will python 3000 break my code?

[Daniel Berlin]

>>>>> "FL" == Fredrik Lundh <effbot at telia.com> writes:

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

   FL> last time I checked, Python had no formal standard.

Given. But it does have a language and library reference.

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

Oops. I read it. Maybe that's why i've become a language lawyer.


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

Right (I examined the code before i stuck my foot in my mouth).

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

I was around at the time, but I was lurking, and doing other things.
And also writing a DWARF2 debug info reader in python.
(It's a much bigger job than it sounds. DWARF2 is very very evil. Most end up 
being about 300k of C code. Mine was 2000 lines of python, or just about 10
time less. Just as quick, too. )

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

   >     1. break lots of code
Not unusual.
Too many years of working on C++ compilers and debuggers i guess.

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

Actually, this isn't true (that it's impossible).
If you really like, i'll take a few days of my spring break and write one
guaranteed to catch every single case. 
You can do it by looking at the byte code.
If you are trying to call function "append" with more than 1 argument on an
object whose type is a list, it's bad.

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

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

   FL> calling professional programmers idiots is not okay.
I didn't. I apologize if you think I did (It's also midterms week, so i'm a
little er, agitated, to say the least). 
Then again, i don't consider programmers who write code that depends on the
existence of bugs (knowingly, intentionally, and with the assumption that the 
bug will *never* ever be fixed, in such a way that if the bug was fixed, the
program would blow up in horrible ways) to be very professional.
Their is a world of difference between the people i was calling idiots (I had 
a particular group of windows programmers in mind), and a python programmer
who didn't know it was a bug.

   FL> </F>

   | -- 
   | http://www.python.org/mailman/listinfo/python-list