[Python-Dev] __all__ for pickle

[M.-A. Lemburg]

Jeremy Hylton wrote:
> 
> I was just testing Zope with the latest CVS python and ran into
> trouble with the pickle module.
> 
> The module has grown an __all__ attribute:
> 
> __all__ = ["PickleError", "PicklingError", "UnpicklingError", "Pickler",
>            "Unpickler", "dump", "dumps", "load", "loads"]
> 
> This definition excludes a lot of other names defined at the module
> level, like all of the constants for the pickle format, e.g. MARK,
> STOP, POP, PERSID, etc.  It also excludes format_version and
> compatible_formats.
> 
> I don't understand why these names were excluded from __all__.  The
> Zope code uses "from pickle import *" and writes a custom pickler
> extension.  It needs to have access to these names to be compatible,
> and I can't think of a good reason to forbid it.

I guess it was a simple oversight. Why not add the constants to the
above list ?!
 
> What's the right solution?  Zap the __all__ attribute; the namespace
> pollution that results is fairly small (marshal, sys, struct, the
> contents of tupes).  Make __all__ a really long list?

The latter, I guess. Some lambda hackery ought to fix this
elegantly.
 
> I wonder how much breakage we should impose on people who use "from
> ... import *" for Python 2.1.  As you know, I was an early advocate of
> the it's-sloppy-so-let-em-suffer philosophy, but I have learned the
> error of my ways.  I worry that people will be unhappy with __all__ if
> other modules suffer from similar code breakage.

IMHO, we should try to get this right now, rather than later.
The betas will get enough testing to reduce the breakage 
below the noise level. If there's still serious breakage somewhere,
then patches will be simple: just comment out the __all__
definition -- even newbies will be able to do this (and feel
great about it ;-).

Besides, the __all__ attribute is a good
way to define a module API and certainly can be put to good
use in future Python versions, e.g. by declaring those module
attribute read-only and pre-fetching them into function locals...

> Has __all__ been described by a PEP?  If so, it ought to be posted to
> c.l.py for discussion.  If not, we should probably write a short PEP.
> It would probably be a page of text, but it would help clarify that
> confusion that persists about what __all__ is for and what its
> consequences are.

No, there's no PEP for it. The reason is that __all__ has been
in existence for quite a few years already. Previously it was
just used for packages -- the patch just extended it's scope
to simple modules. It is documented in the tutorial and the API
docs, plus in Guido's essays.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/