Eric Snow added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17108> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
