I suspect the accurate answer is "just because that's the way Python
itself writes out .pyc files" -- i.e., a .pyc file consists of a header
and a marshaled code object. So it's extremely useful as-is -- just not
to us users directly!
> What we need is the ability to create new code objects,
> function objects, instance method objects, etc... with user-specified
> parameters. For an instance method object, for instance, those are
> im_class, im_func and im_self. ...
Over time, more of Python's internals have been "exposed" to user
manipulation. However, whenever that happens, it pretty much freezes the
implementation for eternity (else people will justifiably whine that
their code that does muck with the internals "will break"). So it makes
good sense to be especially conservative about that kind of change.
Last time this particular one came up here (i.e., people wanting to
fiddle the readonly attributes), Guido declined, on the grounds that then
anybody could cause Python to dump core just by setting one of these
fields to a stupid value (by design or by accident ...). I got the
impression that he's not at all opposed to letting you shoot yourself in
the foot, but is unalterably opposed to letting you make it look like
Python pulled the trigger.
Steve was in the thick of that discussion, and to judge from what he said
later in this thread, came to the correct <grin> Guido-like decision:
that functions should not be mutable objects, but that it might be cool
to invent (safe, at least in the sense that Python can check and raise an
exception if you do something boneheaded) methods for creating new
functions out of old ones, random namespaces, etc.
> However, I would still maintain that extending marshal to handle
> a more complete set of types, ( which I don't think would be
> at all controversial )
Even Timmy wouldn't whine about that <wink>! Always meant to write a
recursive-structure dumper too, and think it would be way cool to fiddle
marshal to allow dumping/restoring those. Sounds like Jim is already
working on something that would subsume the functionality, as part of his
> and (initially) building newobject functions out of structured editing
> of marshal.dumps strings would be a good approach.
subtly y'rs - tim
Tim Peters firstname.lastname@example.org
not speaking for Kendall Square Research Corp