Static Modules...

[Grzegorz Dostatni]

> "import this" -> "Explicit is better than implicit."

This is exactly my point. My way will only work when you reference the
name explicitly, as in:

sys.setrecursionlimit(500)

You're referencing the sys module explicitly. Other than that this
"problem" exactly parallels the discussion between static and dynamic
typing. And we know which way python chooses to go.

> you dont easily see what exetrnal modules a program uses. that makes it
> more difficult to debug, and it makes neat things like py2exe/installer
> impossible.

Alright. I haven't even though of py2exe/installer problem. Still a
solution to that is not outside the realm of possibility. The easiest hack
would be for the autoload to save the "imports" file in the same
directory or display a warning (which is trivially done with the warning
module).


> a slight missconception is also there, as variables dont exist out of
> nothing, they start apearing when you assign something to them. (appart
> from that i dont like to say "variable" in python, more like binding names
> to objects.)

Here I would argue that the variables did not get created out of nothing.
It's equivalent to this code:

--- BEGIN HERE ---
import Tkinter, sys
Tkinter.Button(text="Quit", command=sys.exit).pack()
--- END HERE ---

Which is representative of another python philosophy. Don't specify things
you don't need. If you can resonably figure out (without ambiguity) what
the user wants do to - just do it. Don't pester him/her with unnecessary
questions.


> so something similar to using "variables" would be:
>
> sys = __import__("sys")
>
> which is already possible without any hack ;-)
>
> however, it could be a nice little hack for interactive sessions when
> playing around in the interpreter. but i'd like to see a message when it
> imports something, so that later when copy&pasting something to a file, i
> dont forget the imports.

That's a good idea.

Greg