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
pylint, pychecker, pydev. Maybe more.
Diez
Robert Kern
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
Robert Kern <rober...@gmail.com> 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 (aa...@pythoncraft.com) <*> 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
> In article<mailman.2279.1256851...@python.org>,
> Robert Kern<rober...@gmail.com> 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. :-)
exa...@twistedmatrix.com
>In article <mailman.2279.1256851...@python.org>,
>Robert Kern <rober...@gmail.com> 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
Ben Finney
> Coincidentally, I tried PyFlakes yesterday and was unimpressed with
> the way it doesn't work with "import *".
That's pretty much the reason to avoid ‘from foo import *’: it makes the
namespace indeterminate without actually running the code. Just as much
a problem for the human reader as for a reader like ‘pyflakes’.
But you knew that already.
--
\ “Humanity has advanced, when it has advanced, not because it |
`\ has been sober, responsible, and cautious, but because it has |
_o__) been playful, rebellious, and immature.” —Tom Robbins |
Ben Finney
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)?
Ben Finney
That's easy enough to check:
=====
$ cat namespace_clobber.py
from foo import *
$ pyflakes namespace_clobber.py
namespace_clobber.py:1: 'from foo import *' used; unable to detect undefined names
=====
--
\ “There are no significant bugs in our released software that |
`\ any significant number of users want fixed.” —Bill Gates, |
_o__) 1995-10-23 |
Ben Finney
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.
Bruno Desthuilliers
> On 2009-10-29 16:52 PM, Aahz wrote:
>> 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. :-)
>
Lie Ryan
> In article <mailman.2279.1256851...@python.org>,
> Robert Kern <rober...@gmail.com> 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.
Fabio Zadrozny
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.
--
Alan Franzoni
contact me at public@[mysurname].eu
Singletoned
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.