"Compile time" checking?

Discussion in 'Python' started by Qopit, Aug 10, 2005.

  1. Qopit

    Qopit Guest

    Hi there,

    I'm pretty new to Python and am trying to figure out how to get "will
    this code compile?"-like code checking. To me this is a pretty basic
    language/environment requirement, especially when working with large
    projects. It is *much* better to catch errors at "compile-time" rather
    than at run-time.

    One thing I've "found" is the PyChecker module (conveniently embedded
    in SPE), but it doesn't seem to do that great of a job. For example,
    the following simple program checks out perfectly as far as PyChecker
    is concerned:

    #----
    def tester(a,b,c):
    print "bogus test function",a,b,c
    tester(1,2,3) #this runs fine
    tester(1,2) #this obviously causes a run-time TypeError exception
    #----

    It seems to me that this should be an obvious catch for PyChecker. I
    suppose you could argue that you don't want PyChecker to bark at you
    any time an exception would be raised since you may intentionally be
    causing exceptions, but this one seems a pretty simple and obvious one
    to catch.

    My questions are:
    - Am I missing something with my tester example?
    - Are there other code-checking options other than PyChecker?

    Any other comments appreciated (aside from things like "just right good
    code that doesn't have bugs like that" :) ).

    Thanks!
     
    Qopit, Aug 10, 2005
    #1
    1. Advertising

  2. Qopit

    phil hunt Guest

    On 10 Aug 2005 08:53:15 -0700, Qopit <> wrote:
    >Hi there,
    >
    >I'm pretty new to Python and am trying to figure out how to get "will
    >this code compile?"-like code checking.


    Why not just find out, by trying to compile it? :)


    --
    Email: zen19725 at zen dot co dot uk
     
    phil hunt, Aug 10, 2005
    #2
    1. Advertising

  3. Qopit wrote:

    > [snip]
    >
    > My questions are:
    > - Am I missing something with my tester example?
    > - Are there other code-checking options other than PyChecker?


    Try pylint

    --
    Benjamin Niemann
    Email: pink at odahoda dot de
    WWW: http://www.odahoda.de/
     
    Benjamin Niemann, Aug 10, 2005
    #3
  4. Qopit

    Guest Guest

    On 10 Aug 2005 08:53:15 -0700
    Qopit wrote:

    > def tester(a,b,c):
    > print "bogus test function",a,b,c
    > tester(1,2,3) #this runs fine
    > tester(1,2) #this obviously causes a run-time TypeError exception


    /tmp% cat >a.py
    def tester(a,b,c):
    print "bogus test function",a,b,c
    tester(1,2,3) #this runs fine
    tester(1,2) #this obviously causes a run-time TypeError exception
    /tmp% pychecker a.py
    Processing a...
    bogus test function 1 2 3
    Caught exception importing module a:
    File "/usr/lib/site-python/pychecker/checker.py", line 587, in setupMainCode()
    module = imp.load_module(self.moduleName, file, filename, smt)
    File "a.py", line 4
    tester(1,2) #this obviously causes a run-time TypeError exception
    TypeError: tester() takes exactly 3 arguments (2 given)

    Warnings...

    a:1: NOT PROCESSED UNABLE TO IMPORT
    /tmp% pychecker -V
    0.8.14

    --
    jk
     
    Guest, Aug 10, 2005
    #4
  5. Qopit

    Qopit Guest

    > Why not just find out, by trying to compile it? :)

    This will likely certify me as a python newbie, but... how do you mean?
    How do you compile a .py file?

    If you mean to .pyc by doing an import on it, that may work fine for
    the simple example I typed up earlier, but that is easy to bypass by
    slapping the offending line in a function. The sample below also
    passes PyChecker with not even a warning:

    #----
    def tester(a,b,c):
    print "bogus test function",a,b,c

    def try1():
    tester(1,2,3)
    def try2():
    tester(1,2) #still no error here
    #----

    Do you mean something different?

    Also - thanks for the pylint comment... haven't tried it yet. It would
    be nice to have the capability in an IDE like SPE, though.
     
    Qopit, Aug 10, 2005
    #5
  6. Qopit

    phil hunt Guest

    On 10 Aug 2005 12:01:01 -0700, Qopit <> wrote:
    >> Why not just find out, by trying to compile it? :)

    >
    >This will likely certify me as a python newbie, but... how do you mean?
    > How do you compile a .py file?


    At the command prompt:

    $ python yourfile.py

    This compiles it, then runs it.

    >If you mean to .pyc by doing an import on it,


    Indeed so.

    > that may work fine for
    >the simple example I typed up earlier, but that is easy to bypass by
    >slapping the offending line in a function. The sample below also
    >passes PyChecker with not even a warning:
    >
    >#----
    >def tester(a,b,c):
    > print "bogus test function",a,b,c
    >
    >def try1():
    > tester(1,2,3)
    >def try2():
    > tester(1,2) #still no error here
    >#----
    >
    >Do you mean something different?


    I've never used PyChecker myself, so can't comment on it.

    I've not personally had problems with the wrong number of argumnets
    to a function call -- they get caught at run-time and are easy
    enough to fix -- but I do sometimes get errors because a varialbe is
    the wrong time, e.g. a string when it should be an int.

    One problem I once encountered was wit this and I waasn't picking it
    up because my debugging code looked like this:

    if debug: print "v=%s" % (v,)

    Which of course prints the same output whether v is '2' or 2.

    For this reason I tend to debug print statements like this now:

    if debug: print "v=%s" % (v,)


    --
    Email: zen19725 at zen dot co dot uk
     
    phil hunt, Aug 10, 2005
    #6
  7. Qopit

    Qopit Guest

    How embarassing... thanks, jk. I grabbed a copy of pychecker v0.8.14
    directly (not the one in SPE) and it catches it exactly as you showed.
    Now I wonder why the SPE one doesn't catch it (and why it is sooo
    comparatively slow)!

    Now I'm running into another snag when checking some other code I have.
    Pychecker gets hung up on raw_input... it actually executes code
    rather than just checking it, it seems. For example, the snippet below
    hangs pychecker::

    #---
    while 1:
    x = raw_input("meh:")
    #---

    Curious.

    I'm going to look into some of the code checking capabilities (if
    present) of Komodo and Wing. Anyone familiar enough with their ability
    to comment?
     
    Qopit, Aug 10, 2005
    #7
  8. In <>, Qopit wrote:

    > Hi there,
    >
    > I'm pretty new to Python and am trying to figure out how to get "will
    > this code compile?"-like code checking. To me this is a pretty basic
    > language/environment requirement, especially when working with large
    > projects. It is *much* better to catch errors at "compile-time" rather
    > than at run-time.


    Might sound harsh, but then python ist the wrong language for you.

    > One thing I've "found" is the PyChecker module (conveniently embedded
    > in SPE), but it doesn't seem to do that great of a job. For example,
    > the following simple program checks out perfectly as far as PyChecker
    > is concerned:
    >
    > #----
    > def tester(a,b,c):
    > print "bogus test function",a,b,c
    > tester(1,2,3) #this runs fine
    > tester(1,2) #this obviously causes a run-time TypeError exception
    > #----
    >
    > It seems to me that this should be an obvious catch for PyChecker.


    It's just obviuos because you know that the first call to `tester()`
    doesn't change the name binding for `tester` to a callable object that
    also accepts just two parameters. You, as a human, can see easily the
    error here, but a program has to follow all possible control flows to be
    sure about that. And that's most of the time very complex and sometimes
    impossible. It's not enough to look just at the signature of the function.

    Simple (?) test::

    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.

    > Any other comments appreciated (aside from things like "just right good
    > code that doesn't have bugs like that" :) ).


    Compile it by running it and write unit tests.

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Aug 10, 2005
    #8
  9. In <>, Qopit wrote:

    > Now I'm running into another snag when checking some other code I have.
    > Pychecker gets hung up on raw_input... it actually executes code
    > rather than just checking it, it seems. For example, the snippet below
    > hangs pychecker::
    >
    > #---
    > while 1:
    > x = raw_input("meh:")
    > #---
    >
    > Curious.


    AFAIK `pylint` tries to avoid running the code.

    A common idiom to protect code from being executed, if the module is just
    imported opposed to executed as main module, is to write::

    def foo():
    # some code

    if __name__ == '__main__':
    foo()

    `__name__` is set to the module name if the module will be imported but to
    '__main__' if the module is directly executed.

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Aug 10, 2005
    #9
  10. Qopit

    Qopit Guest

    > 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
     
    Qopit, Aug 10, 2005
    #10
  11. Qopit

    Qopit Guest

    > if __name__ == '__main__':

    Yep - that does it... should have thought of that. Thanks.

    This works fine for pychecker with no hangage:
    #---
    if __name__ == "__main__":
    while 1:
    x = raw_input("meh:")
    #---
     
    Qopit, Aug 10, 2005
    #11
  12. Qopit

    Qopit Guest


    > if debug: print "v=%s" % (v,)


    Not that important, but I assume the first one was supposed to be:

    if debug: print "v=", s

    right?
     
    Qopit, Aug 11, 2005
    #12
  13. On 2005-08-11, Qopit <> wrote:
    >
    >> if debug: print "v=%s" % (v,)

    >
    > Not that important, but I assume the first one was supposed to be:
    >
    > if debug: print "v=", s
    >
    > right?


    http://docs.python.org/tut/node9.html#SECTION009100000000000000000

    --
    Grant Edwards grante Yow! .. Now KEN and BARBIE
    at are PERMANENTLY ADDICTED to
    visi.com MIND-ALTERING DRUGS...
     
    Grant Edwards, Aug 11, 2005
    #13
  14. On Wed, 10 Aug 2005 20:39:03 +0100, (phil hunt) wrote:
    [...]
    >
    >I've not personally had problems with the wrong number of argumnets
    >to a function call -- they get caught at run-time and are easy
    >enough to fix -- but I do sometimes get errors because a varialbe is
    >the wrong time, e.g. a string when it should be an int.
    >
    >One problem I once encountered was wit this and I waasn't picking it
    >up because my debugging code looked like this:
    >
    > if debug: print "v=%s" % (v,)
    >
    >Which of course prints the same output whether v is '2' or 2.
    >
    >For this reason I tend to debug print statements like this now:
    >
    > if debug: print "v=%s" % (v,)


    I usually prefer %r over %s for debug prints

    if debug: print "v=%r" % (v,)

    since it represents (repr's ;-) the v thing better

    >>> print 'v=%r' % 2

    v=2
    >>> print 'v=%r' % '2'

    v='2'

    Regards,
    Bengt Richter
     
    Bengt Richter, Aug 11, 2005
    #14
  15. Qopit

    phil hunt Guest

    On 10 Aug 2005 18:32:54 -0700, Qopit <> wrote:
    >
    >> if debug: print "v=%s" % (v,)

    >
    >Not that important, but I assume the first one was supposed to be:
    >
    > if debug: print "v=", s
    >
    >right?


    No, I'm trying to print (v) not (s).


    --
    Email: zen19725 at zen dot co dot uk
     
    phil hunt, Aug 11, 2005
    #15
  16. Qopit

    phil hunt Guest

    On Thu, 11 Aug 2005 02:35:40 GMT, Bengt Richter <> wrote:
    >On Wed, 10 Aug 2005 20:39:03 +0100, (phil hunt) wrote:
    >[...]
    >>
    >>I've not personally had problems with the wrong number of argumnets
    >>to a function call -- they get caught at run-time and are easy
    >>enough to fix -- but I do sometimes get errors because a varialbe is
    >>the wrong time, e.g. a string when it should be an int.
    >>
    >>One problem I once encountered was wit this and I waasn't picking it
    >>up because my debugging code looked like this:
    >>
    >> if debug: print "v=%s" % (v,)
    >>
    >>Which of course prints the same output whether v is '2' or 2.
    >>
    >>For this reason I tend to debug print statements like this now:
    >>
    >> if debug: print "v=%s" % (v,)

    >
    >I usually prefer %r over %s for debug prints
    >
    > if debug: print "v=%r" % (v,)


    Arrghh!! Yes, that's what I meant to write.


    --
    Email: zen19725 at zen dot co dot uk
     
    phil hunt, Aug 11, 2005
    #16
  17. Just as a note... Pylint is integrated within pydev (http://pydev.sf.net)

    Cheers,

    Fabio

    Qopit wrote:

    >>Why not just find out, by trying to compile it? :)
    >>
    >>

    >
    >This will likely certify me as a python newbie, but... how do you mean?
    > How do you compile a .py file?
    >
    >If you mean to .pyc by doing an import on it, that may work fine for
    >the simple example I typed up earlier, but that is easy to bypass by
    >slapping the offending line in a function. The sample below also
    >passes PyChecker with not even a warning:
    >
    >#----
    >def tester(a,b,c):
    > print "bogus test function",a,b,c
    >
    >def try1():
    > tester(1,2,3)
    >def try2():
    > tester(1,2) #still no error here
    >#----
    >
    >Do you mean something different?
    >
    >Also - thanks for the pylint comment... haven't tried it yet. It would
    >be nice to have the capability in an IDE like SPE, though.
    >
    >
    >



    --
    Fabio Zadrozny
    ------------------------------------------------------
    Software Developer

    ESSS - Engineering Simulation and Scientific Software
    www.esss.com.br

    PyDev - Python Development Enviroment for Eclipse
    pydev.sf.net
    pydev.blogspot.com
     
    Fabio Zadrozny, Aug 11, 2005
    #17
  18. In <>, Qopit wrote:

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


    Well it's a contrived example. But taking a function or method and wrap
    it with some other function or method isn't that uncommon. For methods
    there is even syntactic sugar: decorator syntax.

    Here's a more useful dynamic function wrapping::

    def debug_trace(func):
    def wrapper(*args, **kwargs):
    print 'Calling %s' % func.__name__
    print 'args: %r' % (args,)
    print 'kwargs: %r' % kwargs
    func(*args, **kwargs)
    return wrapper

    def test(a, b, c):
    print 'just a test', a, b, b

    test = debug_trace(test)

    test(1, 2, 3)
    test(1, 2)

    Here it's quite clear to a human reader that the wrapping doesn't change
    the number of arguments. But it's harder to let a program figure this out.

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Aug 11, 2005
    #18
  19. Qopit

    Guest

    Hi,

    If you find something like that, please report it to the bug tracker of
    SPE with an easy example. Also mention that PyChecker is slow, I might
    have another look at it.

    Probably I need to update the version, as SPE ships with the 0.8.13
    version. I don't think it's possible to get it already in the next
    release as now SVN is frozen for new features, as I probably will
    release sunday the new SPE. The screenshots are already updated.

    BTW, maybe a time for a poll: which checker is better? PyChecker or
    PyLint?

    Stani

    http://pythonide.stani.be (mind the new url!)
    http://pythonide.stani.be/screenshots
    http://developer.berlios.de/bugs/?group_id=4161 (SPE bugtracker)
     
    , Aug 13, 2005
    #19
  20. Since Python does not use manifest typing, there's not much you can do about
    this, but typeless languages like this are great if you're using a process
    that finds the errors the compiler would otherwise find. I'm referring, of
    course, to Test Driven Development (TDD).

    If you do TDD, you won't miss compile-time checking much. In fact, the extra
    kruft that manifest typing requires is an annoying burden when doing TDD, so
    Python is a breath of fresh air in this regard.

    On 10 Aug 2005 08:53:15 -0700, "Qopit" <> wrote:

    >Hi there,
    >
    >I'm pretty new to Python and am trying to figure out how to get "will
    >this code compile?"-like code checking. To me this is a pretty basic
    >language/environment requirement, especially when working with large
    >projects. It is *much* better to catch errors at "compile-time" rather
    >than at run-time.
    >
    >One thing I've "found" is the PyChecker module (conveniently embedded
    >in SPE), but it doesn't seem to do that great of a job. For example,
    >the following simple program checks out perfectly as far as PyChecker
    >is concerned:
    >
    >#----
    >def tester(a,b,c):
    > print "bogus test function",a,b,c
    >tester(1,2,3) #this runs fine
    >tester(1,2) #this obviously causes a run-time TypeError exception
    >#----
    >
    >It seems to me that this should be an obvious catch for PyChecker. I
    >suppose you could argue that you don't want PyChecker to bark at you
    >any time an exception would be raised since you may intentionally be
    >causing exceptions, but this one seems a pretty simple and obvious one
    >to catch.
    >
    >My questions are:
    >- Am I missing something with my tester example?
    >- Are there other code-checking options other than PyChecker?
    >
    >Any other comments appreciated (aside from things like "just right good
    >code that doesn't have bugs like that" :) ).
    >
    >Thanks!
     
    Steve Jorgensen, Aug 13, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ben Ingram
    Replies:
    6
    Views:
    393
    red floyd
    Jan 30, 2004
  2. jlara

    Checking endianess in compile time

    jlara, Jun 6, 2005, in forum: C Programming
    Replies:
    7
    Views:
    383
    Michael Mair
    Jun 7, 2005
  3. Urs Thuermann

    checking constant conditions on compile time

    Urs Thuermann, Mar 27, 2006, in forum: C Programming
    Replies:
    14
    Views:
    731
    Urs Thuermann
    Mar 31, 2006
  4. Dave Rahardja
    Replies:
    4
    Views:
    589
    Dave Rahardja
    Nov 21, 2005
  5. Carter
    Replies:
    2
    Views:
    507
    Carter
    Mar 4, 2009
Loading...

Share This Page