"Compile time" checking?

Qopit russandheather at gmail.com
Wed Aug 10 23:12:59 CEST 2005


>  def tester(a, b, c):
>      global tester
>      print "bogus test function", a, b, c
>      def tester(a, b):
>          print "other test function", a, b
>
>  tester(1, 2, 3) # This runs fine.
>  tester(1, 2)    # This too.

Interesting example.  In that case, pychecker does spit out a warning
since it has trouble deciphering the redefinition.  I have no problem
whatsoever with a compiler/code-checker getting confused in such an
oddball situation.  As you say, it is difficult for an automated
process to follow such flows.  A warning is fine here (as I got with
the "proper" pychecker on my initial example - it did easily catch what
I thought should have been, and was, obvious).

With your example, I was curious how pychecker would deal with it if
you altered the flow a bit so that all calls would/should make sense in
what seems to me to be logical locals order, and tried this:

#---
def tester(a, b, c):
    global tester
    print "bogus test function", a, b, c
    def tester(a, b):
      print "other test function", a, b
    tester(1, 2) #no pychecker complaint since local
tester(1, 2, 3) # pychecker complains here (?)
#---

I'm a bit confused why pychecker complained where it did - I don't get
how it got the 2 arg version at that point, but I actually don't really
care that much due to the weirdness level of this code.  A compiler (or
code-checker) warning on this code is perfectly acceptable to me.  I'm
a big fan of Python's ability to easily rebind everything in sight, but
this particular usage seems like a strange abuse I wouldn't expect a
code-checker to be able to figure out.  I'll just avoid writing
confusing code like that... it's not only confusing to a program, but
to a human as well!  Dynamically massacring a function definition (as
opposed to just rebinding a new implementation) like that seems odd to
me.

> Compile it by running it and write unit tests.

... sure, that works,  I'm just used to the integrated tools I've had
available to me for the last 15 years to help me write more robust code
waaaay faster than having to unit test a zillion blocks of code when
you change a single definition somewhere.

PyChecker seems like it may fit the bill right now... just need to try
it some more and figure out how to get around that weird raw_input
thing.  The basis for my first post was a jerk what-the-heck reaction
to the fact that it seemed that pychecker didn't get the simple arg
count mismatch error, but jk showed that that was wrong and I just have
to sort out something with SPE.

Cheers,
Russ




More information about the Python-list mailing list