391
Comment:
|
2357
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | Line 5: |
Attendees: * Erik Bray * Jason Coombs * Michael Droettboom * Eric Smith * Barry Warsaw * Steve Waterbury Bitbucket clone: https://bitbucket.org/embray/pep-382-sprint |
|
Line 8: | Line 18: |
* look for reference counting issues * other initialization issues ({{{*foo = NULL}}}) |
|
Line 9: | Line 21: |
* top-level non-trivial __init__.py * various reload scenarios * both {{{__init__.py}}} and {{{.pth}}} file exists * multiple .pth files in the same namespace package directory * {{{.pth}}} files that contain path names: do they set {{{__path__}}} correctly? * is {{{package.__path__}}} set correctly? must contain one {{{*}}}, at the beginning * test that {{{load_module_with_path()}}} (pep 302 loader) gets called correctly * test AttributeError when that's missing |
|
Line 12: | Line 32: |
* --e.g. zip import-- Already done, but zipimport needs to support PEP-382 * load-from-file could just be a PEP 302 loader * could land independently (but need to go through python-dev) * does this really make our lives easier? * attempt a merge of mvl's branch to trunk * figure out build problems on windows (jaraco) * test_imp gives one failure on fedora (make sure imp module has been updated) * stylistic cleansing of import.c * tests against 0 vs. NULL * mispellings * should LBYL on AttributeError in {{{find_path}}} = PEP Questions = * Clarify what happens when a directory contains both an {{{__init__.py}}} and a {{{.pth}}} file * PEP should clarify what the impact of the PEP is on existing namespace packages (i.e. those with magic {{{__init__.py}}} files * Do {{{import}}} statements in {{{.pth}}} files get ignored or does it raise an error? * Impact of PEP on setuptools/packaging/distutils* * Use case for extending existing .pth file syntax (minus {{{import}}} support)? I.e why are non-* lines in the .pth files added to __path__? And should these really be called {{{.pth}}} files? At least clarify the PEP! = |
PEP 382 Sprint
- Silver Spring, Maryland USA 21-Jun-2011 2000UTC
Attendees:
- Erik Bray
- Jason Coombs
- Michael Droettboom
- Eric Smith
- Barry Warsaw
- Steve Waterbury
Bitbucket clone: https://bitbucket.org/embray/pep-382-sprint
Tasks
review Martin's branch hg clone http://hg.python.org/features/pep-382
- look for reference counting issues
other initialization issues (*foo = NULL)
- do we have sufficient test coverage?
top-level non-trivial init.py
- various reload scenarios
both __init__.py and .pth file exists
- multiple .pth files in the same namespace package directory
.pth files that contain path names: do they set __path__ correctly?
is package.__path__ set correctly? must contain one *, at the beginning
test that load_module_with_path() (pep 302 loader) gets called correctly
test AttributeError when that's missing
is importlib is covered?
- pull down 3rd party pep 302 loader and see if/how it's broken
- refactor import.c to yank out anything that can be written as a 302 loader?
- --e.g. zip import-- Already done, but zipimport needs to support PEP-382
- load-from-file could just be a PEP 302 loader
- could land independently (but need to go through python-dev)
- does this really make our lives easier?
- attempt a merge of mvl's branch to trunk
- figure out build problems on windows (jaraco)
- test_imp gives one failure on fedora (make sure imp module has been updated)
- stylistic cleansing of import.c
- tests against 0 vs. NULL
- mispellings
should LBYL on AttributeError in find_path
PEP Questions
Clarify what happens when a directory contains both an __init__.py and a .pth file
PEP should clarify what the impact of the PEP is on existing namespace packages (i.e. those with magic __init__.py files
Do import statements in .pth files get ignored or does it raise an error?
- Impact of PEP on setuptools/packaging/distutils*
Use case for extending existing .pth file syntax (minus import support)? I.e why are non-* lines in the .pth files added to path? And should these really be called .pth files? At least clarify the PEP!
=