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 possible to wrap the standard Python interpreter with a static analysis tool to enforce some "use strict"-like constraints, but we don't see any widespread adoption of such a thing.
Is there something about Python that makes "use strict" behavior unnecessary or especially undesirable?
Alternatively, is the "use strict" behavior unnecessary in Perl, despite its widespread adoption?
Note: By "necessary" I mean "practically necessary", not strictly necessary. Obviously you can write Perl without "use strict," but (from what I've seen) most Perl programmers do use it.
Note: The Python interpreter-wrapper need not require "use strict"-like constraints -- you could use a pseudo-pragma similar to "use strict" that would be ignored by the normal interpreter. I'm not talking about adding a language-level feature.
Update: Explaining what "use strict" does in Perl per comments. (Link to official docs is in the first paragraph.)
The "use strict" directive has three distinct components, only two of which are really interesting:
use strict vars: Statically checks lexically scoped variable usage in your program. (Keep in mind that, in Python, there is basically only global scope and local scope). Many Python linters check for this sort of thing. Since it's the only static analysis that they can do, the linters assume you use straightforward lexical scoping and warn you about things that appear wrong in that sense until you tell them to shut up; i.e.
FOO = 12
foo += 3
If you're not doing anything fancy with your namespaces this can be useful to check for typos.
use strict refs: Prevents symbolic namespace dereferencing. Python's closest analog is using locals() and globals() to do symbolic binding and identifier lookup.
use strict subs: No real analog in Python.
"the run-time binding philosophy that Python embraces... makes "use strict" behavior unnecessary [and] especially undesirable"
Pretty good summary. Thanks.
That is essentially it. Static analysis tools don't help Python enough to be worthwhile.
Edit
"I'm asking for us to introspect on why we don't need it and, relatedly, why Perl programmers think they do need it."
The reason why is precisely the reason you already gave. We don't need it because it doesn't help. Clearly, you don't like that answer, but there's not much more to be said. Compile-time or pre-compile time checking simply does not help.
However, since you took the time to asked the question again, I'll provide more evidence for the answer you already gave.
I write Java almost as much as I write Python. Java's static type checking does not prevent any logic problems; it doesn't facilitate meeting performance requirements; it doesn't help meet the use cases. It doesn't even reduce the volume of unit testing.
While static type checking does spot the occasional misuse of a method, you find this out just as quickly in Python. In Python you find it at unit test time because it won't run. Note: I'm not saying wrong types are found with lots of clever unit tests, I'm saying most wrong type issues are found through unhandled exceptions where the thing simply won't run far enough to get to test assertions.
The reason why is Pythonistas don't waste time on static checking is simple. We don't need it. It doesn't offer any value. It's a level of analysis that has no economic benefit. It doesn't make me any more able to solve the real problems that real people are having with their real data.
Look at the most popular SO Python questions that are language (not problem domain or library) related.
Is there any difference between "foo is None" and "foo == None"? -- == vs. is. No static checking can help with this. Also, see Is there a difference between `==` and `is` in Python?
What does ** (double star) and * (star) do for parameters? -- *x gives a list, **x gives a dictionary. If you don't know this, your program dies immediately when you try to do something inappropriate for those types. "What if your program never does anything 'inappropriate'". Then your program works. 'nuff said.
How can I represent an 'Enum' in Python? -- this is a plea for some kind of limited-domain type. A class with class-level values pretty much does that job. "What if someone changes the assignment". Easy to build. Override __set__ to raise an exception. Yes static checking might spot this. No, it doesn't happen in practice that someone gets confused about an enum constant and a variable; and when they do, it's easy to spot at run time. "What if the logic never gets executed". Well, that's poor design and poor unit testing. Throwing a compiler error and putting in wrong logic that's never tested is no better than what happens in a dynamic language when it's never tested.
Generator Expressions vs. List Comprehension -- static checking doesn't help resolve this question.
Why does 1+++2 = 3? -- static checking wouldn't spot this. 1+++2 in C is perfectly legal in spite of all the compiler checking. It's not the same thing in Python as it is in C, but just as legal. And just as confusing.
List of lists changes reflected across sublists unexpectedly -- This is entirely conceptual. Static checking can't help solve this problem either. The Java equivalent would also compile and behave badly.