will python 3000 break my code?

Fredrik Lundh effbot at telia.com
Wed Mar 1 22:30:19 CET 2000


Daniel Berlin wrote:
> > (ask Frederik if he doesn't have more interesting things to do than fixing
> > multiargument appends ;-)
>
> Actually, it's not a design change in about 95% of the incompatible
> changes in g++. It's just the implementation happened to be allowing
> illegal (by the language standard) things because nobody had gotten around
> to saying "that's illegal".

last time I checked, Python had no formal standard.

(the language reference is pretty good, but it's no
ISO/ANSI level standard.  and nobody reads it any-
way ;-)

> Not a bug?

depends.  "append" used old method calling syntax
(ml_flags == 0), under which all arguments are passed
to the function as a tuple.  the code just added that
to the list.

given that lots of old code in the standard library used
this feature, someone must once have thought that
this was a good idea.  or at least acceptable.

however, it was deprecated as of 1.4 (where you around
at that time?), but as far as I know, nobody remembered
to add a warning to the documentation.

so what we're seeing is an innocent looking minor change,
that turns out to:

    1. break lots of code

    2. result in a runtime error, not compile-time
    error.  we've already seen cases where code
    expected a TypeError to have a certain mean-
    ing, and misbehaved when append and not ord
    was the one throwing the exception (written by
    a programmer that knew his tool too well,
    obviously...)

    3. be impossible to identify by automatic tools.
    Tim's excellent checkappend.py can spot many
    cases, but not all.

given this, arguing whether this is a bug or a feature is
rather meaningless.  I'd call it a "CPython implementation
wart".

the BDFL wants to get rid of it.  that's okay with me.

calling professional programmers idiots is not okay.

</F>





More information about the Python-list mailing list