PEP318

[Ronald Oussoren]

On 13-aug-04, at 13:17, Arthur wrote:

>
>> On Thu, 12 Aug 2004 17:03:19 GMT, Arthur <ajsiegel at optonline.com> 
>> wrote:
>>>> def foo ():
>>>>   whatever
>>>> foo = decorator (foo)
>>>>
>>>> is that you have to type the word "foo" three times.
>>>
>>> Big f**king deal - all things considered. ;)
>>
>> When this name is a PyObjC name that might be 70 characters long,
>> it becomes a big deal.
>
> I had asked this before:
>
> Does
>
> def __f(something):
>     dosomething
>
> the_name_I_really_want_to_call=transform(__f)
>
> work?
>
> It is not a destructive transform of __f, but why is that important?

This requires additional input if you want to have the correct __name__ 
attribute for the function. In your example 'transform' cannot no that 
the result will be bound to 'the_name_I_really_want_to_call'.   In 
PyObjC I use the __name__ to deduce information about the function 
(such as the Objective-C name for the function).

Another problem is that you only know the "real" name for the function 
some time after the function definition.

>
> What else am I missing?
>
> I thought I read the PyObjC folks saying that they saw use cases for a
> decorator syntax for their project - to be sure - but that was
> (mis)interpreted as meaning that they saw it as important for their 
> project,
> which they don't.
>
> I could be wrong in my interpretation here.

Decorators would make live a lot easier for us, but not having 
decorators won't kill PyObjC.

I would like to have decorators, but not at every cost. The 
@decorator-before-def proposal looks sane.

Ronald