Not *SIMPLY* ( more on this below. )
> If not why are code objects supported as a valid type that can be
> packed up using the marshal module in python?
You CAN exec 'bare' code objects. 'exec code' statement optionally
takes a global and local dictionary object for the environment in
which to exec the code. ( In a function, the first would be bound
to the func_globals attribute )
>>> code = compile( 'a + 1' , '<compiled code>', 'exec' )
>>> code
<code object ? at 20074498, file "<compiled code>", line 0>
>>> exec code
Traceback (innermost last):
File "<stdin>", line 1
File "<compiled code>", line 1
NameError: a
>>> exec ( code, { 'a': 99 } )
100
On Apr 5, 11:44, tnb2d@henson.cs.virginia.edu wrote:
>
> Steve Majewski is currently having this same problem as he
> tries to re-assign the code objects he "optimizes ;-)" with his
> byte-code optimizer. [ ...] The problem is that these built-in
> objects have *read-only* attributes, so they are not modifiable, and
> there is no facility currently available from within Python (although
> you can do it from C!) to create new ones.
> What we need is the ability to create new code objects,
> function objects, instance method objects, etc... with user-specified
> parameters. [ ... ]
> But before I make a bigger fool of myself, please tell me that
> this is not already supported somehow and I'm just missign it!
>
Making funcobject attributes Read/Writable was a quick hack for
experimental purposes. I don't think funtions should be mutable
objects. I *DO* however agree that there should be a simple
method to create NEW objects with different attribute bindings.
My hack was taking the easy way out as I didn't want to spend
the time figuring out how to add a new c function ( or to
figure out how to decipher marshal-ed code ) until I was
convinced there was going to be some general utility to it.
But if you're asking for a vote right NOW -- YES !
However:
(1) You don't need (I think) to code and external interface to
newfuncobject in C. I think it CAN be done in Python.
(2) I hate to sound like Tim here ( "You'll know better when
you've been around Python a bit longer, Sonny!" :-) but my
experience has been that you can do more that you expect
coding IN Python, and that it's well worth experimenting
with things on that level first: it's easier to change the
interface in Python, it's easier for other folks to try it
and comment on it and offer suggestions, and if it DOES
become a widely desired and standardized feature, THEN it's
much easier to get Guido and other to accept making it a
new builtin.
The original hack to make funcobject attributes R/W was to
add a mutable func_doc attribute. I'm now not sure that there
is any necessity for that ( see recently posted 'describe()'
help function. )
The second use was when kicking around lambda bindings.
Again, it was useful for demonstrating the problems and
suggesting solutions, but even if Guido doesn't add an
enhanced lambda syntax, I think there is a way to do
my bind function without R/W funcobj attrib's. (see below)
The third use was experimenting with a Python byte-code
assembler. I think we can code up a newfuncobject( code, ... )
in Python - I haven't poked into the internal representation
of marshal-ed code, but the following should be suggestive
of an answer:
[ But don't worry, Tommy: I wouldn't exactly call this
method "supported" ! :-) ]
>>> code
<code object ? at 20074498, file "<compiled code>", line 0>
>>> Dcode = marshal.loads( regsub.gsub( '<compiled code>',
'>Edoc Delipmoc<' , marshal.dumps( code )))
>>> Dcode
<code object ? at 2007a368, file ">Edoc Delipmoc<", line 0>
>>> exec ( Dcode, {'a':99} )
100
[ Discovering the NON-necessity of adding a new style
import statement, after having campaigned for this
feature, was the other recent lesson. ]
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics