[Python-ideas] Before and after the colon in funciton defs.

[Nick Coghlan]

On Fri, Sep 23, 2011 at 1:17 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Yes, inject() will be special. But I don't believe it will be magic, or at
> least not deep magic. We can get most of the way using supported Python
> functionality already: we can pull a function object apart, make a copy of
> the pieces as needed, and reassemble them into a new function. All that is
> supported by Python, none of it requires messing with private attributes:
> it's not much more magic than what functools.wraps() already does.
>
> We can even take the bytecode from the code object, and because it's just a
> string, we can perform transformations on it. The only "magic" is the
> knowledge of what transformations to perform.

Bytecode hacks are inherently implementation dependent deep magic.
Almost *nothing* about code objects is part of the language
specification (IIRC, it expects them to exist, but that's about it).
Jython and IronPython use JVM and CLR bytecode. PyPy uses a format at
least similar to CPython bytecode (since it was convenient for them to
do so), but there's absolutely no requirement for them to keep it the
same as the two implementations evolve. The entire *point* of wpython
is to use a word-oriented rather than byte-oriented format.

Even CPython will happily change the bytecode format between releases
- there's a reason a bytecode version marker is embedded in every .pyc
file.

Taking an existing function apart and putting it back together again
in a different way is skating right along that border between language
specification and implementation details. Proposals that play in that
space are almost guaranteed to be a hack that pays no attention to the
overall semantic concepts of the language design and they're simply
*not* going to happen.

Any reasonable piece of Python code *must* treat code objects as
opaque blobs that the interpreter uses to define an algorithm. It can
be fun, and sometimes even useful, to go further, but it would be
thoroughly inappropriate for the interpreter core or standard library
to indulge in that kind of thing.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia