[Python-Dev] Re: PEP 318: Decorators last before colon (original) (raw)

Bob Ippolito bob at redivi.com
Thu Apr 1 12:48:56 EST 2004

On Apr 1, 2004, at 12:08 PM, Michel Pelletier wrote:

My second comment is that I wonder if decoration of any syntax has been thought out in the light of other objects being decorated, like classes, functions, or interfaces. I just feel like there's more thought to be applied here on decoration syntax in general. When we take decoration to the next level, will this syntax suffice? Will it be abused for reasons not considered, like run-time type checking? I'm not positive but it seems this is what Bob I. wants it for.

It's not run-time type checking.. it's run-time type bridge between the Python and Objective C runtimes. Without these decorators (and other FFI machinery), the bridge does not work, because a PyObject* is not a struct _NSRect or a NSObject*, etc. It's essentially the same kind of thing as ctypes, except the Objective C runtime has a lot more RTTI available than the regular 'ol C runtime and it also uses reference counting so it's more safe and sane. ctypes probably needs decorator syntax more than PyObjC does, but the brave few have hobbled along without it :)

And have we considered all the options? I'm not making any proposals, but perhaps decoration can be bundled into a separate object that a class refers to, similar to interfaces. This could allow a lot more flexibility and still look like Python. Or perhaps this separate object could be mixed in (blech). But you see my point, the upshot is you could apply different decorations at different times, decorators would be separately managed and it wouldn't look like a shark fin duct taped to a VW bug.

In my use case it doesn't really make sense to keep them separate, as the functions are broken without their decorator because they can not be called from the Objective C side of the bridge. The only time you need to use these decorators are when you are creating a class that complies with an informal protocol, whose selectors have non-object type signatures (returning void or BOOL is exceedingly common, as is taking integers, and sometimes nasty pointer stuff). In any case, it's actually really common with AppKit and Foundation because most of it is event driven and these informal protocols are part of the delegate callback machinery for everything from URL loading to printing.

-bob

More information about the Python-Dev mailing list