pychecker proposal

[Nick Jacobson]

I think that PyChecker should be part of the "batteries included"
library that comes with Python. It can be a very useful tool for
catching errors and bad style.

If it were in the standard library, newbies would be aware of it
sooner. It could catch some of their mistakes, making for a smoother
learning curve. e.g. when I started learning Python, I named a
variable str, which caused an exception when I called str() in an
unrelated part of the code. This led to some confusion...PyChecker
would have flagged it as shadowing a built-in function.

What do you guys think?

 

[Roger Binns]

I think that PyChecker should be part of the "batteries included"
library that comes with Python. It can be a very useful tool for
catching errors and bad style.

If it were in the standard library, newbies would be aware of it
sooner.

I would prefer a "lint" mode to the Python interpretter that runs
in a full warnings mode, using both static analysis that pychecker
does as well as any dynamic analysis that could be done. I
don't even care if it runs at half the speed of normal Python.

Roger

 

[Anton Vredegoor]

I think that PyChecker should be part of the "batteries included"
library that comes with Python. It can be a very useful tool for
catching errors and bad style.

Here are a few thoughts on this.

a) How often will it be used by how many people?

While I acknowledge PyCheckers usefulness, I tend not to use it very
often. Maybe I should use it more, or maybe Pythons executable pseudo
code quality forces PyChecker to fall in the "below 1% of use cases"
category.

b) Is it actively supported by people that are willing to release it
synchronously with Pythons updates?

c) Is its license compatible with Python?

d) Are there other packages that should be included which have more
urgency or that would be a better tradeoff for adding to the space
that a Python standard distribution takes?

Pychecker is not a very big package, which would be an argument in
favor of including it.

OTOH, some time ago I was at an Apple Itunes demonstration. I was
happy to immediately start a Python shell on a mac, but I also noticed
the conspicuous absence of an impressive Python demo.

It would be a really good idea to include a (PyGame) demo like
solarwolf in the standard distribution. Not because it would be used
very often but because it would add substantially to the "out of the
box experience" which is crucial for acquiring new customers.

IMO this alone would outweigh even the disadvantage of adding a few
megabytes to Pythons standard distribution and the disadvantage of
making it look less "serious" by associating it with games.

e) Anything not mentioned above

Anton

 

[Nick Jacobson]

Here are a few thoughts on this.

a) How often will it be used by how many people?

While I acknowledge PyCheckers usefulness, I tend not to use it very
often. Maybe I should use it more, or maybe Pythons executable pseudo
code quality forces PyChecker to fall in the "below 1% of use cases"
category.

I can't speak for others, but I run every piece of code of mine
through it. It's a safety net for typos. It explains certain bugs
before I have to figure them out. And if nothing else, I configured
it to tell me to put in doc strings, which comes up all the time.

b) Is it actively supported by people that are willing to release it
synchronously with Pythons updates?

Well, that might be a bit of a deal-breaker.

c) Is its license compatible with Python?

Not sure, but from the website,
"We believe that code should be as bug-free as possible. We believe
this so strongly, that we make tools freely available to help
programmers develop more robust systems."

d) Are there other packages that should be included which have more
urgency or that would be a better tradeoff for adding to the space
that a Python standard distribution takes?

Pychecker is not a very big package, which would be an argument in
favor of including it.

Right, it's not very big. If there are other packages that are more
important, that's OK. But IMO PyChecker belongs in the "to be added"
queue.

OTOH, some time ago I was at an Apple Itunes demonstration. I was
happy to immediately start a Python shell on a mac, but I also noticed
the conspicuous absence of an impressive Python demo.

It would be a really good idea to include a (PyGame) demo like
solarwolf in the standard distribution. Not because it would be used
very often but because it would add substantially to the "out of the
box experience" which is crucial for acquiring new customers.

IMO this alone would outweigh even the disadvantage of adding a few
megabytes to Pythons standard distribution and the disadvantage of
making it look less "serious" by associating it with games.

I think this deserves its own thread

 

[Nick Jacobson]

I would prefer a "lint" mode to the Python interpretter that runs
in a full warnings mode, using both static analysis that pychecker
does as well as any dynamic analysis that could be done. I
don't even care if it runs at half the speed of normal Python.

Roger

Yes! I completely agree. Perl has its "use strict" and "use
warnings". Admittedly, Perl *needs* them more, but I think Python
could use something like this too.

Not everyone would have to use it, but IMO having the option to catch
certain bugs (or style mistakes) before run-time would be beneficial.