Dados de File

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados (os arquivos estão em resources da requisição):

Os campos name, description e format seriam para conhecer melhor sobre o arquivo em si. url seria para realizar o download do arquivo. created e last_modified seriam para saber desde quando o arquivo existe e se ele já sofreu alguma mudança (possivelmente correção de erro e tals, como já teve).

Métodos de File

O acesso aos atributos não necessitaria de métodos (por exemplo os gets), pois é um padrão adotado em alguns pacotes que já vi, como df.columns que é uma variável da classe pandas.DataFrame.

Existiria o método download(), porém os parâmetros poderiam ser diferentes dos que já existem, visto que os filtros de dicionário e anos serão aplicados em Package, no vetor de File, e não diretamente em File.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados:

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

Métodos de Package

O acesso aos atributos não necessitaria de métodos (por exemplo os gets), pois é um padrão adotado em alguns pacotes que já vi, como df.columns que é uma variável da classe pandas.DataFrame.

• __init(self)__: o construtor poderia receber o nome do pacote, aí seria feito a requisição que preencheria a lista de File e pegaria todos os dados necessários.
  • Deveria existir um método set_package() que receberia o nome de um novo pacote, atualizando todas as informações do objeto atual, ou seja, não retorna um novo objeto;
  • Poderia existir o erro de não encontrar o pacote desejado.
• download(): que iria baixar toda a lista de File que existem no Package;
  • Perceba que isso já exclui o atual método download_all(), pois não condiz ao comportamento atual do pacote, sendo necessário colocar esse método em outro local.
• filter(): que iria receber uma função e filtrar a lista de File, retornando um novo Package com os arquivos que satisfizessem o filtro aplicado. Esse método retorna um novo Package.
  • Existiria filtros já criados, como o de baixar dicionário ou não ou se o arquivo está dentro de um range de anos.

Métodos já existentes como print e load poderia ser adaptados, o primeiro para imprimir as informações do pacote e da lista de arquivos (fica a critério do programador decidir isso) e o segundo para dar um refresh no pacote atual que o objeto representa.

Demais funções que existem atualmente

Funções como download_packages, search_related_packages, download_all, download_packages_by_tag e download_packages_by_tag seriam realocados para as novas classes que o pacote irá ter, como um novo modelo para Tag e Group. Isso pois atualmente a classe Package pode manipular mais de um pacote ao mesmo tempo, exemplo: download_all baixa todos os pacotes, e a função dela ao final dessa issue é representar um único pacote.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados:
Dado Exemplo de valor
version "1.1"
resources Lista de File
title "Discentes"
name "discentes"
ckan_url "http://dados.ufrn.br/dataset/discentes"
notes "Relação dos discentes da UFRN."
notes_rendered "<p>Relação dos discentes da UFRN.</p>"
extras É um dicionário com alguns extras do pacote.

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

Essa parte de imprimir pacote podemos implementar como str da classe packages. Outra é que a renderização html notes_rendered é desnecessária, além disso o name e title da API são praticamente iguais, devemos escolher uma das duas.

Dados de Package

Usando a requisição exemplo da issue, acho interessante a classe conter os seguintes dados:
Dado Exemplo de valor
version "1.1"
resources Lista de File
title "Discentes"
name "discentes"
ckan_url "http://dados.ufrn.br/dataset/discentes"
notes "Relação dos discentes da UFRN."
notes_rendered "<p>Relação dos discentes da UFRN.</p>"
extras É um dicionário com alguns extras do pacote.

Boa parte dos campos seriam para permitir que o programador conheça melhor o pacote, sendo que tem atributos "redundantes" que valeriam o debate para decidirmos se iremos colocar ou não, como: notes e notes_rendered, title e name.

acho interessante mantermos o note, mas notes_rendered é irrelevante e escolheríamos entre title ou name, possivelmente name

Como File só é estendida para Package, não há razão para ela ser um mixin, então ela vai ser só uma classe normal que será estendida pra package.