[Python-Dev] Deprecating obsolete builtins

Michael Hudson mwh at python.net
Wed Nov 5 10:02:07 EST 2003

Alex Martelli <aleaxit at yahoo.com> writes:

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

Well, yeah, but I contend doing it to, say, coerce would cause less
grief than apply.

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

Yeah, I guess for apply that is no great stretch.

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

I know, but maybe I think he shouldn't have :-)


There's always going to be a tension between wanting to keep backwards
compatibility and making the Python of tomorrow as perfect as
possible.  To me, leaving the builtins a little it cluttered just
isn't that painful.

And perhaps talking about people trying to keep code running on 1.5.2
and 2.4 wasn't a good example; I have more sympathy for people who are
trying to upgrade the Python they use.  Each little obstacle means
that they are that little bit more likely to just throw their hands up
in the air and keep on using 1.5.2 or 2.1 -- and that would be a Bad


  That one is easily explained away as massively intricate
  conspiracy, though.            -- Chris Klein, alt.sysadmin.recovery

More information about the Python-Dev mailing list