"Compiling" scripts before execution ?

[Tim Peters]

[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