[Python-Dev] Deprecating obsolete builtins

Guido van Rossum guido at python.org
Wed Nov 5 10:23:09 EST 2003

> Removing _any_ built-in that was around in 1.5.2 will pose similar
> problems.

Only proportional to the likelihood that it was used in 1.5.2, which
is proportional to how useful it is.  intern(): extremely unlikely
(nobody knows what it's for); coerce(): rather unlikely (too
advanced); apply(): very likely.

> 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...).

The problem (and real cost, for some!) is that people who write code
that should work for 1.5.2 and later end up having to do more
maintenance on it for each new Python version they support.  Maybe we
should just be resigned to having a bunch of unwanted builtins until
3.0 comes along (where I'm okay with all bets being off).

> 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.

(a) It's always better to be able to use a common subset than to have
    to resort to version checking or version-specific hacks.  (We've
    all learned this in the context of platform independence; I think
    the same applies to version independence.)

(b) Since 2.4 and 2.5 don't yet exist (2.4 is at best a moving
    target), someone wanting to use a cross-version subset *now* has
    to settle for targeting and testing with 1.5.2 through 2.3.
    Forcing these folks to do a new release for 2.4 or 2.5 is not
    increasing their work from 99 to 100 units, it's increasing the
    work they have to do in the future from 0 to 1 (on an arbitrary
    scale :-).

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list