views:

87

answers:

3

Hey guys,

I've never been a huge Python fan. I learned it for a course where the teacher was really into it, but his enthusiasm never quite made it to the rest of our class it seems: as soon as we had the chance, we all jumped off to C#/Java.

Anyways. This wasn't a concluding experience, and what annoyed me the most in the language was that to find out if Python code would work, you actually have to execute it, and risk dying halfway through because of something stupid like a typo in a variable name (throwing up a NameError). Stuff that compilers for compiled languages catch at the very first glance, but that Python won't bother to complain about until it's too late. (I know you can always die half through a test with compiled programs too, but at least it won't be from a typo.)

I'm not really giving it a second chance yet, but for the sake of the next students, are there Python statical analysis or validation tools out there that would catch most errors (I understand you can't catch them all) compilers would catch at compile-time?

+5  A: 

Take a look at the following programs:

ars
+1 beat me to it
awesomo
Thank you very much!
zneak
+6  A: 

"but that Python won't bother to complain about until it's too late"

It's not that the message comes too late. It's that you're waiting too long to use Python. Don't type a mountain of code and then complain that one small piece is bad.

  1. Use Unit Testing. Write less code before running a test.

  2. Use python Interactively to experiment. You can do most statistical processing from the >>> prompt.

  3. Don't write long, main-program-like scripts. Write short scripts -- in small pieces -- and test the small pieces.

S.Lott
Thank you for expressing your opinion on my ways of coding. However, I don't need it anymore. I'm asking which tools I could recommend to help the poor souls.
zneak
@zneak - S. Lott gave you techniques to naturally exercise code coverage in dynamically typed languages. Try not to be so dismissive of good advice - especially if you in turn expect to give advice.
Jeremy Brown
@zneak: I gave you tools. The tools are Unit Testing, Interactive Python and a change in style. Those tools are often more effective than static analysis. Here's a hint: static analyzers aren't a standard part of the Python distribution for a reason. Fewer folks use them. Unit testing is part of the distribution for a reason. More folks use it.
S.Lott
@S.Lott: I'd rather say that the single tool you gave me are unit tests, and the rest is a change of style. So I thank you for expressing your views on my ways of coding, but I am not willing to do big projects with Python any time soon, and I am not going to teach a change of style to other students.
zneak
@zneak: If you're teaching the wrong style, then -- perhaps -- you should reconsider the style you're teaching.
S.Lott
@S.Lott: I won't be teaching anything, style included. Unless hinting pylint is teaching style.
zneak
@zneak: So you've decided Python -- as you decided to use it -- is impossible to use. And I cannot suggest that you might be doing something wrong. Further, I cannot suggest that almost everyone else does it differently. Are you saying the only acceptable thing you can learn from this is `pylint`? Are you saying your preconceived notions (no matter how distinct from common usage) cannot change?
S.Lott
@S.Lott: I think you're taking this a bit too seriously. I asked for something to check for potential `NameErrors`, you came up with how I used Python the wrong wrong way (without even knowing prior to this how I used it), and now you're upset that I really just wanted something to check for potential `NameErrors`.
zneak
@zneak: Your question indicted Python very broadly. If all you have are NameErrors, your question doesn't indicate that. Your question says something quite different: "Python code would work, you actually have to execute it" and "Python won't bother to complain about until it's too late" Which are very broad, unfocused and confusing criticisms. Further, you said that you are "not willing to do big projects with Python any time soon" which indicates that you've extrapolated your initial problems into an absolute indictment of the language. If that's false, please fix the question.
S.Lott
@S.Lott I am sorry for the misunderstanding of my question. I believe my focus on the benefits of compile-time checking made it very explicit what kind of help I expected. I would also dare say your second quote is out of place, since the first half of the sentence it comes from is "Stuff that compilers for compiled languages catch at the very first glance", making my criticism much narrower than you apparently want to believe. Finally, how would your answer change should I remove my appreciation of Python from my question?
zneak
@zneak: " I believe my focus on the benefits of compile-time checking made it very explicit what kind of help I expected". I'm sure you believe that. The fact that I misunderstood should give you some doubts about how explicit you were. My answer would not change materially, since you are claiming that your "style" is perfect and that -- somehow -- only pylint can help. I'm fail understand that response. You have repeatedly claimed that your "style" is above comment. I have no choice but to acquiesce. You will not change your "style". It is perfect even if atypical for Python.
S.Lott
@S.Lott I believe dedicating a whole paragraph to something is enough to make it explicit. Besides, out of the three answerers, you are the only one who did not see it. As of my style, I don't think I ever said it was perfect. I did try to hammer that it was not the concern of the question. But calling it perfect? Don't think so. Apart from being imperfect, I'll also agree that it's probably not suited for Python applications. But we both already knew that. Now what's wrong with suggesting people to use pylint? It's not pylint against unit tests, either. As far as I know you, can have both.
zneak
@zneak: I now see the wisdom in asking for help, and then complain about the help offered. I see the wisdom in refusing to clarify. Totally makes sense now. You've cleared it up for me. Thanks.
S.Lott
+1  A: 

In addition to the ones mentioned by ars.

Try Pydev, it has static code analysis build-in. Or Pida which has a couple of different static analysis tools available.

Or if you are looking for a standalone library, try Rope

WoLpH