[Python-ideas] Assignment decorators (Re: The Descriptor Protocol...)
ncoghlan at gmail.com
Thu Mar 10 02:02:08 CET 2011
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):
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).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas