Re: an old idea: getting rid of __init__.py

On 3 May 2015 at 08:22, Eric Snow <[email protected]> wrote:
> When namespace packages were under discussion I remember we were
> seriously considering eliminating the requirement of __init__.py for
> *all* packages.

Which is what we effectively did. You only need an __init__.py now if you:

a) want module level attributes, rather than only subpackages;
b) want to run other code at package import time; or
c) want to forcibly close the package to further extension in other directories.

As Antoine notes, the implicit nature of magically scanning
directories for subpackages trades away comprehensibility for the sake
of convenience. It's main advantage is actually "that's the way other
languages handle import namespacing".

The kind of traditional package created by adding __init__.py could be
described as being more akin to a "directory module" than it is to a
pure namespace package (certainly "directory module" is an accurate
description of former single-file modules like unittest, which go out
of their way to hide the fact that they're now implemented across
multiple files).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia