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

MRAB python at mrabarnett.plus.com
Thu Mar 10 02:37:52 CET 2011

On 10/03/2011 01:02, Nick Coghlan wrote:
> 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
I think what I don't like is that the name is buried in the middle of
the line and not near the start as in the "class" or "def" statement.

> 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).

More information about the Python-ideas mailing list