Repository navigation
bpo-30645: use an internal variable while iterating in imp.load_package() - #2268
brettcannon merged 3 commits into
Conversation
Sorry, something went wrong.
|
@commodo, thanks for your PR! By analyzing the history of the files in this pull request, we identified @brettcannon, @ericsnowcurrently and @ncoghlan to be potential reviewers. |
Sorry, something went wrong.
|
@commodo Did you want to add yourself to the ACKS file and write an entry for Misc/NEWS (somewhere not at the top of the Library section to avoid merge conflicts)? |
Sorry, something went wrong.
|
ack thanks :) |
Sorry, something went wrong.
There was a problem hiding this comment.
"use an internal variable" is implementation detail and it's not suitable for NEWS entry.
Please describe the bug you fixed.
Sorry, something went wrong.
|
ack |
Sorry, something went wrong.
…ge() The imp.load_package() function is marked as deprecated, however, some packages (like virtualenv) seem to use it. The problem with that loop, is that if the .py file does not exist, you'll get a `<path-to-package>__init__.py/__init__.pyc` file. When shipping only Python bytecodes, we don't want that. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
brettcannon
left a comment
There was a problem hiding this comment.
I'm not worrying about tests since the problem is very obvious and this whole module is actually deprecated.
Sorry, something went wrong.
…ythonGH-2268) Bug didn't manifest itself when importing a module with source as .py files are always the first on the search path. The issue only showed up in bytecode-only packages where the calculated file path would be ``__init__.py/__init__.pyc``. Patch by Alexandru Ardelean. (cherry picked from commit c38e32a)
…ge() (pythonGH-2268) Bug didn't manifest itself when importing a module with source as .py files are always the first on the search path. The issue only showed up in bytecode-only packages where the calculated file path would be ``__init__.py/__init__.pyc``. Patch by Alexandru Ardelean.. (cherry picked from commit c38e32a)
|
GH-2364 is a backport of this pull request to the 3.6 branch. |
Sorry, something went wrong.
…ge() (pythonGH-2268) Bug didn't manifest itself when importing a module with source as .py files are always the first on the search path. The issue only showed up in bytecode-only packages where the calculated file path would be ``__init__.py/__init__.pyc``. Patch by Alexandru Ardelean.. (cherry picked from commit c38e32a)
|
GH-2365 is a backport of this pull request to the 3.5 branch. |
Sorry, something went wrong.
…ge() (GH-2268) (#2364) Bug didn't manifest itself when importing a module with source as .py files are always the first on the search path. The issue only showed up in bytecode-only packages where the calculated file path would be ``__init__.py/__init__.pyc``. Patch by Alexandru Ardelean. (cherry picked from commit c38e32a)
…ge() (GH-2268) (GH-2365) Bug didn't manifest itself when importing a module with source as .py files are always the first on the search path. The issue only showed up in bytecode-only packages where the calculated file path would be ``__init__.py/__init__.pyc``. Patch by Alexandru Ardelean. (cherry picked from commit c38e32a)
|
thank you :) |
Sorry, something went wrong.
The imp.load_package() function is marked as deprecated,
however, some packages (like virtualenv) seem to use it.
The problem with that loop, is that if the .py file
does not exist, you'll get a
<path-to-package>__init__.py/__init__.pyc file.
When shipping only Python bytecodes, we don't want that.
Signed-off-by: Alexandru Ardelean ardeleanalex@gmail.com