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

[Ronald Oussoren]

On 03 Jun 2014, at 15:00, Nicholas Cole <nicholas.cole at gmail.com> 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;

More importantly, it should generally be trivial to derive the Swift definition from the Objective-C one. 

I’ve in the past looked at using keyword arguments (basically a **kwds argument) to do something similar for PyObjC, but that doesn’t work in general because the order of keyword arguments in a call isn’t preserved in “kwds”, and that makes it expensive to derive Objective-C selector from the keyword dictionary (and in theory there might be two methods with the same segments in a different order). 

There’s been some talk about using an OrderedDict for the dictionary that’s used for **kwds on python-list, but I don’t recall the result of that discussion and even that did work out that would at best turn up in Python 3.5.

BTW. It might be possible to use a similar algorithm to derive Pythonic names for Objective-C selectors, but that would either require eagerly scanning the methods in an class, or doing the work up front and storing the result in metadata. Neither option is particularly appealing.  But you never know, maybe Swift inspires me to come up with a smart solution to the naming problem ;-)

Ronald

P.S. This is still without having read the Swift documentation.