Atualmente, no que chegamos a planejar para o escopo da segunda versão do pacote, as classes passarão a representar uma única entidade (o que facilita algumas das várias funcionalidades que desejamos), por exemplo: Package representa exclusivamente um único pacote de dados.
O problema nisso é que perdemos, em parte, o poder de utilizar vários pacotes de uma vez. Por exemplo: se eu quisesse fazer uma manipulação em dois grupos de pacotes, ensino e pessoas, eu teria que criar uma lista e salvar ambos os pacotes nessa lista, porém as manipulações ficariam chatas, pois sempre teria que iterar na lista criada. Além de que eu irei possuir pacotes redundantes, nesse caso o pacote discentes está nos dois grupos.
Creio que seria interessante criarmos uma estrutura de dados como as várias Collections existentes. Um exemplo que poderíamos pegar como base seria a Collections do Laravel. Além de que poderíamos adicionar métodos que julgássemos relevantes.
Isso poderia ser expandido para Tag, como também criar alguma estrutura que armazene Package, independente dos pacotes serem do mesmo grupo ou não, tipo um PackageCollection.
Esse tipo de estrutura poderia nos ajudar a realizar operações de conjuntos, como intersect e merge.
Exemplo
Um exemplo que julgo interessante.
# Estou considerando que o __init__ do Group irá se comportar desse jeito
group_ensino = Group('ensino')
group_pessoas = Group('pessoas')
# Collection de grupos com ensino e pessoas MODO 1
groups = Groups(['ensino', 'pessoas'])
# Collection de grupos com ensino e pessoas MODO 2
groups = GroupCollection(['ensino', 'pessoas'])
# Descobrir quais pacotes estão em ambos os grupos
groups_intersect = groups.intersect() # Retornaria, de certeza, o package de discentes
# Pegar a diferença entre dois grupos
groups_diff = group_ensino.diff(group_pessoas)
# Mesclar dois grupos de pacotes, resultando em apenas um imenso grupo
groups_merge = group_ensino.merge(group_pessoas)
# Em groups_merge teriamos uma lista de packages,
# porém sem os atributos que definem um único grupo,
# pois aqui englobaria dois grupos de pacotes.
# Uma alternativa seria ter atributos como `groups_name`, que seria uma lista
# com os nomes dos grupos que geraram aquele grande grupo.
Essas funcionalidades de intersect e merge, por exemplo, poderiam ser usadas depois da integração com o pandas, então não vemos vantagem em usar essa abordagem.
Debate sobre Collections
Atualmente, no que chegamos a planejar para o escopo da segunda versão do pacote, as classes passarão a representar uma única entidade (o que facilita algumas das várias funcionalidades que desejamos), por exemplo:
Package
representa exclusivamente um único pacote de dados.O problema nisso é que perdemos, em parte, o poder de utilizar vários pacotes de uma vez. Por exemplo: se eu quisesse fazer uma manipulação em dois grupos de pacotes,
ensino
epessoas
, eu teria que criar uma lista e salvar ambos os pacotes nessa lista, porém as manipulações ficariam chatas, pois sempre teria que iterar na lista criada. Além de que eu irei possuir pacotes redundantes, nesse caso o pacotediscentes
está nos dois grupos.Creio que seria interessante criarmos uma estrutura de dados como as várias Collections existentes. Um exemplo que poderíamos pegar como base seria a Collections do Laravel. Além de que poderíamos adicionar métodos que julgássemos relevantes.
Isso poderia ser expandido para
Tag
, como também criar alguma estrutura que armazenePackage
, independente dos pacotes serem do mesmo grupo ou não, tipo umPackageCollection
.Esse tipo de estrutura poderia nos ajudar a realizar operações de conjuntos, como
intersect
emerge
.Exemplo
Um exemplo que julgo interessante.