Keeping __init__.py empty for Python packages used for module grouping.
Looking at http://docs.python.org/dev/library/html.html#module-html it would appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two loosely related modules, html.parser and html.entities.
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
Before the placement of html.escape() becomes set in stone, I think we should consider putting it somewhere else.
Raymond
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html it would appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two loosely related modules, html.parser and html.entities.
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
Before the placement of html.escape() becomes set in stone, I think we should consider putting it somewhere else.
To be honest, I don't see the issue. I don't see stdlib packages as "namespace containers", but rather as a nice way of structuring functionality. And remember that flat is better than nested -- why should escape() be put away into a new submodule?
At least you'll need to let us know where you would rather put that function.
Georg
On 1/24/2011 2:18 PM, Georg Brandl wrote:
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html it would appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two loosely related modules, html.parser and html.entities.
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
Before the placement of html.escape() becomes set in stone, I think we should consider putting it somewhere else.
To be honest, I don't see the issue. I don't see stdlib packages as "namespace containers", but rather as a nice way of structuring functionality. And remember that flat is better than nested -- why should escape() be put away into a new submodule?
At least you'll need to let us know where you would rather put that function.
I would put in html.entities, which is also sparse, as it seems to me vaguely related.
On Mon, Jan 24, 2011 at 11:18, Georg Brandl g.brandl@gmx.net wrote:
Am 24.01.2011 20:04, schrieb Raymond Hettinger:
Looking at http://docs.python.org/dev/library/html.html#module-html it would appear that we've created a new module with a single trivial function.
In reality, there was already a python package, html, that served to group two loosely related modules, html.parser and html.entities.
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
Before the placement of html.escape() becomes set in stone, I think we should consider putting it somewhere else.
To be honest, I don't see the issue. I don't see stdlib packages as "namespace containers", but rather as a nice way of structuring functionality. And remember that flat is better than nested -- why should escape() be put away into a new submodule?
Importlib also acts as a precedent with importlib.import_module(). I honestly don't feel the need to treat packages as a namespace explicitly (but then again I also disagree with the argument that __init__.py needs to be left empty).
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger raymond.hettinger@gmail.com wrote:
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
This is only an issue if the separate components are distributed separately; for the standard library, we're not using it as a namespace package in the same sense that is done with (for example) the "zope" package.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/24/2011 03:14 PM, Fred Drake wrote:
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger raymond.hettinger@gmail.com wrote:
ISTM, that if we're going to use python packages as "namespace containers" for categorizing modules, then the top level __init__ namespace should be left empty.
This is only an issue if the separate components are distributed separately; for the standard library, we're not using it as a namespace package in the same sense that is done with (for example) the "zope" package.
It might matter if we want to enable third-party package installation into a namespace also used by the stdlib: ISTR that the 'xml' package had such installs at one point.
If that pattern is a goal, having all versions of the namespace's __init__.py empty of anything but the __path__-munging majyk / boilerplate is required to make such installs work regardless of the order of PYTHONPATH.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
If that pattern is a goal, having all versions of the namespace's __init__.py empty of anything but the __path__-munging majyk / boilerplate is required to make such installs work regardless of the order of PYTHONPATH.
With PEP 382, having extensible packages won't contradict to having a non-trivial __init__.py, and no __path__-munging will be necessary.
Regards, Martin
On Mon, Jan 24, 2011 at 4:59 PM, Tres Seaver tseaver@palladion.com wrote:
It might matter if we want to enable third-party package installation into a namespace also used by the stdlib: ISTR that the 'xml' package had such installs at one point.
Almost, but not quite.
The xml package at one point allowed itself to be overridden by another package (_xmlplus specifically), however that was define. Experience proved that this was a mistake.
"Namespace packages", as originally defined by setuptools and applied for the hurry, zc, and zope packages (and many others), are a very different thing than what was done for the xml/_xmlplus package, and have proven significantly more useful and usable.
While I heartily approve of "namespace packages" of that sort, I see no reason to support installing into the same package namespace as the standard library. The primary disadvantage I see is that it would be too easy to foster confusion over what's in the standard library among newcomers.
-Fred
-- Fred L. Drake, Jr. <fdrake at acm.org> "A storm broke loose in my mind." --Albert Einstein
participants (7)
-
"Martin v. Löwis" -
Brett Cannon -
Fred Drake -
Georg Brandl -
Raymond Hettinger -
Terry Reedy -
Tres Seaver