will python 3000 break my code?
dan at cgsoftware.com
Thu Mar 2 00:17:05 CET 2000
>>>>> "MF" == Martijn Faassen <m.faassen at vet.uu.nl> writes:
>> 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
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'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
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.
More information about the Python-list