RetroSearch Browse

Thu Aug 5 21:28:13 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/046907.html

On 5-aug-04, at 21:17, Gustavo Niemeyer wrote:

> Hi Bob,
>
>>> Why are they special? Why should they be more important than any 
>>> other
>>> part of the function definition?
>>
>> Because they take a function object as input and can do whatever they
>> want with it and return something else.
>
> This seems extremely powerful. OTOH, perl is also powerful.

They should IMHO be a part of the function definition because they are 
part of the specification of what the function will do. In the current 
situation decorators are not part of the function definition.

>
>>>> def saveSheetDidDismiss_returnCode_contextInfo_(self, sheet,
>>
>>> What is objc.signature() doing?
>>
>> objc.signature wraps the function object with an objc.selector that
>> specifies specific return and argument types.  In this particular 
>> case,
>> it declares that the selector
>> saveSheetDidDismiss:returnCode:contextInfo: returns void and takes an
>> object and an integer as arguments.  Without this, the selector can 
>> not
>> be bridged correctly to the Objective C runtime and the program would
>> crash.
>
> Isn't metaclass usage helpful in this case?
>
> Or a perhaps a dictionary?
>
>    __signature__ = {"funcname": "v@:@i"}

This moves the signature away from the function definition, meaning you 
have to take care to keep them synchronized.
>
> or
>
>    def funcname(...):
>       ...
>    funcname.signature = "v@:@i"

That should be workable for this specific example. It wouldn't work for 
the objc.accessor example. The objc.accessor function/decorator deduces 
the right kind of signature from the name and arguments of the 
function.

>
> and a postprocessor like:
>
> objc.register(classname)

We already use a metaclass, which is working just fine ;)
>
>> The ctypes package behaves similarly and would use decorators for the
>> same thing.  I imagine that other runtime/language bridges would also
>> benefit from similar techniques (Jython, IronPython, Python.NET,
>> JPython.. or whatever else).  I can also imagine it being used for
>> things like XML-RPC, SOAP, Apple Events, COM, etc. in a similar 
>> manner.
>
> Is this something good? I mean, having function wrappers all
> around the place? Wouldn't it be introducing unobvious code (magic?)
> in packages which are working fine as they are?

Nobody is saying anything about modifying existing modules. Decorators 
might make it easier to write objects that implement a COM or 
AppleScript interface, that doesn't mean we have to convert existing 
modules into COM objects.

>
> Should I just throw away my t-shirt with the "zen of python" text? :-)
Please don't, people need to be reminded of the zen sometimes :-)

Ronald

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046907.html below:

[Python-Dev] Call for defense of @decorators