RetroSearch Browse

Wed Nov 5 22:58:37 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040043.html

On Thu, Nov 06, 2003 at 12:26:12PM +1300, Greg Ewing wrote:
> [Neal Norwitz]
> > For 2.4 I'd suggest we officially deprecate: apply, coerce, intern.
> 
> In the case of intern, do you mean to move it into
> a module, or remove it altogether? 
> 
> If the latter, why?

For the most part, I meant to remove them (including intern)
altogether in the long run.  In 2.4, I only meant to officially
deprecate them with a warning.  intern() doesn't seem particularly
useful or commonly used.  At least moving it to sys or some other
module is an improvement IMO.

My primary goal in pushing to deprecate these older features 
is to make the language smaller.  A secondary goal is 
to reduce the code base, thus easing maintenance and testing.  
If a feature is not useful, in the long run, I think it should
be removed.  I agree there's pain involved.  But there's
also pain in keeping it.  Part of that pain, is that its
use get propagated.  Perhaps people that teach Python and
write books can speak to this better than I.

This idea leads to Jeremy's statement:

        The solution is to get people to stop using 1.5.2.  I don't
        entirely understand why so many people write new code that
        needs to work with it.

If we never deprecate/threaten to remove a feature, people will
continue to use it.  But that becomes a circular argument for
why we can't deprecate/remove it.  How long should we wait
from the time a feature is not needed until it is removed?

Here's the documentation release dates from the doc web page
(http://python.org/doc/versions.html):

        2.3   29 Jul 2003
        2.2   21 Dec 2001
        2.1   15 Apr 2001
        2.0   16 Oct 2000
        1.5.2 30 Apr 1999

By the time 2.4 is released (likely mid-2004 at the earliest),
apply() will have been made redundant for about 4 years
(since 2.0 was released).  All we are talking about
is adding a warning for 2.4.  I'm not sure whether it is 
appropriate to remove apply() in 2.5 (delivered in 2005-2006?).  
But if we don't work towards cleaning up, it will never get done.

I also have no problem adding a module for backwards compatibility
that adds apply(), etc to builtins.  In fact, I think this is 
a better approach that if someone wants to "port" their code
from 1.5.2 to 2.4, they can acheive much of it by adding:

        import python1_5_2_compatibility

which does some magic.

I also think the reverse is true.  For new builtins, it would
be nice to provide a compatibility module that can be downloaded
for older versions.  That way I can use sum(), enumerate(), etc
in 2.2 and before.

Neal

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040043.html below:

[Python-Dev] Deprecating obsolete builtins