Is there a need for a “use strict” Python compiler?

Question

There exist static analysis tools for Python, but compile time checks tend to be diametrically opposed to the run-time binding philosophy that Python embraces. It\'s possibl

Answer 1

I've found that I only really care about detecting references to undeclared vars. Eclipse has pylint integration via PyDev and, although pylint is far from perfect, it does a reasonable job at that.

It does kind of go against Python's dynamic nature, and I do have to add #IGNOREs occasionally, when my code gets clever about something. But I find that happens infrequently enough that I'm happy with it.

But I could see the utility of some pylint-like functionality becoming available in the form of a command-line flag. Kind of like Python 2.6's -3 switch, which identifies points of incompatibility between Python 2.x and 3.x code.

Answer 2

It is very difficult to write large programs without 'use strict' in Perl. Without 'use strict', if you use a variable again, and misspell it by leaving a letter out, the program still runs. And without test cases to check your results, you can never find such errors. It can be very time-consuming to find why you are getting wrong results due to this reason.

Some of my Perl programs consist of 5,000 lines to 10,000 lines of code broken into dozens of modules. One cannot really do production programming without 'use strict'. I would never allow production code to be installed in the factory with languages that do not enforce "variable declarations".

This is why Perl 5.12.x now has the 'use strict' as the default behavior. You can turn them off.

PHP has given me quite a few problems because of no variable declaration enforcement. So you need to limit yourself to small programs with this language.

Just an opinion ...

abcParsing

Answer 3

Python does have something that can change script syntax:

from __future__ import print_function

and various other future-features that have syntax implications. It's just that Python's syntax has been stricter, stabler and more well-defined than historical Perl; the kind of things that ‘strict refs’ and ‘strict subs’ prohibit have never existed in Python.

‘strict vars’ is primarily intended to stop typoed references and missed-out ‘my’s from creating accidental globals (well, package variables in Perl terms). This can't happen in Python as bare assignments default to local declaration, and bare unassigned symbols result in an exception.

(There is still the case where users accidentally try to write-through to a global without declaring it with a ‘global’ statement, causing either an accidental local or, more often, an UnboundLocalError. This tends to be learned fairly quickly, but it is an arguable case where having to declare your locals could help. Although few experienced Python programmers would accept the readability burden.)

Other language and library changes that do not involve syntax are handled through the warnings system.

Answer 4

I think there's some confusion as the what "use strict" does, from the comments I'm seeing. It does not turn on compile time type checks (to be like Java). In that sense, Perl progammers are in agreement with python programmers. As S.Lott says above these types of checks don't protect against logic bugs, don't reduce the number of unit tests you need to write and we're also not big fans of bondage programming.

Here's a list of what "use strict" does do:

1. Using symbolic references is a run-time error. This prevents you from doing crazy (but sometimes useful things like)

   $var = 'foo';

   $foo = 'bar';

   print $$var; # this would contain the contents of $foo unless run under strict

2. Using undeclared variables is a run-time error (this means you need to use "my", "our" or "local" to declare your variable's scope before using it.

3. All barewords are considered compile-time syntax errors. Barewords are words that have not been declared as symbols or subroutines. This is mainly to outlaw something that was historically done but is considered to have been a mistake.