On Wed, 2006-04-26 at 10:16 -0700, 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.
But if it's there, then nothing changes, right? IOW, if we want to expose names in the subpackage's namespace, we can still do it in the subpackage's __init__.py. It's just that otherwise empty subpackage __init__.py files won't be required. What would the following print? import toplevel.sub1.sub2 print toplevel.sub1.sub2.__file__ If it's "<path>/sub1/sub2" then that kind of breaks a common idiom of using os.path.dirname() on a module's __file__ to find co-located resources. Or at least, you have to know whether to dirname its __file__ or not (which might not be too bad, since you'd probably know how that package dir is organized anyway). I dunno. Occasionally it trips me up too, but it's such an obvious and easy fix that it's never bothered me enough to care. I can't think of an example, but I suppose it's still possible that lifting this requirement could cause some in-package located data directories to be mistakenly importable. I'd be somewhat more worried about frameworks that dynamically import things having to be more cautious about cleansing their __import__() arguments now. I'd be -1 but the remote possibility of you being burned at the stake by your fellow Googlers makes me -0 :). -Barry