[Python-Dev] Deprecating obsolete builtins

Alex Martelli aleaxit at yahoo.com
Wed Nov 5 09:45:11 EST 2003

On Wednesday 05 November 2003 02:48 pm, Michael Hudson wrote:
> "Raymond Hettinger" <python at rcn.com> writes:
> > [Neal Norwitz]
> >
> >> For 2.4 I'd suggest we officially deprecate: apply, coerce, intern.
> >
> > +1
> I think apply is probably widely enough used that this is too strong.
> It could be a right royal pain in the arse if you wanted to have code
> that still ran in 1.5.2.  I realize that this poses other problems,
> but I don't feel we should be going out of our way to make it harder.

Removing _any_ built-in that was around in 1.5.2 will pose similar
problems.  How hard can it be, in Python source that needs to run
on both 1.5.2 and 2.5, to, e.g.:

try: import legacy_25x_152
except ImportError: pass

where the "legacy module" would inject apply (etc) in builtins?  (In
2.4, you'd "just" need to turn off deprecation warnings, which in
such a stretched case as 1.5-to-2.4 you're surely doing anyway...).

Guido has specifically asked for built-ins that could be deprecated.

It doesn't seem to me that asking for deprecation warnings to be
turned off, or a "legacy module" to be conditionally imported, is
"going out of our way to make it harder" to have code running all
the way from 1.5 to 2.5 -- if such a feat currently requires 99 units
of effort it MAY move all the way to 100 this way, but I doubt the
relative augmentation of effort is even as high as that.


More information about the Python-Dev mailing list