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.
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?
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.
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.
Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4