[Python-Dev] Dropping __init__.py requirement for subpackages

[Donovan Baarda]

Guido van Rossum wrote:
> On 4/26/06, Barry Warsaw <barry at python.org> wrote:
> 
>>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.
[...]
>>>>I'd be -1 but the remote possibility of you being burned at the stake by
>>your fellow Googlers makes me -0 :).
> 
> 
> I'm not sure I understand what your worry is.

I happen to be a Googler too, but I was a Pythonista first...

I'm -1 for minor mainly subjective reasons;

1) explicit is better than implicit. I prefer to be explicit about what 
is and isn't a module. I have plenty of "doc" and "test" and other 
directories inside python module source tree's that I don't want to be 
python modules.

2) It feels more consistant to always require it. /foo/ is a python 
package because it contains an __init__.py... so package /foo/bar/ 
should have one one too.

3) It changes things for what feels like very little gain. I've never 
had problems with it, and don't find the import exception hard to diagnose.

Note that I think the vast majority of "newbie missing __init__.py" 
problems within google occur because people are missing __init__.py at 
the root of package import tree. This change would not not solve that 
problem.

It wouldn't surprise me if this change would introduce a slew of newbies 
complaining that "I have /foo on my PYTHONPATH, why can't I import 
foo/bar/" because they're forgotten the (now) rarely required __init__.py


--
Donovan Baarda