PEP 382 Sprint

Attendees:

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

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!