will python 3000 break my code?

Daniel Berlin dan at cgsoftware.com
Wed Mar 1 18:17:05 EST 2000


>>>>> "MF" == Martijn Faassen <m.faassen at vet.uu.nl> writes:

   MF> [snip]

   MF> [effbot]
   >> 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.

   MF> Are you sure you've thought this through? How would you know the type
   MF> of an object is a list? 

This can only be done at runtime, of course, without getting into very heavy
analysis.
However, i can instrument the code rather easily, so that even really tricky
things would still tell you where the problem is really being generated (IE
where foo became an append method, which is why when you passed it to some
random function that called it's arguments, you had problems.


That's the only way to catch things passed as arguments.


I was talking about a tool that both looked at the bytecode, and instrumented 
it.
It's automatic in the same way "BoundsChecker" is an automatic tool.

   MF>That's the tricky part, to know you're dealing
   MF> with a list and not something else that happens to have a method
   MF> 'append'.
Right.
I realize this.

   MF> Anyway, if you can write a static typechecker for Python in a few days
   MF> during spring break the types-sig will be happy; doing this isn't
   MF> *that* much easier than writing a full fledged static typechecker, it
   MF> seems to me.
God no. I shudder at the thought of the analysis required.

   MF> Regards,

   MF> Martijn

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




More information about the Python-list mailing list