Static Modules...

[Grzegorz Dostatni]

On Sat, 17 Apr 2004, Peter Hansen wrote:

> That's not entirely accurate, I think.  With static typing, you
> can't even use a variable if you don't predefine it, but predefining
> it doesn't necessarily give it a value (or it gives it a benign
> default value).  With dynamic typing, just asking for a variable
> doesn't (normally) magically create one with an appropriate value.

Consider this imaginary python code:

asdf.hello()

The problem is that we don't know what asdf is. It could be a module, an
object or even a function (eg.

>>> def asdf(a="Hello", b="World"):
...     print (a,b)
...
>>> asdf.hello = asdf

) # closing the (eg.
My claim here is that we don't "magically" create the variable. You are
still required to explicitly ask for it (as in sys.setrecursionlimit -
you're asking for sys), BUT that statement is based on a fact that I KNOW
what sys is - a module. I think that is the root of this discussion. And
no, I don't like the idea of changing syntax to accomodate it ;-)

> This hack is a cool idea for interactive prompts, but in real
> code and even at the prompt it could actually be quite "dangerous".
> Importing a module can cause arbitrary code to execute, so it
> makes some sense to _require_ the import statement.

I somewhat agree with this. It is definitely a good idea to require
imports of custom modules. It is quite easy to add that check into the
code. This is a great hack for the interactive mode.

> After all, what if I had a module called, perhaps inappropriately,
> "launch" and it triggered the launch of my personal anti-aircraft
> missile when imported?  (Yes, bad style too, but I wrote this
> control code long ago before I learned good style. ;-)  Now in
> one of my other modules, I have a subtle bug** which involves an
> object named, perhaps unsurprisingly for this example, "launch".
>
> The code looks like this actually (pulled right out of the source
> tree!), slightly edited to preserve national security:
>
> def checkLaunchPermission(self):
>      lunch = self.findLaunchController()
>      if launch.inhibited:
>          # code that doesn't launch anything...
>
> Now if I understand it properly, when your hack is in place
> this would actually import the launch module and cause all hell
> to break loose.

Hmm.. In the interest of continual survival of human race I could include
a warning whenever including a module.  Or perhaps make the binding to
sys.excepthook explicit (an extra statement), but extra statements is what
I want to avoid. Another options would be to make this work *ONLY* for
system libraries (sys,os,os.path,popen, etc.).

One thing I can't get out of my head is that if your launch module is
installed in PYTHONPATH, we're all in danger and should probably seek
cover. Isn't it more likely that launch.py is somewhere deep under
"NSA/development/python/missile" directory? So it should not be imported
automatically. Generally only the system library and custom modules to the
project you're working on are available to be imported.


> Did I just make a case for static typing with Python?  Well,
> perhaps, but only in the relatively dangerous area of module
> imports and there, unlike with simple variable names, Python
> already requires explicit (i.e. static) definitions...
>
> -Peter
>

Greg