Re: [Pyobjc-dev] NGPython

[b.bum <bb...@ma...>]

Please read the rather long thread on python-dev.  All of the points 
you raise have been addressed in that thread.

This is a subject that has come up every 18 months to two years for the 
history of the PyObjC project (since 1994/1995) and the change has not 
been made yet.   None of us are attached to the '_' based notation, but 
it remains because it is brain-dead simple and has no exceptions beyond 
those necessary to support the idiosyncrasies of mapping C to Python.

> Good points, yet the "usual" mapping rule is pretty easy to explain 
> and understand and just makes sense. Like if you have an Objective-C 
> method with "With", the "With" denotes keyword arguments 
> (initWithSet:, NSSet(set=)).
> I don't think this is much more difficult for the regular developer to 
> remember.

Except that there are exceptions.... and exceptions to the exceptions...

End result developer has to remember:  "This is the mapping, except 
this special case and that special case and this other special case and 
that inconsistency and, oh wait, this is a new framework, it hasn't 
been mapped yet and oops, Apple released a new version, those haven't 
been mapped yet but will be..."

On Mar 1, 2004, at 2:02 AM, Helge Hess wrote:
> On 01.03.2004, at 07:26, b.bum wrote:
>>> I think that this was much more beautiful than the current automatic 
>>> ":" => "_" scheme used in PyObjC ;-)
>>
>> It fails this simple test:  can the mapping rule be expressed as a 
>> single rule.
>> The ":" -> "_" mapping, though ugly (really -- none of us are 
>> attached to it), can:
>> "Given an ObjC method name, replace all ":" with "_" to find the 
>> python name."
>> A 'bridget' style mapping cannot.
>
> Could you elaborate? What do you mean by "can be expressed as a single 
> rule"?  Do you care about speed?
> Of course the mapping "can" be expressed as a single rule as long as 
> it is unique.

Speed is just a matter of caching and optimizations.

The last sentence of your statement is exactly why mappings are a 
nightmare.   There will always be special cases, including dealing with 
situations where the default "mapping" is not unique.

>> There will be special cases and the end result will be a new language 
>> that is effectively a hybrid between Python and Objective-C.
>
> Absolutely not, this is just regular Python - a function which does 
> different things depending on the input parameters. Of course the 
> developer need to know about the used libraries in any case.

A language is a combination of its syntax and the APIs of the base 
libraries.   To effectively use Python, you need to know Python and you 
need to know some limited subset of the python library.  The same is 
true of Cocoa or GNUStep based Objective-C.

A mapping based solution attemps to "port" the Objective-C API into 
Python in a "Pythonic" fashion.  The end result is an API that is 
neither Objective-C nor Python.   It sort of looks like Python, but 
there will be all kinds of weird little special cases resulting from 
the underlying C nature of Objective-C.

>> Just like the Java<->Objective-C bridge, such an approach to 
>> "mapping" Objective-C methods into Python in a "Pythonic" fashion 
>> will yield something that requires the developer to learn a new 
>> language.
>
> I can't see why. Indeed he does need to know much less about 
> Objective-C than before if he doesn't do exotic things.

That is incorrect.  The developer still has to know that there is API 
to be called and still  has to find that API.   As it stands, the 
developer can find the API by looking directly in the Python library or 
finding the API by looking directly in the Objective-C header files 
[API].

A mapped solution ensures that the developer cannot look in either of 
these places to find canonical information as to what they should 
implement.

Furthermore, the Objective-C method names are meaningful.   
-setObject:forKey: says more than just "this is a method named 
'setObject:forKey:', it also gives information about the arguments and 
their order (and, no, they are not named arguments).   A mapping based 
solution loses all of that.

This was one of the primary complaints about bridged Java (and WO 5.x). 
   The Java APIs were a mutated Foundation.   It was less approachable 
to new developers because the API was not as self-descriptive.

>> The current form is as follows:
>>
>> set = NSSet.setWithArray_(myarray)
>> set = NSSet.setWithSet_(otherSet)
>>
>> While the trailing '_' are unpalatable to the traditional Python 
>> programmer, it is extremely clear exactly what the code is doing.  If 
>> not, the developer only has to remember one rule to figure out what 
>> bit of Foundation documentation to read to figure it out.
>
> There are obviously situations where and explicit factory makes a lot 
> more sense, yet, in the case of NSSet its awkward and unintuitive for 
> Python developers (and even Objective-C developers will get into 
> difficulties to know what syntax to use in what situation).

If Objective-C developers have difficulty and that difficulty is still 
found in bridged Obj-C on the python side, why go through such pains to 
hide it?

Again, unless the PyObjC project were to specifically document each and 
every mapping, there is nowhere that the developer could look up 
NSSet(array=myArray) to understand what is being invoked on the ObjC 
side.

> Anyway, we can let the thread stop here, my posting wasn't really 
> meant to start a flamewar but to offer some code in case someone is 
> interested ;-)

No flamewar -- I don't think you understand how much thought, effort, 
and engineering has gone into the current implementation, including a 
lot of thinking as to how to make a mapping based solution work.

I think I can safely speak for the entire pyobjc-dev community in 
saying that we all think the '_' based notation isn't pretty.   But the 
lack of 'pythonic syntax' is a disadvantage that pales in comparison to 
having a solution that "just works" across releases of the OS and with 
any Objective-C API available, including those that we have never 
"mapped".

> BTW: your post fails to list the really interesting parts, like the 
> required reverse mapping of selectors for subclassing Objective-C 
> objects in Python.

Subclassing works fine.

Go read the python-dev thread, there is a lot more info there....

b.bum