PyChecker messages

[Frans Englich]

Hello,

I take PyChecker partly as an recommender of good coding practice, but I
cannot make sense of some of the messages. For example:

runner.py:878: Function (main) has too many lines (201)

What does this mean? Cannot functions be large? Or is it simply an advice that
functions should be small and simple?
runner.py:200: Function (detectMimeType) has too many returns (11)

The function is simply a long "else-if" clause, branching out to different
return statements. What's wrong? It's simply a "probably ugly code" advice?
A common message is these:

runner.py:41: Parameter (frame) not used

But I'm wondering if there's cases where this cannot be avoided. For example,
this signal handler:

#-------------------------------------------
def signalSilencer( signal, frame ):
"""
Dummy signal handler for avoiding ugly
tracebacks when the user presses CTRL+C.
"""
print "Received signal", str(signal) + ", exiting."
sys.exit(1)
#-------------------------------------------

_must_ take two arguments; is there any way that I can make 'frame' go away?
Also, another newbie question: How does one make a string stretch over several
lines in the source code? Is this the proper way?

print "asda asda asda asda asda asda " \
"asda asda asda asda asda asda " \
"asda asda asda asda asda asda"
Thanks in advance,

Frans

PS. Any idea how to convert any common time type to W3C XML Schema datatype
duration?

[Steven Bethard]

Frans Englich wrote:

Also, another newbie question: How does one make a string stretch over several
lines in the source code? Is this the proper way?
(1) print "asda asda asda asda asda asda " \
"asda asda asda asda asda asda " \
"asda asda asda asda asda asda"

A couple of other options here:

(2)
print """asda asda asda asda asda asda
asda asda asda asda asda asda
asda asda asda asda asda asda"""

(3)
print """\
asda asda asda asda asda asda
asda asda asda asda asda asda
asda asda asda asda asda asda"""

(4)
print ("asda asda asda asda asda asda "
"asda asda asda asda asda asda "
"asda asda asda asda asda asda")

Note that backslash continuations (1) are on Guido's list of "Python
Regrets", so it's likely they'll disappear with Python 3.0 (Of course
this is 3-5 years off.)

I typically use either (3) or (4), but of course the final choice is up
to you.

Steve

[Roger Binns]

> runner.py:878: Function (main) has too many lines (201)

What does this mean? Cannot functions be large? Or is it simply an advice that
functions should be small and simple?
It is advice.
runner.py:200: Function (detectMimeType) has too many returns (11)

The function is simply a long "else-if" clause, branching out to different
return statements. What's wrong? It's simply a "probably ugly code" advice?
That is also advice. Generally you use a dict of functions, or some other
structure to lookup what you want to do.
_must_ take two arguments; is there any way that I can make 'frame' go away?
Yes, you can name it just _ (underscore). There are a few other names like
that that are ignored. (Check the doc).
Also, another newbie question: How does one make a string stretch over several
lines in the source code? Is this the proper way?

print "asda asda asda asda asda asda " \
"asda asda asda asda asda asda " \
"asda asda asda asda asda asda"

Depends what you are trying to achieve. Look at triple quoting as well.

Roger

[Eric Brunel]

Frans Englich wrote:

Hello,

I take PyChecker partly as an recommender of good coding practice, but I
cannot make sense of some of the messages. For example:

runner.py:878: Function (main) has too many lines (201)

What does this mean? Cannot functions be large? Or is it simply an advice that
functions should be small and simple?
This is an advice. You can set the number after which the warning is triggered
via the maxLines option in your .pycheckrc file.
runner.py:200: Function (detectMimeType) has too many returns (11)

The function is simply a long "else-if" clause, branching out to different
return statements. What's wrong? It's simply a "probably ugly code" advice?
Same thing; the corresponding option in .pycheckrc is maxReturns. Other options
that may interest you are maxBranches, maxArgs, maxLocals and maxReferences.
Please see PyChecker's documentation for more details.
A common message is these:

runner.py:41: Parameter (frame) not used

But I'm wondering if there's cases where this cannot be avoided. For example,
this signal handler:

#-------------------------------------------
def signalSilencer( signal, frame ):
"""
Dummy signal handler for avoiding ugly
tracebacks when the user presses CTRL+C.
"""
print "Received signal", str(signal) + ", exiting."
sys.exit(1)
#-------------------------------------------

_must_ take two arguments; is there any way that I can make 'frame' go away?

See/set the unusedNames option in .pycheckrc; this is a list of names for which
this kind of warnings are not triggered. If you set for example:

unusedNames = [ 'dummy' ]

in .pycheckrc and if you define your function with:

def signalSilencer(signal, dummy):
...

the warning will not be triggered.

BTW, if your signal handler is just here to catch Ctrl-C, you'd better do a
try/except on KeyboardInterrupt...

HTH
--
- Eric Brunel <eric (underscore) brunel (at) despammed (dot) com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com

[Sylvain Thenault]

On Tue, 11 Jan 2005 06:54:54 +0000, Frans Englich wrote:

Hello,
Hi
I take PyChecker partly as an recommender of good coding practice

You may alos be interested by Pylint [1].

Pylint is less advanced in bug detection than pychecker, but imho its good
coding practice detection is more advanced and configurable (as the pylint
author, i'm a little biased... ;), including naming conventions, code
duplication, bad code smells, presence of docstring, etc...
Side note : I wish that at some point we stop duplicated effort between
pylint and pychecker. In my opinion that would be nice if each one focus
on its strenghs (as i said bugs detection for pychecker and convention
violation / bad code smell for pylint). That would be even better if both
tools could be merged in one, but (at least last time I took a look at
pychecker) the internal architecture is so different that it's not an easy
task today. Any thoughts ?

[1] http://www.logilab.org/projects/pylint

--
Sylvain Thénault LOGILAB, Paris (France).

http://www.logilab.com http://www.logilab.fr http://www.logilab.org

[Cameron Laird]

In article <lq************@home.rogerbinns.com>,
Roger Binns <ro****@rogerbinns.com> wrote:

[Ben Sizer]

But you could use a dict of return values, or even just assigning a
different return value in each if clause. The end result is that you
have a single well-defined exit point from the function, which is
generally considered to be preferable.

[John Roth]

"Ben Sizer" <ky*****@gmail.com> wrote in message
news:11*********************@c13g2000cwb.googlegro ups.com...

But you could use a dict of return values, or even just assigning a
different return value in each if clause. The end result is that you
have a single well-defined exit point from the function, which is
generally considered to be preferable.
Preferable, but not any form of an absolute. "Single Exit"
was one of the recommendations from the early structured
program work back in the 70s, and the industry has long
since sent it to the dustbin of history.

The issue is a simple one of clarity, and woodenly applying
the single exit rule where it doesn't belong frequently
winds up creating nested if-elif-else structures and extranious
flag variables.

If an embedded return isn't clear, the method probably
needs to be refactored with "extract method" a few
times until it is clear.

John Roth

[Cameron Laird]

In article <11*********************@c13g2000cwb.googlegroups. com>,
Ben Sizer <ky*****@gmail.com> wrote:

But you could use a dict of return values, or even just assigning a
different return value in each if clause. The end result is that you
have a single well-defined exit point from the function, which is
generally considered to be preferable.

Well, no; I'm trying to say exactly that there are times when "a dict
of return values" only adds complexity. Or perhaps I'm missing a bet-
way to code:

def condition_label():
if x13.fluid_level() > lower_threshhold:
return "OK"
if user in restricted_list:
return "Ask for help"
if not current_time.in_range(beginning, end):
return "Uncorrectable exception reported"
...

When conditions live in a space with higher dimensionality than any
handy immutable range, no dict-ification is a benefit.