[Python-Dev] PEP 294: Type Names in the types Module
Oren Tirosh
oren-py-d@hishome.net
Tue, 25 Jun 2002 16:24:24 +0300
On Tue, Jun 25, 2002 at 02:08:54PM +0200, Peter Funk wrote:
> A recent thread here on python-dev came to the conclusion to
> "silently deprecate" the standard library modules 'string' and 'types'.
> This silent deprecation nevertheless means, that these modules will
> go away at some future point in time. I don't like this decision,
> but I understand the reasoning and can now only hope, that this
> point in time lies very very far away in the future.
I don't like it very much either. I prefer the string module to be silently
deprecated "forever" without any specific schedule for removal.
That's why the Backward Compatibility section of this PEP says that "it is
not planned to actually remove the long names from the types module in some
future version."
I think that actually breaking backward compatibility should be reserved for
really obscure modules that virtually nobody uses any more. Another case is
when the programs that will be broken were using somewhat questionable
programming practices in the first place (e.g. lst.append(x,y) instead of
lst.append((x,y)) or assignment to __class__).
> Unfortunately this will not help for software, which has already been
> written and is in production. If in 2004 certain Python programs
> written in 2000 or earlier would start raising ImportError exceptions
> on 'from types import *' after upgrading to a new system which may come
> with the latest version of Python, this will certainly cause damage.
In fact, reusing the types module instead of deprecating and eventually
removing it will ensure that no ImportError will be raised. The new types
module will also serve as a retirement home for the long type names where
they can live comfortably and still be of some use to old code instead being
evicted.
There is a problem though. "from types import *" would import the short
names, too, overriding the builtins. If you redefine int or str you probably
deserve it :-) but if you have an innocent variable called "function"
somewhere in your module it will get clobbered. This is a problem. The
solution might be to include only the long type names in __all__.
Oren