Is it possible to 'compile' a script?

[Cameron Laird]

In article <bSbn9.3037$Fz.82406 at news1.tin.it>,
Alex Martelli  <aleax at aleax.it> wrote:
><posted & mailed>
>
>solosnake wrote:
>        ...
>>> Note that Python already compiles scripts internally
>>> to a bytecode before executing them, and does most
>>> things that are reasonably practical to interpret
>>> the bytecode as quickly as possible.
>> 
>> So *in theory* at least what I am asking after is not impossible, and at
>> some level is already inside Python. My suggestion to those responsible
>
>And it's exposed to Python programmers as the 'compile' built-in function.
>
>> for maintaining Python is to differentiate between calling a script which
>> is then parsed and compiled into bytecode and executed, and calling a
>> function which will parse and create the bytecode, but return a handle to
>> that (now faster) bytecode and allow it to be executed through this
>> handle.
>
>How would that differ from the 'compile' built-in function, which
>returns a code-object?
Guys, guys; solosnake, Python already does what
you need.  Trust us.  Try it, and, and as your
experience grows, we'll discuss these matters
more deeply.

Alex, I suspect you're frightening our newcomer.
			.
			.
			.
>One thing I've seen leave beginners perplexed sometimes in this regard
>is how to perform the following task: they read from somewhere at
>runtime a multiline string such as:
>
>newcode = """def userfunc(x,y):
>                 return x+y"""
>
>which by convention of their program with its users must define a
>function named userfunc that accepts two arguments (e.g. for plotting
>purposes of some kind) and wonder how to best handle this.
			.
			.
			.
>Tip #2: def is a statement; if you trust your user totally you
>COULD just exec this string, ONCE, and thus bind name userfunc
>to a function which you can call normally.  *THIS IS NOT WISE*.
>Quite apart from users of ill intent, if the user has made a
>tiny typo such as defining 'usefrunc' instead of 'userfunc',
>your diagnostics of his/her mistake will likely be feeble to
>nonexistent.  exec can trample all over your namespace and thus
			.
			.
			.
>def new_userfunc(newcode):
>    tempdict = {}
>    try: exec newcode in tempdict
>    except SyntaxError, err:
>        return None, err
>    try: return tempdict['userfunc'], None, None
>    except AttributeError:
>        return None, NameError(
>          "You defined no 'userfunc' -- the names you binded are %s"
>          % [x for x in tempdict if x[:1]!='_'])
>
>to be called e.g. as follows:
>
>userfunc, err = new_userfunc(newcode)
>if userfunc is None:
>    diagnose_error(err)
>else:
>    plot_new_func(userfunc)
			.
			.
			.
Something like that.  My impression is that this
is *not* the direction solosnake is headed.

There certainly are a lot of bright, enthusiastic
Python beginners, though, who want to do exec()ly
things.  This is healthy.  They invariably start
off with overuse, with predictable results.
You've given above one programmatic mollification
of the confusion that can result.  For many of 
them, though, they're best off pausing for a bit
and reflecting whether they're truly in the I-
must-act-on-live-Python-code-received-from-the-
end-user mode of your graphic example.  "Extension
scripting"'s a powerful technique.  There are, as
you note, ways to do it more safely.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html