pyobjc-dev

[Pyobjc-dev] Why syntax?

[Andrew Z. <az...@we...>]

This is probably a dumb question, but there isn't much of an archive on 
this topic (since there's really only been two people posting...)

Why does PyObjC mangle method names, instead of using named parameters?  
I understand why it's done that way for the Java bridge - Java is an 
inferior language.  But why for Python?  I'd like to see:

	win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0)

become

	win.init(contentRect=frame, styleMask=15, backing=2, defer=0)

If you've looked at Jython, it does a lot to "pythonify" java methods 
and classes - it lets you specify thing that look like bean properties 
in constructors, for instance, and makes things that look like 
properties available as attributes.  It would be nice to do similar 
things for the PyObjC module, to make it as Pythonic as possible...

This seems really obvious, however, so I'm sure there's a reason why it 
hasn't been done.  Please enlighten.

Re: [Pyobjc-dev] Why syntax?

[Bill B. <bb...@co...>]

Because the mangling that is done now is really easy-- simply 
substitute : for _ -- whereas the second form is considerably harder.

One key difference between Java and ObjC is that ObjC doesn't require us 
to know the method signatures-- the names-- prior to actually invoking 
the method.  We can effectively "catch" the request for a particular 
method the first time an execution is attempted, and generate the ObJC 
name of the method at that point in time.   It is 100% dynamic and all 
at runtime;  there is no need for any prior knowledge regarding the 
existence of a method or class.

Jython-- on the other hand-- must compile the Python classes into JVM 
byte code prior to even loading the class, much less executing a 
method.   That is, every method that is to be executed must be compiled 
into the JVM byte code stream prior to loading the class.

A secondary problem is that key/value arguments are not ordered.   I.e. 
Ignoring for a moment that "win.init(contentRect=frame, styleMask=15, 
backing=2, defer=0)" drops the "With", the order with which the 
key/value arguments are passed to the init() function cannot be known.   
As such, it makes reconstructing the method really hard;  nearly 
impossible.

This was actually discussed at great length in '96 or '97 when Lele, 
myself and others were actively working on the ObjC module.  We 
determined then that the amount of work did not justify the small reward.

b.bum

On Thursday, April 12, 2001, at 04:11 PM, Andrew Zeldis wrote:

> This is probably a dumb question, but there isn't much of an archive on 
> this topic (since there's really only been two people posting...)
>
> Why does PyObjC mangle method names, instead of using named 
> parameters?  I understand why it's done that way for the Java bridge - 
> Java is an inferior language.  But why for Python?  I'd like to see:
>
> 	win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0)
>
> become
>
> 	win.init(contentRect=frame, styleMask=15, backing=2, defer=0)
>
> If you've looked at Jython, it does a lot to "pythonify" java methods 
> and classes - it lets you specify thing that look like bean properties 
> in constructors, for instance, and makes things that look like 
> properties available as attributes.  It would be nice to do similar 
> things for the PyObjC module, to make it as Pythonic as possible...
>
> This seems really obvious, however, so I'm sure there's a reason why it 
> hasn't been done.  Please enlighten.
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Why syntax?

[Andrew Z. <az...@we...>]

Oh, sorry about the moderation.  I keep accidentally posting from the 
wrong account.

Is there an archive of your 3-years-ago conversation about this?  Maybe 
it would be easier to just forward that to me...  Although this is 
definitely helping me understand ObjC more!

I have to say I'm disappointed to find out ObjC parameters are ordered - 
I thought the naming made that unnecessary.  Order-agnosticism would 
seem to me one of the main benefits of having names.

Re: [Pyobjc-dev] Why syntax?

[Steven D. M. <sd...@mi...>]

On Fri, 13 Apr 2001, Andrew Zeldis wrote:

> Is there an archive of your 3-years-ago conversation about this?  Maybe
> it would be easier to just forward that to me...  Although this is
> definitely helping me understand ObjC more!

There WAS an archive at python.org among the retired sigs section,
but now when I try to pull up the archive page, I get a "404 Not Found".

But I read thru it a while ago, and I think you've already heard the
gist of it.

I think it may be worthwhile revisiting this issue later --
 [1] since jython can access cocoa classes, it might be worthwhile
    trying to make the syntax more uniform ( however, there are
     other differences between jython and pyobjc access to Cocoa
     classes, so it's probably never going to be source portable,
     and since Java has overloaded polymorphic methods jython has
     some extra language support for dispatching to the right method.)
 [2] I would like to add more introspective capabilities to pyobjc
    objects -- right now, you can't get any info by doing a dir()
    on an object as you can with native python objects. As was noted
    earlier in this thread, there's no list of methods being maintained
    by the bridge -- you just try calling a method, and if it's not
    there (I think it calls respondsToSelector: )  it'll return an error.
    Introspection CAN be added outside of the runtime (I've been
    playing with the Neo ClassInspector from Python/objc), but if it
    was added to the runtime, it would add some of the support for
    more intelligent method dispatch.


 Right now I'm concentrating on getting what's there working, on figuring
out how it works (Bill was using pyobjc back in the Next days, but I'm
still learning Cocoa, objective-c and pyobjc plumbing. ) and documenting
what's there.
 I think a redesign and a reimplementation is quite likely in the
future: this is version 0.6, and I'ld consider anything < 1 to
indicate experimental and quite likely to change.

 On other big issue it that objc-objects run into the python object-class
barrier. i.e. Eveything in Python is an object but not all objects are
members of classes. Like lists and dictionaries, pyobjc objects that
represent objective-c classes or instances aren't python classes or
instances. It would obviously be much easier and less awkward if
that was not the case.

-- Steve Majewski

[Pyobjc-dev] [Slightly OT] jython com.apple.cocoa vs. cpython pyobjc [was: Why syntax?]

[Steven D. M. <sd...@mi...>]

Since I brought up jython cocoa access vs. pyobjc:

Both bridges do:
 [1] some automatic conversion to and from equivalent types, for
    example, python and java strings or python strings and NSStrings.
 [2] automatic mapping of equivalent protocols or interfaces, for
    example, in pyobjc, NSArray instances returned from objc methods
    can be treated like python sequences, for example:
	>>> allbundles =  runtime.NSBundle.allBundles()
        >>> print allbundles[0]
        >>> for x in allbundles: print x

 However, in jython to Cocoa access, there are two bridges: Python
  to Java and Java to Objective-C, so you don't always get the
  benefit of automatic conversion or mapping. for example:


Jython 2.1a1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> from com.apple.cocoa.foundation import *
>>> for x in NSBundle.allFrameworks(): print x
...
Traceback (innermost last):
  File "<console>", line 1, in ?
AttributeError: __getitem__

# You need to get an objectEnumerator to do the equiv:

>>> for x in NSBundle.allFrameworks().objectEnumerator(): print x
...
NSBundle </System/Library/Frameworks/Foundation.framework> (loaded)
NSBundle </System/Library/Frameworks/JavaVM.framework> (loaded)
NSBundle </usr/lib/java> (loaded)
NSBundle </usr/lib> (loaded)
>>>


-- Steve Majewski