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

[kj]

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

 

[Mick Krippendorf]

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

By using pylint.

Mick.

 

[Diez B. Roggisch]

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

 

[Robert Kern]

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

 

[Aahz]

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 ([email protected]) <*> 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

 

[Robert Kern]

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

 

[exarkun]

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

 

[Albert Hopkins]

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)?

 

[alex23]

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/

 

[Bruno Desthuilliers]

Robert Kern a écrit :

On 2009-10-29 16:52 PM, Aahz wrote: (snip)

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

+1 QOTW

 

[Lie Ryan]

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.

 

[Fabio Zadrozny]

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

 

[Alan Franzoni]

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.

 

[Singletoned]

Robert Kern a écrit :> On 2009-10-29 16:52 PM, Aahz wrote:
(snip)


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