On 4/26/06, André Malo <[EMAIL PROTECTED]> wrote: > * Guido van Rossum wrote: > > > On 4/26/06, André Malo <[EMAIL PROTECTED]> wrote: > > > * Guido van Rossum wrote: > > > > So I have a very simple proposal: keep the __init__.py requirement > > > > for top-level pacakages, but drop it for subpackages. This should be > > > > a small change. I'm hesitant to propose *anything* new for Python > > > > 2.5, so I'm proposing it for 2.6; if Neal and Anthony think this > > > > would be okay to add to 2.5, they can do so. > > > > > > Not that it would count in any way, but I'd prefer to keep it. How > > > would I mark a subdirectory as "not-a-package" otherwise? > > > > What's the use case for that? Have you run into this requirement? And > > even if you did, was there a requirement that the subdirectory's name > > be the same as a standard library module? If the subdirectory's name > > is not constrained, the easiest way to mark it as a non-package is to > > put a hyphen or dot in its name; if you can't do that, at least name > > it something that you don't need to import. > > Actually I have no problems with the change from inside python, but from the > POV of tools, which walk through the directories, collecting/separating > python packages and/or supplemental data directories. It's an explicit vs. > implicit issue, where implicit would mean "kind of heuristics" from now on. > IMHO it's going to break existing stuff [1] and should at least not be done > in such a rush. > > nd > > [1] Well, it does break some of mine ;-)
Can you elaborate? You could always keep the __init__.py files, you know... -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
