Python-future: Importing `backports` and `moves` packages, imports (e.g. `test.py`) fromuser folders,

Created on 28 Jan 2017  ·  4Comments  ·  Source: PythonCharmers/python-future

future-version: 0.16.0
python-ver: 3.5

When importing either future.moves or future.backports packages, it invokes import_top_level_modules() which attempts to import various modules by name. For instance, if there is a test.py in user project, it is also gets unexpectedly imported.

According the message of one implicated commit 264f9bcdf0, the import_top_level_modules() method was introduced for "getting the test runner working on travis-ci on Py3".
Wouldn't be better to place this code in test-packages?

0.19 bug

Most helpful comment

I was just bitten by this when using apache_beam with python3.

To reproduce:

echo "raise NotImplementedError('This test.py file should not be touched')" >> ./test.py
pip install apache_beam
python -c "import apache_beam as beam"

I notice that the comment for exclude_local_folder_imports which is called from import_top_level_modules states:

(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?)

It seems to work fine without it. Perhaps it's time.

All 4 comments

any update on this?

I was just bitten by this when using apache_beam with python3.

To reproduce:

echo "raise NotImplementedError('This test.py file should not be touched')" >> ./test.py
pip install apache_beam
python -c "import apache_beam as beam"

I notice that the comment for exclude_local_folder_imports which is called from import_top_level_modules states:

(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?)

It seems to work fine without it. Perhaps it's time.

Also bitten while using the dash plotting library that relies on this package. I was getting very strange behavior because I happened to have a quick-and-dirty test.py for experimenting with my package during development, that turns out to have been running and silently changing critical state every time I did a local test of my app. I really dislike debugging silent issues like this. Please consider prioritizing the removal of this behavior.

Was this page helpful?
0 / 5 - 0 ratings