56 lines
2.1 KiB
Plaintext
56 lines
2.1 KiB
Plaintext
From: tim_one at email.msn.com (Tim Peters)
|
|
Date: Tue, 27 Apr 1999 23:49:02 -0400
|
|
Subject: "Compiling" scripts before execution ?
|
|
In-Reply-To: <19990426104245.A504861@vislab.epa.gov>
|
|
Message-ID: <000801be912a$0e7ed680$29a02299@tim>
|
|
Content-Length: 1878
|
|
X-UID: 433
|
|
|
|
[Randall Hopper]
|
|
> One concern I've been mulling over lately is the potential problem
|
|
> maintaining Python scripts over time. For example:
|
|
>
|
|
> 1) It's easy to never create (or to sever) a link to a
|
|
> imported symbol defined in another module, and you may never
|
|
> know it until python tries to execute the referencing line of
|
|
> script code.
|
|
>
|
|
> 2) If the signature of an imported method changes, and all
|
|
> references to it in all scripts aren't updated, you may never know
|
|
> it until Python tries to execute one of these "broken" line of
|
|
> script code.
|
|
> ...
|
|
> What are folks doing to keep this class of errors from being a problem?
|
|
|
|
I use a text editor with extremely fast file-based search-and-replace <0.5
|
|
wink>. Short of that, signatures and exported symbols are part of a
|
|
module's advertised contract, and a module has no right to change its
|
|
contract unilaterally in an incompatible way. This isn't as flippant as it
|
|
sounds (*almost*, but not quite ...). Python argument lists are exceedingly
|
|
flexible beasts, and it's almost always possible to maintain backwards
|
|
compatibility when changing a signature.
|
|
|
|
> Is there a way to "lint" or compile Python code such that it
|
|
> forces symbols to resolve when seen (possibly disallowing some dynamic
|
|
> symbol definition available in the language (e.g. adding methods to
|
|
> classes after class definition).
|
|
|
|
Nope, you'll have to deal with it. The best stab at a Python "lint" is
|
|
Aaron Watters's kjpylint, available from
|
|
|
|
http://www.chordate.com/kwParsing/index.html
|
|
|
|
It's not trying to do cross-module analysis, though.
|
|
|
|
Python2 may or may not introduce some notion of optional static typing,
|
|
which could catch this stuff for those motivated enough to use it. That's a
|
|
Types-SIG topic.
|
|
|
|
the-downside-of-a-dynamic-language-is-its-dynamicism-ly y'rs - tim
|
|
|
|
|
|
|
|
|
|
|
|
|