467,228 Members | 1,438 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,228 developers. It's quick & easy.

PyChecker does STATIC analysis?

If I run PyChecker on the following program, stored in xtry.py,

m = 10000000
k = 0
for i in xrange(m):
k = k + i
print k
x = range(3)
print x[3]

the output is

49999995000000

Warnings...

xtry:1: NOT PROCESSED UNABLE TO IMPORT
Processing xtry...
Caught exception importing module xtry:
File "H:\Energy\rao\python\Lib\site-packages\pychecker\checker.py",
line 530, in setupMainCode()
module = imp.load_module(self.moduleName, file, filename, smt)
File "xtry.py", line 7
print x[3]
IndexError: list index out of range
I am surprised that PyChecker actually needs to execute the code block

for i in xrange(m):
k = k + i
print k

before finding the out-of-bounds error. I have seen PyChecker
described as a "static analysis" tool, and it does find some problems
that such a tool ought to. But it seems that for the simple program I
have shown, it basically runs the program, and I could just run the
Python program to find the same errors. An aspect of Python
programming that sometimes frustrates me is that a program will run,
perhaps for a few minutes, before stopping because of a misspelled
variable or an out-of-bounds variable. It seems that currently,
PyChecker will not solve this problem. I wish there were a tool that
did (and would be willing to pay for it).

The Lahey/Fujitsu Fortran 95 compiler is able to catch the
out-of-bounds error at COMPILE time for an analogous Fortran program.
Jul 18 '05 #1
  • viewed: 1939
Share:
4 Replies
be*******@aol.com wrote:
before finding the out-of-bounds error. I have seen PyChecker
described as a "static analysis" tool, and it does find some problems
that such a tool ought to. But it seems that for the simple program I
have shown, it basically runs the program, and I could just run the
Python program to find the same errors. An aspect of Python
programming that sometimes frustrates me is that a program will run,
perhaps for a few minutes, before stopping because of a misspelled
variable or an out-of-bounds variable. It seems that currently,
PyChecker will not solve this problem. I wish there were a tool that
did (and would be willing to pay for it).

The Lahey/Fujitsu Fortran 95 compiler is able to catch the
out-of-bounds error at COMPILE time for an analogous Fortran program.


while there might be not-so-obvious cases that can be found using static
analysis, the halting problem also applies here: There is no such thing as
a automated analysis that finds out if your prgram is going to die or not.

So automatically running a program as part of the analysis is as valid as
any other technique - as long as there are no permantent sideeffects (you
don't want your partitioning code accidentially ruin your hd while
developing...)

Given the fact that nobody prevents you from doing this:
xrange = lambda x: [1,2,3,4,5]
x = range(3)
print x[3]

4

you can fool a static analysis, I wont blame Pychecker too much.
--
Regards,

Diez B. Roggisch
Jul 18 '05 #2
Diez B. Roggisch wrote:
xrange = lambda x: [1,2,3,4,5]


Oops - that was supposed to be

range = lambda x: [1,2,3,4,5]

of course... I'm so used to prefering xrange over range, I confused
myself...

--
Regards,

Diez B. Roggisch
Jul 18 '05 #3
be*******@aol.com wrote:
If I run PyChecker on the following program, stored in xtry.py,

m = 10000000
k = 0
for i in xrange(m):
k = k + i
print k
x = range(3)
print x[3]

the output is

49999995000000

Warnings...

xtry:1: NOT PROCESSED UNABLE TO IMPORT
Processing xtry...
Caught exception importing module xtry:
File "H:\Energy\rao\python\Lib\site-packages\pychecker\checker.py",
line 530, in setupMainCode()
module = imp.load_module(self.moduleName, file, filename, smt)
File "xtry.py", line 7
print x[3]
IndexError: list index out of range
I am surprised that PyChecker actually needs to execute the code block

for i in xrange(m):
k = k + i
print k

before finding the out-of-bounds error. I have seen PyChecker
described as a "static analysis" tool, and it does find some problems
that such a tool ought to. But it seems that for the simple program I
have shown, it basically runs the program, and I could just run the
Python program to find the same errors. An aspect of Python
programming that sometimes frustrates me is that a program will run,
perhaps for a few minutes, before stopping because of a misspelled
variable or an out-of-bounds variable. It seems that currently,
PyChecker will not solve this problem. I wish there were a tool that
did (and would be willing to pay for it).

The Lahey/Fujitsu Fortran 95 compiler is able to catch the
out-of-bounds error at COMPILE time for an analogous Fortran program.


You're right but now try on :

def main():
m = 10000000
k = 0
for i in xrange(m):
k = k + i
print k
x = range(3)
print x[3]

if __name__=='__main__':
main()

And it should work !
PyChecker import your file and does not just do a source checking...

--
Yermat
Jul 18 '05 #4

beliavsky> If I run PyChecker on the following program, stored in xtry.py,

beliavsky> m = 10000000
beliavsky> k = 0
beliavsky> for i in xrange(m):
beliavsky> k = k + i
beliavsky> print k
beliavsky> x = range(3)
beliavsky> print x[3]

beliavsky> the output is

beliavsky> 49999995000000

beliavsky> Warnings...

beliavsky> xtry:1: NOT PROCESSED UNABLE TO IMPORT
...

beliavsky> I am surprised that PyChecker actually needs to execute the
beliavsky> code block

beliavsky> for i in xrange(m):
beliavsky> k = k + i
beliavsky> print k

beliavsky> before finding the out-of-bounds error.

Try modifying your code to this:

if __name__ == "__main__":
m = 10000000
k = 0
for i in xrange(m):
k = k + i
print k
x = range(3)
print x[3]

PyChecker simply imports your module. Importing a module causes the code at
the top level to be executed.

beliavsky> The Lahey/Fujitsu Fortran 95 compiler is able to catch the
beliavsky> out-of-bounds error at COMPILE time for an analogous Fortran
beliavsky> program.

Python is just slightly more dynamic than Fortran, and I'm sure the
Lahey/Fujitsu compiler has had a few more man-years of development put into
it than PyChecker. As an example of the former point, note that PyChecker
can't assume that the output of range(3) is a list of 3 elements. Another
module may have modified builtins before the code was executed.

Skip
Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Pedro Werneck | last post: by
1 post views Thread by Neal Norwitz | last post: by
12 posts views Thread by Stephen Ferg | last post: by
1 post views Thread by Olaf Meding | last post: by
21 posts views Thread by Philippe Fremy | last post: by
reply views Thread by simon.dahlbacka@gmail.com | last post: by
1 post views Thread by Neal Norwitz | last post: by
4 posts views Thread by Anthony Greene | last post: by
1 post views Thread by Edward K. Ream | last post: by
reply views Thread by Adict | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.