versão futura: 0.16.0
python-ver: 3.5
Ao importar future.moves
ou future.backports
pacotes, ele invoca import_top_level_modules()
que tenta importar vários módulos por nome. Por exemplo, se houver um test.py
no projeto do usuário, ele também será importado inesperadamente.
De acordo com a mensagem de um commit envolvido 264f9bcdf0, o método import_top_level_modules()
foi introduzido para "fazer o executor de teste trabalhar em travis-ci em Py3" .
Não seria melhor colocar este código em pacotes de teste?
apenas mordido por isso.
https://bitbucket.org/pyglet/pyglet/issues/117/pyglet-produces-spurious-imports
alguma atualização disso?
Eu fui mordido por isso ao usar apache_beam com python3.
Reproduzir:
echo "raise NotImplementedError('This test.py file should not be touched')" >> ./test.py
pip install apache_beam
python -c "import apache_beam as beam"
Percebo que o comentário de exclude_local_folder_imports
que é chamado de import_top_level_modules
afirma:
(This was need prior to v0.16.0 because the presence of a configparser
folder would otherwise have prevented setuptools from running on Py3. Maybe
it's not needed any more?)
Parece funcionar bem sem ele. Talvez seja a hora.
Também mordido ao usar a biblioteca de plotagem de traços que depende deste pacote. Eu estava tendo um comportamento muito estranho porque aconteceu de ter um test.py
rápido e sujo para experimentar com meu pacote durante o desenvolvimento, que acabou rodando e mudando silenciosamente de estado crítico toda vez que eu fazia um teste local do meu aplicativo. Eu realmente não gosto de depurar problemas silenciosos como este. Considere priorizar a remoção desse comportamento.
Comentários muito úteis
Eu fui mordido por isso ao usar apache_beam com python3.
Reproduzir:
Percebo que o comentário de
exclude_local_folder_imports
que é chamado deimport_top_level_modules
afirma:Parece funcionar bem sem ele. Talvez seja a hora.