Message181692
Deprecating pkg/__init__.py and having pkg.py coexist with pkg/ was on the table in an earlier proposal (PEP 402). In that case pkg/__init__.py would have been tried first for backward compatbility (until eliminated in Python 4 or whenever). PEP 420 (namespace packages) took a more conservative approach, leaving the question of pkg.py coexisting with pkg/ on the table.
I still find the idea appealing of replacing pkg/__init__.py with simply pkg.py + pkg/. PEP 402 outlines the rationale pretty well. Considering that PEP 420 made __init__.py-less packages legal, deprecating __init__.py isn't a huge leap. The challenge of deciding if a directory is a package is tricky when there is not marker (like __init__.py is), but PEP 420 already tackled that for the most part.
Regardless, it would definitely require a new PEP (likely derived from 402) and some caution, especially since you could argue that people may be relying on the current precedence policy. It would also take a little bit of work for the implementation, and a bunch of work to make sure the stdlib is happy. |
|
Date |
User |
Action |
Args |
2013-02-08 18:54:55 | eric.snow | set | recipients:
+ eric.snow, eric.araujo, Arfrever, r.david.murray, docs@python, shai |
2013-02-08 18:54:55 | eric.snow | set | messageid: <1360349695.73.0.644540366428.issue17108@psf.upfronthosting.co.za> |
2013-02-08 18:54:55 | eric.snow | link | issue17108 messages |
2013-02-08 18:54:55 | eric.snow | create | |
|