«

I had an idea yesterday. (Yes, I know. Sorry).

If we don't need to declare variables as having a certain type, why do we
need to import modules into the program? Isn't the "import sys" redundant
if all I want is to call "sys.setrecursionlimit(5000)" ? Why couldn't we
just try loading the module of a name "sys" to see if it exists and re-try
the command?

I tried just that. This is meant as a proof of concept (I called it
autoload.py)

-------- BEGIN HERE ------
import sys, inspect

def autoload_exc(type, value, traceback):
modulename = value.args[0].split()[1][1:-1]
f_locals = traceback.tb_frame.f_locals
f_globals = traceback.tb_frame.f_globals

exec "import " + modulename in f_locals, f_globals
exec traceback.tb_frame.f_code in f_locals, f_globals

sys.excepthook = autoload_exc

------- END HERE -------

I know there are problems here. Checking if we have a NameError exception
is the most glaring one. Still this works for simple things as a proof of
concept.

Here is an example of a simple session:

>>> import autoload
>>> sys.setrecursionlimit(5000)
>>> dir(time)
['__doc__', '__name__', 'accept2dyear', 'altzone', 'asctime', 'clock',
'ctime',
'daylight', 'gmtime', 'localtime', 'mktime', 'sleep', 'strftime',
'strptime', 's
truct_time', 'time', 'timezone', 'tzname']
>>> os.path.join("usr","local","bin")
'usr\\local\\bin'

Any comments?

Greg

Advice is what we ask for when we already know the answer but wish we
didn't.
-- Erica Jong (How to Save Your Own Life, 1977)

> "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

I tossed this in my PYTHONSTARTUP file, to see how I like it.
No complaints so far, and it might make the interactive prompt even
easier to use.

Jeff

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

Grzegorz Dostatni <> wrote in
newsine.LNX.4.44.0404171006210.27811-:
>
> I had an idea yesterday. (Yes, I know. Sorry).
>
> If we don't need to declare variables as having a certain type, why do
> we need to import modules into the program? Isn't the "import sys"
> redundant if all I want is to call "sys.setrecursionlimit(5000)" ? Why
> couldn't we just try loading the module of a name "sys" to see if it
> exists and re-try the command?
>
> I tried just that. This is meant as a proof of concept (I called it
> autoload.py)
>
> -------- BEGIN HERE ------
> import sys, inspect
>
> def autoload_exc(type, value, traceback):
> modulename = value.args[0].split()[1][1:-1]
> f_locals = traceback.tb_frame.f_locals
> f_globals = traceback.tb_frame.f_globals
>
> exec "import " + modulename in f_locals, f_globals
> exec traceback.tb_frame.f_code in f_locals, f_globals
>
> sys.excepthook = autoload_exc
>
> ------- END HERE -------
>
> I know there are problems here. Checking if we have a NameError
> exception is the most glaring one. Still this works for simple things
> as a proof of concept.
>
> Here is an example of a simple session:
>
>>>> import autoload
>>>> sys.setrecursionlimit(5000)
>>>> dir(time)
> ['__doc__', '__name__', 'accept2dyear', 'altzone', 'asctime', 'clock',
> 'ctime',
> 'daylight', 'gmtime', 'localtime', 'mktime', 'sleep', 'strftime',
> 'strptime', 's
> truct_time', 'time', 'timezone', 'tzname']
>>>> os.path.join("usr","local","bin")
> 'usr\\local\\bin'
>
> Any comments?

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

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.

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.)

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.

chris

--
Chris <>

Grzegorz Dostatni wrote:
>>"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.

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.

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.

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.

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

** Thanks to Greg for starting this discussion as otherwise I
would not have discovered this bug in time to save you all...

Grzegorz Dostatni:

>Here is another version of the autoload module. This is now at 0.3 and
>moving on.

Thanks. Seems to work here under Cygwin (my main Python interactive
shell). What's in a name anyway.

Anton

Grzegorz Dostatni <> wrote in message news:<Pine.LNX.4.44.0404171006210.27811->...
> I had an idea yesterday. (Yes, I know. Sorry).
>
> -------- BEGIN HERE ------
> import sys, inspect
>
> def autoload_exc(type, value, traceback):
> modulename = value.args[0].split()[1][1:-1]
> f_locals = traceback.tb_frame.f_locals
> f_globals = traceback.tb_frame.f_globals
>
> exec "import " + modulename in f_locals, f_globals
> exec traceback.tb_frame.f_code in f_locals, f_globals
>
> sys.excepthook = autoload_exc
>
> ------- END HERE -------

Nice hack! The earlier pundits have a point that explicit imports
are a Good Thing for most code, but for the interactive session this
will be really handy. (...considers putting it in .pythonrc)

On Sat, 17 Apr 2004 15:11:16 -0400, rumours say that Peter Hansen
<> might have written:

>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".

Peter, don't worry. There ain't no such thing as a free launch.
--
TZOTZIOY, I speak England very best,
Ils sont fous ces Redmontains! --Harddix