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

Nick Coghlan ncoghlan at gmail.com
Fri Mar 11 03:31:46 CET 2011


On Thu, Mar 10, 2011 at 2:02 PM, Guido van Rossum <guido at python.org> wrote:
> On Thu, Mar 10, 2011 at 11:41 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 10 March 2011 12:49, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> I actually agree it is a major weakness of the syntax. You can play
>>> games with "from" to rearrange the line. For example:
>>>
>>> def name from builder(param_spec):
>>>  code_block
>>>
>>> as sugar for:
>>>
>>> name = builder("name", param_spec_obj, code_obj)
>>
>> Yes, I like that better...
>
> I'd like it better if it came with a default builder implementation
> that would create regular functions, so that
>
> def name(<params>):
>  <block>
>
> was equivalent to
>
> def name from <defaultbuilder>(<params>):
>  <block>

Yeah, I was thinking that having builde equivalents for functions and
generators would be an interesting way to go. Builder objects may need
to be passed some extra parameters to make that feasible, though
(specifically, a reference to globals(), as well as the closure
fulfilment details).

One interesting side effect of that is the ability to have a
never-yields generator without having to insert a dummy never-executed
yield statement anywhere.

> But I don't see a reasonable way to do that.
>
> Also I think it's confusing to have both
>
> @some_magic
> def name(<params>): ...
>
> and
>
> def name from some_magic(<params): ...
>
> with different semantics.

Don't forget:

@more_magic
def name from some_magic(params):
    code

I'm *far* from convinced this is a good idea, but it at least meets
the holder of making something new possible.

If exec() was enhanced to allow correct execution of closures and code
blocks expecting arguments, you could experiment with this using a
decorator and extracting the various pieces from a function object
after it had already been created.

Cheers,
Nick.

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



More information about the Python-ideas mailing list