[Python-Dev] Re: PEP 318: Decorators last before colon

[Bob Ippolito]

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