-
-
Notifications
You must be signed in to change notification settings - Fork 32k
bpo-30645: use an internal variable while iterating in imp.load_package() #2268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@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. |
@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)? |
ack thanks :) |
Misc/NEWS
Outdated
@@ -381,6 +381,8 @@ Library | |||
- bpo-30508: Don't log exceptions if Task/Future "cancel()" method was | |||
called. | |||
|
|||
- bpo-30645: use an internal variable while iterating in imp.load_package() | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"use an internal variable" is implementation detail and it's not suitable for NEWS entry.
Please describe the bug you fixed.
ack |
…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 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not worrying about tests since the problem is very obvious and this whole module is actually deprecated.
…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. |
…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. |
Thanks for the PR, @commodo ! |
…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 :) |
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 [email protected]