PEP318

[Arthur]

On Fri, 13 Aug 2004 13:30:57 +0200, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:

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

if __name__ were writeable, aren't both problems solved?

def __f():
    __name__ = "the_name_I'm_stuck with"    # we know the name 

the_name_I'm_stuck with=transfrom(__f)

We are down to  one extra cut and paste of "the_name_I'm_stuck with" 


Art
>
>>
>> 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