Aaaargh! "global name 'eggz' is not defined"

Discussion in 'Python' started by kj, Oct 29, 2009.

  1. kj

    kj Guest

    How can one check that a Python script is lexically correct?

    As my Python apps grow in complexity and execution, I'm finding it
    more often the situation in which a program dies after a lengthy
    (i.e. expensive) run because the execution reaches, say, a typo.
    Of course, this typo needs to be fixed, but I'd like to find out
    about it before I waste hours on a run that is bound to fail. Is
    there any way to do this? I imagine the answer is no, because
    given Python's scoping rules, the interpreter can't know about
    these things at compile time, but I thought I'd ask.

    TIA!

    kynn
    kj, Oct 29, 2009
    #1
    1. Advertising

  2. kj wrote:
    > How can one check that a Python script is lexically correct?


    By using pylint.

    Mick.
    Mick Krippendorf, Oct 29, 2009
    #2
    1. Advertising

  3. kj schrieb:
    > How can one check that a Python script is lexically correct?
    >
    > As my Python apps grow in complexity and execution, I'm finding it
    > more often the situation in which a program dies after a lengthy
    > (i.e. expensive) run because the execution reaches, say, a typo.
    > Of course, this typo needs to be fixed, but I'd like to find out
    > about it before I waste hours on a run that is bound to fail. Is
    > there any way to do this? I imagine the answer is no, because
    > given Python's scoping rules, the interpreter can't know about
    > these things at compile time, but I thought I'd ask.


    pylint, pychecker, pydev. Maybe more.

    Diez
    Diez B. Roggisch, Oct 29, 2009
    #3
  4. kj

    Robert Kern Guest

    On 2009-10-29 15:48 PM, kj wrote:
    >
    > How can one check that a Python script is lexically correct?
    >
    > As my Python apps grow in complexity and execution, I'm finding it
    > more often the situation in which a program dies after a lengthy
    > (i.e. expensive) run because the execution reaches, say, a typo.
    > Of course, this typo needs to be fixed, but I'd like to find out
    > about it before I waste hours on a run that is bound to fail. Is
    > there any way to do this? I imagine the answer is no, because
    > given Python's scoping rules, the interpreter can't know about
    > these things at compile time, but I thought I'd ask.


    I like using pyflakes. It catches most of these kinds of typo errors, but is
    much faster than pylint or pychecker. That means I can hook up a key macro to
    run it in my editor so I can use it frequently without hesitation (e.g. in Vim,
    it is my makeprg for Python files).

    It doesn't catch other stupid errors, of course. Try your best to write small,
    simple, quick-to-run tests for each piece of functionality that you are working
    on. Test the methods you've just coded independently of the rest of your code
    using that small test before doing full hours-long runs of the whole program.
    Bonus: you now have a suite of unit tests.

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
    Robert Kern, Oct 29, 2009
    #4
  5. kj

    Aahz Guest

    In article <>,
    Robert Kern <> wrote:
    >
    >I like using pyflakes. It catches most of these kinds of typo errors, but is
    >much faster than pylint or pychecker.


    Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    way it doesn't work with "import *".
    --
    Aahz () <*> http://www.pythoncraft.com/

    "You could make Eskimos emigrate to the Sahara by vigorously arguing --
    at hundreds of screens' length -- for the wonder, beauty, and utility of
    snow." --PNH to rb in r.a.sf.f
    Aahz, Oct 29, 2009
    #5
  6. kj

    Robert Kern Guest

    On 2009-10-29 16:52 PM, Aahz wrote:
    > In article<>,
    > Robert Kern<> wrote:
    >>
    >> I like using pyflakes. It catches most of these kinds of typo errors, but is
    >> much faster than pylint or pychecker.

    >
    > Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    > way it doesn't work with "import *".


    I consider "import *" the first error to be fixed, so it doesn't bother me much. :)

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
    Robert Kern, Oct 29, 2009
    #6
  7. kj

    Guest

    On 09:52 pm, wrote:
    >In article <>,
    >Robert Kern <> wrote:
    >>
    >>I like using pyflakes. It catches most of these kinds of typo errors,
    >>but is
    >>much faster than pylint or pychecker.

    >
    >Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    >way it doesn't work with "import *".


    Consider it (some very small, I'm sure) motivation to stop using "import
    *", which is itself only something used in unimpressive software. ;)

    Jean-Paul
    , Oct 29, 2009
    #7
  8. On Thu, 2009-10-29 at 17:27 -0500, Robert Kern wrote:
    > I consider "import *" the first error to be fixed, so it doesn't
    > bother me much. :)


    But does pyflakes at least *warn* about the use of "import *" (I've
    never used it so just asking)?
    Albert Hopkins, Oct 30, 2009
    #8
  9. kj

    alex23 Guest

    kj <> wrote:
    > As my Python apps grow in complexity and execution, I'm finding it
    > more often the situation in which a program dies after a lengthy
    > (i.e. expensive) run because the execution reaches, say, a typo.


    This is a good reason for breaking your program down into testable
    units and verifying they behave as expected before a long execution
    phase. You can get a long way with unittest in the stdlib, but I
    personally prefer using nose[1], I find the tests to be less weighty
    in boilerplate.

    1: http://code.google.com/p/python-nose/
    alex23, Oct 30, 2009
    #9
  10. Robert Kern a écrit :
    > On 2009-10-29 16:52 PM, Aahz wrote:

    (snip)
    >> Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    >> way it doesn't work with "import *".

    >
    > I consider "import *" the first error to be fixed, so it doesn't bother
    > me much. :)
    >

    +1 QOTW
    Bruno Desthuilliers, Oct 30, 2009
    #10
  11. kj

    Lie Ryan Guest

    Aahz wrote:
    > In article <>,
    > Robert Kern <> wrote:
    >> I like using pyflakes. It catches most of these kinds of typo errors, but is
    >> much faster than pylint or pychecker.

    >
    > Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    > way it doesn't work with "import *".


    If only IDLE's Intellisense worked without having to run the code first,
    perhaps I wouldn't have abandoned using IDE altogether to write codes
    and used vim/gedit/notepad/whateverpad instead. I've felt liberlized
    since going plaintext.
    Lie Ryan, Oct 30, 2009
    #11
  12. On Thu, Oct 29, 2009 at 6:48 PM, kj <> wrote:
    >
    > How can one check that a Python script is lexically correct?
    >
    > As my Python apps grow in complexity and execution, I'm finding it
    > more often the situation in which a program dies after a lengthy
    > (i.e. expensive) run because the execution reaches, say, a typo.
    > Of course, this typo needs to be fixed, but I'd like to find out
    > about it before I waste hours on a run that is bound to fail.  Is
    > there any way to do this?  I imagine the answer is no, because
    > given Python's scoping rules, the interpreter can't know about
    > these things at compile time, but I thought I'd ask.
    >


    Pydev has a code-analysis feature which works analyzing the code while
    you're typing. See: http://pydev.org/manual_adv_code_analysis.html

    Cheers,

    Fabio
    Fabio Zadrozny, Oct 30, 2009
    #12
  13. On 10/29/09 9:48 PM, kj wrote:
    > How can one check that a Python script is lexically correct?


    You can use a pseudo-static analyzer like pyflakes, pylint or pydoctor.

    Or, better, you can avoid wild imports, excessive local or global
    namespace manipulation, and break you program in smaller parts and write
    unit tests for them.

    Typos are very common but should very easy to catch. If you're not
    catching them until a very long run of your program, then your code
    coverage is probably too low.

    --
    Alan Franzoni
    contact me at public@[mysurname].eu
    Alan Franzoni, Oct 31, 2009
    #13
  14. kj

    Singletoned Guest

    On Oct 30, 8:53 am, Bruno Desthuilliers <bruno.
    > wrote:
    > Robert Kern a écrit :> On 2009-10-29 16:52 PM, Aahz wrote:
    > (snip)
    > >> Coincidentally, I tried PyFlakes yesterday and was unimpressed with the
    > >> way it doesn't work with "import *".

    >
    > > I consider "import *" the first error to be fixed, so it doesn't bother
    > > me much. :)

    >
    > +1 QOTW


    Bruno, do you actually get to decide the QOTW? Because everytime you `
    +1 QOTW` it gets to be the QOTW.

    Ed

    BTW I was the grateful recipient of your vote the other week.
    Singletoned, Nov 3, 2009
    #14
    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. anti-guru
    Replies:
    2
    Views:
    7,813
    anti-guru
    Sep 2, 2004
Loading...

Share This Page