Import Cíclico - Qual a melhor forma de evitar e corrigir?

[Eduardo Pires]

Pessoal,

Estava implementando uns projetos usando Python, e a modelagem das classes acaba gerando alguns import cíclicos, ou seja:

a.py importa funções de b.py.
b.py importa funções de c.py.
c.py importa funções de a.py.

Qual a melhor maneira de corrigir isso?
O recomendável é sempre deixar os "import" no início do arquivo, como sugere o PEP8. (http://www.python.org/dev/peps/pep-0008/)
Mas Python permite o import no meio de um método, por exemplo, o que deve resultar numa perda de desempenho do código.

Abraço a todos.
--
Eduardo Pires

[Gileno Alves]

Se este problema for frequente talvez seja bom rever a estrutura do código.

2010/12/2 Eduardo Pires <eduardo...@gmail.com>

--
Você está recebendo esta mensagem porque se inscreveu no grupo "pug-pe" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para pug...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para pug-pe+un...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/pug-pe?hl=pt-BR.

--
Abraços,
Gileno Filho

http://www.gilenofilho.com.br

[Luciano Rodrigues da Silva]

Sobre os imports, acho que vc está fazendo da forma errada. Vc deveria ter uma biblioteca com os códigos que todos vão precisar, então eu aconselho vc pensar novamente na estrutura do seu código.

Sobre os imports no meio de código, primeiro não há queda de desempenho simplemente por eles serem chamados no meio do código. O custo será o mesmo. Inclusive isso é um comportamento recomendado dependendo de como seu código funciona. Se o import só for necessário em determinadas condições, fazendo o import dentro do código só quando necessário, economizando em memória e em processamento. Oq tem que ser visto é quantas vezes esse import seria feito (pois se o import for feito muitas vezes então vc deveria coloca-lo no inicio pq economizaria em processamento).

2010/12/2 Eduardo Pires <eduardo...@gmail.com>

--

Você está recebendo esta mensagem porque se inscreveu no grupo "pug-pe" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para pug...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para pug-pe+un...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/pug-pe?hl=pt-BR.

--
Até,

Luciano

<quote>
"Na prática, a teoria é outra!"
</quote>

:wq!

[Marcel Caraciolo]

Eduardo,

Acredito que o problema é a maneira de organizar seu código. Sempre bom centralizar tudo em um lugar e chamar a partir deste ponto, ou verificar se aquele trecho de código onde é mais chamado e a depender colocá-lo em um mesmo módulo.

Sobre a importação, não há problemas em adicionar no meio dos métodos, desde que justifique seu uso. Se o mesmo for utilizado em um lugar pontual, o apropriado é importá-lo dentro do método.

Se o mesmo for usado em diversos lugares, importá-lo no início do módulo é a prática adotada.

Abraços,

Marcel

2010/12/2 Luciano Rodrigues da Silva <lucro...@gmail.com>

--
Marcel Pinheiro Caraciolo
M.S.C. Candidate at CIN/UFPE

   http://www.mobideia.com
   http://aimotion.blogspot.com/

[Marcel Caraciolo]

Dêem uma lida.

http://effbot.org/zone/import-confusion.htm

Por fim:

http://docs.python.org/faq/programming.html

Only move imports into a local scope, such as inside a function definition, if it’s necessary to solve a problem such as avoiding a circular import or are trying to reduce the initialization time of a module. This technique is especially helpful if many of the imports are unnecessary depending on how the program executes. You may also want to move imports into a function if the modules are only ever used in that function. Note that loading a module the first time may be expensive because of the one time initialization of the module, but loading a module multiple times is virtually free, costing only a couple of dictionary lookups. Even if the module name has gone out of scope, the module is probably available in sys.modules.

Abs,

Marcel

2010/12/3 Marcel Caraciolo <cara...@gmail.com>

[Daker Fernandes]

Um erro comum é a criação de diversas classes cada uma em um arquivo diferente apesar de estarem fortemente acopladas. Se elas são fortemente acopladas, não há problema em colocá-las em um único arquivo.

O problema que pode surgir dessa demanda é o controle de versão, já que deve haver mais modificações em um mesmo arquivo ao invés de ter uma alteração mais fragmentada.
Uma maneira de minimizar esse problema é o uso de um sistema de gerenciamento de versões mais inteligente. Fica a dica de dar uma olhada no git.

Abraços!

Daker Fernandes Pinheiro (dfp)
Graduando em CC, turma 2007.2
CIn - UFPE

[Eduardo Pires]

Pessoal,

Primeiramente, valeu pela ajuda. O pessoal aqui sempre disposto a ajudar.

Sobre o que Daker falou sobre acoplamento, eu achei que não se aplicaria muito, porque a modelagem que a gente tá usando é baseado em SOA, arquitetura orientado a serviços, e queremos o máximo de desacoplamento.
Entretanto, esse problema ta acontecendo pq tem um módulo do sistema que gera mensagens das atividades de um usuário para seus amigos, e esse controlador de mensagens precisa recuperar os amigos do usuário que emite a ação.
Por isso não faz tanto sentido deixar esses dois módulos num mesmo arquivo, pq vamos perder muito em modularidade.

Uma solução que eu vejo é a de isolar apenas o processo de recuperação de amigos, que não tem dependência com esse controlador de mensagens.

Valeu aí mais uma vez.
--
Eduardo Pires

2010/12/3 Daker Fernandes <dak...@gmail.com>