[Python-ideas] Assignment decorators (Re: The Descriptor Protocol...)

[Nick Coghlan]

On Wed, Mar 9, 2011 at 7:29 PM, Guido van Rossum <guido at python.org> wrote:
> On Wed, Mar 9, 2011 at 6:12 PM, MRAB <python at mrabarnett.plus.com> wrote:
>>    def foo = CharField(size=10, nullable=False)
>
> Eek, it would be really easy to misread that.
>
> But as long as we're trying to reuse 'def', I think a decorator using
> introspection could make this form work:

I don't like the suggestion as written, but I quite like it as a
superior syntax proposal for PEP 359.

def (builder) name(param_spec):
    code_block

Unlike PEP 359 though, the builder could be given the compiled code
block as a code object (compiled as a closure) and the param_spec
would be a description of the full parameter spec (ala PEP 362). The
invocation of the builder would then be along the lines of:

name = builder("name", param_spec, code_block, globals_dict)

Such a statement would:
1. differs from "class" as it would be a true closure
2. differ from bare "def" with a decorator as the builder is given the
current globals, raw parameter spec and code object, rather than
having to extract them from a pre-built function object.
3. allow "global": and "nonlocal" to work just as they do for a function
4. "class" and "bare def" would be become optimised versions of such a
general def for creating functions, generators and classes
5. With an appropriate builder, it would be possible to force creation
of a generator without using a dummy yield in dead code
6. "exec" would likely need updates in order to be able to properly
execute compiled closures and code objects expecting arguments

In a lot of ways, this would be resurrecting the "anonymous blocks"
part of PEP 340 (only without the anonymity).

Cheers,
Nick.

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