[Pythonmac-SIG] [Pyobjc-dev] Towards PyObjC 3.0

[has]

Ronald Oussoren wrote:

 >> In fact, if you are right that
 >> there is now some kind of translation table that could make PyObjC
 >> method names even better, that would be really brilliant.
 >
 >I was too optimistic about that, looking at the section about methods 
in the Swift book (page 339 and onwards) Swift by default treats the 
second and later arguments of a method as function parameters with 
“external names” (see page 221 for a definition of that), which similar 
to required keyword parameters in Python 3, that is:
 >
 > func splitBy(separator: String, maxCount: Int) -> Array { …}
 >
 >as a method on a String-like class is more or less similar to the 
following Python definition:
 >
 > def splitBy(separator, *, maxCount): …
 >
 >And that cleanly translates into:
 >
 > -(NSArray) splitBySeparator:(NSString*)separator 
maxCount:(NSInteger)maxCount;

Yep, it's not runtime translation, its syntactic swizzling being done in 
the parser. MacRuby did [1] the same thing IIRC, allowing Ruby users to 
write methods using familiar Ruby method name + keyword args syntax, but 
obviously what looked like the method's name was only part of it and the 
'keyword' args were 100% positional and order-sensitive: the parser just 
stripped out the 'keywords' and reassembled the real ObjC signature.

It also meant, of course, that you could safely have several methods 
with identical-looking 'names' in the same class, even though Ruby 
doesn't support method overloading, because they weren't really 
identical names at all and therefore didn't actually mask each other. 
That alone should rule out a translation table approach, since Python 
would only give you the last splitBy(...) method in your class; every 
other splitBy(...) would be masked by it, regardless of what their 
selector names are.

Whether you could dive into Python's lexer/tokenizer/parser/AST and do 
the same sort of swizzling as MR there, I don't know.

And I really wouldn't like to say if it'd be a wise choice or not: the 
current syntax is ugly, but you can throw rocks at it and it's still 
guaranteed to work, whereas once you start mucking with something as 
complex and knotty as Python syntax, who knows what you might step on?

HTH

has