ajsiegel at optonline.com
Mon Aug 23 16:25:06 CEST 2004
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>
>>>>> def foo ():
>>>>> 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:
>> def __f(something):
>> 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?
__name__ = "the_name_I'm_stuck with" # we know the name
We are down to one extra cut and paste of "the_name_I'm_stuck with"
>> 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
>> 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.
More information about the Python-list