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/