pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Confused on syntax

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

[ I know our mails have crossed, and I addressed some of this
  in the earlier, longer message, but to distill the problems
  down more concisely: ]


> class ConverterController(pyobjc.runtime.NSObject):

[1]
That won't work for the same reason you can't directly
subclass Python lists or dictionaries. They are objects,
but not classes. Look in you're Python lib for UserDict.py
and UserList.py -- which are examples of class wrappers
around a non-class object. You would need to do something
similar for Cocoa classes -- which are not Python classes.

 We're going to look for a general solution to this problem:
Jim Fulton and Don Beaudry both (I think) did some work on
"extension classes" and other ways around this problem in
Python -- and I think Python is moving towards a more
general solution eventually.
 We might try fixing it without waiting for Python 2.X to
fix the problem (looking at those previous attempts).
 We might be able to add more introspection to the bridge
to make it easier to automatically generate, or make a
generic one-size-fits-all class wrapper.


[2]
 I haven't yet been able to load and reanimate an IB Nib file
from Python. I think this is a much easier problem than [1]
above. I'll try to post what I've tried and what didn't work
in case anyone else wants to give it a try.

-- Steve Majewski

Re: [Pyobjc-dev] What did I do wrong?

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

What version of Python are you using ? One of the beta releases?
My patch was accepted into the 2.1 final, so that should work.

My copy of Python2.1/lib/distutils/unixccompiler.py  has a line:

    src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"]

in the beta (and maybe the final candidate) releases, the ".m" is
missing.

-- Steve.

On Fri, 27 Apr 2001, Deirdre Saoirse Moen wrote:

> OK, I figured that out -- now I'm up to the problem Steve had last
> November with not having pyobjc import correctly. I finally just
> chickened out and grabbed his binaries so I could get something done.
>
>
> >% /usr/local/bin/python setup.py install
> >running install
> >running build
> >running build_ext
> >building 'pyobjc' extension
> >Traceback (most recent call last):
> >   File "setup.py", line 23, in ?
> >     ext_modules = [Extension("pyobjc", sourceFiles)],
> >   File "/usr/local/lib/python2.0/distutils/core.py", line 157, in setup
> >     raise SystemExit, "error: " + str(msg)
> >SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')
>

Re: [Pyobjc-dev] A pathetic plea for understanding (MacOS X)

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

On Thu, 26 Apr 2001, Deirdre Saoirse Moen wrote:

> I heard about this project on the Jython list and, frankly, it seems
> a more straightforward way of handling the problem of making
> ProjectBuilder/InterfaceBuilder projects.
>
> The catch: I have a lot of python experience, but not a lot mixing it
> with other languages. Even looking through the archives, it's not
> clear to me what is done and what might need to be done.


The best thing for now is probably to look at and try the HelloWorld
program I posted a while back, and look at the apple docs for the
Cocoa classes used. If there's anything you don't understand about it,
ask and I'll try to explain. ( I probably should do a version of the
same program in objective C for comparison, and maybe annotate the
example a bit more. )

> To put it simply, I want to build Cocoa projects and code them in
> Python. I'm learning ObjC (I learned it a few years ago but not
> enough to get fully over the learning curve) and I don't know Java.

Hehe! ;-)  That's sort of what I was hoping for when I got involved.

The truth is that it's not really much of a shortcut right now --
you have to be able to understand enough objective-c to read and
understand the apple Foundation and AppKit docs.

One the bright side, if you already know C, you can .literally. learn
objective-C in a day. ( Learning the whole class library is another
matter! )  And I've been learning lots about the objc runtime by
hacking on PyObjC. ( If you don't know C, I'm afraid that's not a
very bright side! )


> This means I'll want to subclass Cocoa classes in Python -- how close
> is this project to allowing me to do that? Is there some kind of
> guide for how I'd do it either in Jython OR PyObjC? (Ultimately, I'd
> like to try it both ways -- and I'd be more than happy to put up a
> page detailing what has to be done).

You can't subclass Cocoa classes in Python -- objective C classes
are Python objects but not Python classes.  This is the notorious
class/object barrier in Python, and why you need wrapper classes
around dicts and lists and can't directly subclass them.
 You could do the same thing: write a Python wrapper around an
objective C class and subclass that. I'm not sure how I could write
a universal wrapper for all objective-C classes without adding
more introspection capabilities (which is something that's planned,
but not built in -- it can be done with the Neo class inspector --
I'll have to put up some updated instructions on how to get and use
that from Python  -- you can grab the standalone app at:
<http://www.neodata-inc.com/Eng/Self_Introspector.html> )

I would have to say it's not ready for prime time yet.
I don't think you could write a whole non-toy Cocoa app with
Python at present. I haven't been able to get delegate objects
working properly -- which, in the absence of direct subclassing
is probably a requirement. I think I'm going to have to build
an objc-runtime lib from Darwin sources with debugging info,
because I haven't been able to locate the problem with gdb.

I have high hopes for it eventually -- some Apple folks on
other mainling lists have indicated an interest on their part
in opening up ProjectBuilder/InterfaceBuilder to support other
languages,  but I haven't yet figured out how to reanimate a
IB Nib  file from Python yet.

There's a lot of stuff I haven't explored fully yet: for example,
you can load your own objective-C classes as easily as you can
load the AppKit classes. (I've done this with the NeoData class
inspector) and I can say there's a lot less "impedence difference"
between Python and objective-C than between Python and C -- it
makes mixed language programming much easier. I haven't explored
the notion of doing most of a application framework in objective-C
and scripting/customizing  it from Python, but this would
probably work right now. ( Although getting the delegates working
would make it better. )

I would have to admit that right now, PyObjC is mostly for the
adventurous hacker -- but I would sure like to get a few more
adventurous souls to take a hack at it!


-- Steve Majewski

[Pyobjc-dev] Confused on syntax

[Deirdre S. M. <de...@de...>]

I realize that I asked Steve a lot of questions and others might be 
able to answer and/or shed some light on. My ObjC was never really 
very good (I'm trying to work on that <g>) and I'm trying to make the 
paradigm leap at the same time.

I'm trying to create a Python version of the Currency Converter 
tutorial (start smallish, I figured). I figured I'd keep the two 
classes (Converter and ConverterController) as intended and wrestle 
with the main function after that, cribbing heavily from Steve.

Converter.py looks right (and the python interpreter doesn't 
complain). But when it gets to the ConverterController class (where 
all the fun is), my understanding just stops cold.

The .h file is:

#import <Cocoa/Cocoa.h>

@interface ConverterController : NSObject
{
     IBOutlet id converter;
     IBOutlet id dollarField;
     IBOutlet id rateField;
     IBOutlet id totalField;
}
- (IBAction)convert:(id)sender;
@end

It seems to me that this has got to have a syntax something like:

# ConverterController.py

import pyobjc
import Converter

class ConverterController(pyobjc.runtime.NSObject):
	def __init__(self):
		self.converter = pyobjc.runtime.IBOutlet(id)
		self.dollarField = pyobjc.runtime.IBOutlet(id)
		self.rateField = pyobjc.runtime.IBOutlet(id)
		self.totalField = pyobjc.runtime.IBOutlet(id)
	def convert(sender):
		amt = 	self.dollarField.floatValue()
		rate = 	self.rateField.floatValue()
		total =	self.converter( amt, rate )
		self.totalField.setFloatValue(total)
		self.rateField.selectText(self.rateField)

Am I even close here?

Re: [Pyobjc-dev] What did I do wrong?

[Deirdre S. M. <de...@de...>]

OK, I figured that out -- now I'm up to the problem Steve had last 
November with not having pyobjc import correctly. I finally just 
chickened out and grabbed his binaries so I could get something done.


>% /usr/local/bin/python setup.py install
>running install
>running build
>running build_ext
>building 'pyobjc' extension
>Traceback (most recent call last):
>   File "setup.py", line 23, in ?
>     ext_modules = [Extension("pyobjc", sourceFiles)],
>   File "/usr/local/lib/python2.0/distutils/core.py", line 157, in setup
>     raise SystemExit, "error: " + str(msg)
>SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')

-- 
--
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

[Pyobjc-dev] What did I do wrong?

[Deirdre S. M. <de...@de...>]

% /usr/local/bin/python setup.py install
running install
running build
running build_ext
building 'pyobjc' extension
Traceback (most recent call last):
   File "setup.py", line 23, in ?
     ext_modules = [Extension("pyobjc", sourceFiles)],
   File "/usr/local/lib/python2.0/distutils/core.py", line 157, in setup
     raise SystemExit, "error: " + str(msg)
SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')

(I'd have searched the archives on this one more carefully, but 
they've been down for an hour now. Remind me to wget them tomorrow)

[Pyobjc-dev] A pathetic plea for understanding (MacOS X)

[Deirdre S. M. <de...@de...>]

I heard about this project on the Jython list and, frankly, it seems 
a more straightforward way of handling the problem of making 
ProjectBuilder/InterfaceBuilder projects.

The catch: I have a lot of python experience, but not a lot mixing it 
with other languages. Even looking through the archives, it's not 
clear to me what is done and what might need to be done.

To put it simply, I want to build Cocoa projects and code them in 
Python. I'm learning ObjC (I learned it a few years ago but not 
enough to get fully over the learning curve) and I don't know Java.

This means I'll want to subclass Cocoa classes in Python -- how close 
is this project to allowing me to do that? Is there some kind of 
guide for how I'd do it either in Jython OR PyObjC? (Ultimately, I'd 
like to try it both ways -- and I'd be more than happy to put up a 
page detailing what has to be done). 

Re: [Pyobjc-dev] Bridging enumerated types

[Leigh S. <le...@to...>]

Thanks for the tip, it turns out there is a nifty little utility h2py 
that will churn out a python source file from #defines in .h files. This 
needs extending to manage enums but that shouldn't be all that 
difficult. Therefore I can just add this utility into the build script 
of the MusicKit framework and pump out a python script. I'll see if the 
Python people will incorporate the changes back into the build.
--
Dr. Leigh Smith
tomandandy

le...@to... (MIME)
http://www.tomandandy.com
89 Greene St. 2nd Floor, New York, NY 10012, USA
+1-212-334-0421 (W) +1-212-431-4115 (Fax)

Re: [Pyobjc-dev] Bridging enumerated types

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

Have a look at they way python builds the socket.py library.  In particular, it
has a look at the system header files and defines constants within the socket.py
module based on values found in system specific headers.

It is more designed for handling the changes in values across different
platforms, but may provide some useful seeds for doing what you want!

Sounds like a very cool project!

b.bum

On Sun, 15 Apr 2001, Leigh Smith wrote:

> The Python-ObjC works really well for interfacing the MusicKit (non-GUI) to
> Python, thanks to the developers!
> 
> One issue we face is that the MusicKit uses a very large collection (200
> odd) of enumerated types for musical note parameters (pitch, duration,
> synthesis parameters etc). It would be really nice to define these within
> Python, but to avoid synchronizing between two code bases, it would be nicer
> to have them automatically derived from the C source.
> 
> Two approaches come to mind, either I create a C function that includes the
> params.h file (containing the enums) and then exports them via the usual
> Python C bridge or I write a python script to read a header file, extract
> all the enums (including integer assignments) and create the variables then.
> 
> The issues I can see are the former could require a lot of repetitive code
> (possibly automatically created using sed/Python/perl) and would require
> that binary to be complied and placed into the standard Python library area.
> Each program would then need a "import MusicKit" statement, which could (I
> assume) do the NSBundle.load('MusicKit.framework') statement.
> 
> The latter parsing approach would need to create all the variables at run
> time (obviously possible, but I currently lack that knowledge of Python) and
> would follow the NSBundle.load('MusicKit.framework') statement with
> something like enumParse('MusicKit.framework/Headers/params.h').
> 
> Perhaps there is already some similar solution since this is not ObjC
> specific, any bridge to a large C code base using many enums would have the
> same issue. Of course I'd look to contribute the solution to either pyobjc
> or the standard Python archive, depending on where it is best located.
> 
> Any suggestions?
> 
> 
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

[Pyobjc-dev] Bridging enumerated types

[Leigh S. <le...@to...>]

The Python-ObjC works really well for interfacing the MusicKit (non-GUI) to
Python, thanks to the developers!

One issue we face is that the MusicKit uses a very large collection (200
odd) of enumerated types for musical note parameters (pitch, duration,
synthesis parameters etc). It would be really nice to define these within
Python, but to avoid synchronizing between two code bases, it would be nicer
to have them automatically derived from the C source.

Two approaches come to mind, either I create a C function that includes the
params.h file (containing the enums) and then exports them via the usual
Python C bridge or I write a python script to read a header file, extract
all the enums (including integer assignments) and create the variables then.

The issues I can see are the former could require a lot of repetitive code
(possibly automatically created using sed/Python/perl) and would require
that binary to be complied and placed into the standard Python library area.
Each program would then need a "import MusicKit" statement, which could (I
assume) do the NSBundle.load('MusicKit.framework') statement.

The latter parsing approach would need to create all the variables at run
time (obviously possible, but I currently lack that knowledge of Python) and
would follow the NSBundle.load('MusicKit.framework') statement with
something like enumParse('MusicKit.framework/Headers/params.h').

Perhaps there is already some similar solution since this is not ObjC
specific, any bridge to a large C code base using many enums would have the
same issue. Of course I'd look to contribute the solution to either pyobjc
or the standard Python archive, depending on where it is best located.

Any suggestions?

Re: [Pyobjc-dev] Why syntax?

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

On Thursday, April 12, 2001, at 06:04 PM, Andrew Zeldis wrote:
> On Thursday, April 12, 2001, at 05:11 PM, Bill Bumgarner wrote:
>
>> 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
>
> I've been under the impression that all available selectors were 
> somehow compiled or registered with the ObjC runtime before anything 
> else happened.  Is it possible to define new selectors during runtime, 
> post-load?  If so, I can see how the dynamicicity (?) of ObjC would 
> muck this up, but as I understand it all possible selectors will be 
> available for discovery if the object is available.

All selectors are defined as a bundle/library is loaded.  However, it is 
trivial to define new selectors at runtime (though that is rarely done 
because there is rarely a need).  One particular twist on the complexity 
is that all of the methods available for a particular object are not 
necessarily possible to determine at runtime.   In particular, an object 
may delegate, forward, or proxy some certain set of method invocations 
to other classes, instances, or runtimes at runtime based on a 
dynamically changing set of criteria.

I.e. in ObjC, like SmallTalk, Python, or other similarly purely dynamic 
languages, anything *can* go.   Not that it generally *does* go...


>> 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.
>
> Oh yes, I assumed that using "with" in the method name was a standard, 
> and so could be dropped - like getBlah and setBlah in jython...  Is 
> that true?

Not true;   initWith or stringWith is generally a standard when applying 
state to an object based upon the presence of some other object.  
However, the "With" is merely a naming convention.

> Also, I didn't realize ObjC methods were ordered...  Does this mean 
> then that it's wrong to think of them as key/value or named parameters, 
> but as a single method name where variables are "interpolated"?

Exactly;  the syntax implies interpolation and is derived directly from 
the SmallTalk heritage of Objective-C.   It really isn't that the 
methods are ordered, but that the method name is entirely defined by the 
stuff proceding the colons.  I.e. the method:

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)ti target:(id)aTarget 
selector:(SEL)aSelector userInfo:(id)userInfo repeats:(BOOL)yesOrNo;

Has the literal name "timerWithTimeInterval: target: selector: userInfo: 
repeats:".

Consider it this way;  every method can be declared as a C function with 
two "hidden" parameters, self and _cmd.   Just like when calling 
strstrc(), you can't change the order of parameters to an ObjC method 
and have it mean or do the same thing!

For academice purposes, the above method could be defined as a C 
function like:

NSTimer *myCFuncThatBehavesExactlyLikeThatMethod(id self, SEL _cmd, 
NSTimeInterval ti, id aTarget, SEL aSelector, id userInfo, BOOL yesOrNo);

For those folks particularly amused by the bowels of ObjC, it is 
possible and easy to edit the runtime such that a function declared like 
the above could easily replace the implementation of a method declared 
like the way-above.   If you can't figure it out-- it ain't totally 
obvious, don't feel bad, send email and I'll post an example.

> Is there a possibility of more than one selector containing the same 
> "keys" in a different order?

Yes and no;  Yes in that the methods -foo:bar: and -bar:foo: are very 
much different;  no in that there is no concept of "keys" in ObjC.  The 
method calling syntax/convention is derived purely from smalltalk and 
exists solely for clarity of reading source.

>> 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.
>
> Well, probably because I'm syntax mad, but this doesn't seem like an 
> especially small reward.  Especially if you're trying to evangelize 
> it.  Right now PyObjC looks very little like Python, *or* ObjC; if the 
> thing looked more like python we'd basically have a native gui 
> framework finished and *polished*.

I would agree if the goal were to make ObjC objects in python appear to 
transparently behave like Python objects and vice-versa.  However, the 
reality is that any intra-language bridge will *always* incur both a 
performance penalty [though ObjC is *much* faster than python] and a 
paradigm shift.

It is the paradigm shift that really matters.

In the 12 years (good GOD that long???!?!! wow! how time flies when you 
are having fun!) that I have been writing ObjC code, there have been 
numerous attempts-- some written by me, most not-- of melding ObjC with 
Perl, Python, TCL, Java, and a whole bunch of other languages.

The one thing that is abundantly clear-- the one thing that has left 
deeeeppp and lllllooooonnnnnggg scars-- is that language A is not like 
language B.   Attempting to make the two languages totally transparently 
intra-compatible is reallyreallyreally neat, but it actually does not 
serve the goal of USEFULNESS.

As much as it seems to be ttractive to be able to message between Python 
and ObJC in a wholly transparent manner, it really does not serve the 
purposes of the developer to the best degree.  In particular, it is 
useful to the developer to be able to read through a body of code and go 
"oh, that consistently weird bit of syntax involving underscores 
actually means I'm messaging into a different OO runtime".  Very 
useful.  Hugely useful;  in my experience, being able to easily 
differentiate between native and foreign invocations-- be it 
intra-language or inter-runtime-- has saved *hundrends* of hours of 
debugging time.

Not that I don't think totally transparent inter-language coding is NOT 
cool-- I do think its cool and it would be really neat to achieve.  
However, I do *firmly*-- i.e. based on lots of experience, jaded or 
not-- believe that such an achievement would not yield an environment 
that maximizes developer productivity!

> It doesn't look like the ObjC runtime provides anything more than 
> NSSelectorFromString, is that  right?  So basically it'd have to run 
> through all the permutations of the parameter names, testing each one, 
> until it matched.  Maybe a little slow, and annoying, but it doesn't 
> seem that hard...?

Not hard... except the fuzzy matching and that it is several orders of 
magnitude slower than what is in place today.... and that it would 
occasionally and in very weird circumstances invoke totally the wrong 
method in a fashion that would be incredibly hard to debug, if it was 
even reproducible (as is the case with any 
non-ordered-applied-to-ordered test).

> Anyway, now that it's building with distutils (thanks!) I think I'll 
> attempt it - just please don't say I told you so!

Go for it!  I'm certainly not such an egotist to think that my opinions 
are the end all / be all.  If you figure out a way to pull it off, I'll 
adopt your code in a millisecond!!

> Are the NSFunctions  (like NSSelectorFromString) made available to 
> Python somewhere?

Nope;   actually,  we really need to clean up the whole pyobjc module 
and:

	- remove legacy cruft

	- remove GnuObjC/GnuStep support until someone volunteers to (a) 
update it to modern standards and (b) maintain it over time

	- modernize some of the facilties within the module to map to 
low-level runtime servicves that are "new" to OpenStep 4.2 and beyond 
[OS4.2 and prior being the primary platform under which the module was 
"designed"].

b.bum

[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

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

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?

[Bob S. <bob...@ma...>]

>> From: Andrew Zeldis <ae...@ma...>
>> 
>>> A secondary problem is that key/value arguments are not ordered.
>> 
>> Also, I didn't realize ObjC methods were ordered...  Does this mean
>> then that it's wrong to think of them as key/value or named parameters,
>> but as a single method name where variables are "interpolated"?
>> 

Yes. There is a single method name, not key/value pairs.

>> Is there a possibility of more than one selector containing the same
>> "keys" in a different order?
>> 

Yes.

result (test program follows):

Apr 12 20:52:32 testTool[583] cat bat hat
Apr 12 20:52:32 testTool[583] cat hat bat

testTool has exited with status 0.

--test program--

//  testthing.h

#import <Foundation/Foundation.h>

@interface testthing : NSObject { }
- (void) testBy: (NSString *)who wearing:(NSString *)with weilding:(NSString
*)what;
- (void) testBy: (NSString *)who weilding:(NSString *)what wearing:(NSString
*)with;
@end

//  testthing.m

#import "testthing.h"

@implementation testthing
- (void) testBy: (NSString *)who wearing:(NSString *)with weilding:(NSString
*)what {
    NSLog([who stringByAppendingFormat:@" %@ %@", with, what]);
}
- (void) testBy: (NSString *)who weilding:(NSString *)what wearing:(NSString
*)with {
    NSLog([who stringByAppendingFormat:@" %@ %@", what, with]);
}
@end


// main.m

#import <Foundation/Foundation.h>
#import "testthing.h"

int main (int argc, const char * argv[])
{
    testthing *tthing;
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    tthing = [[[testthing alloc] init] retain];
    [tthing testBy: @"cat" weilding:@"bat" wearing:@"hat"];
    [tthing testBy: @"cat" wearing:@"hat" weilding:@"bat"];
    [pool release];
    return 0;
}

Fwd: [Pyobjc-dev] Why syntax?

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

Seems to be held in moderation-- wanted to make sure it was posted [will 
reply later] because I forgot the bloody admin passwrod.

b.bum

Begin forwarded message:

> From: Andrew Zeldis <ae...@ma...>
> Date: Thu Apr 12, 2001  06:04:23 PM US/Eastern
> To: Bill Bumgarner <bb...@co...>
> Cc: pyo...@li...
> Subject: Re: [Pyobjc-dev] Why syntax?
>
>
>
> On Thursday, April 12, 2001, at 05:11 PM, Bill Bumgarner wrote:
>
>> 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
>
> I've been under the impression that all available selectors were 
> somehow compiled or registered with the ObjC runtime before anything 
> else happened.  Is it possible to define new selectors during runtime, 
> post-load?  If so, I can see how the dynamicicity (?) of ObjC would 
> muck this up, but as I understand it all possible selectors will be 
> available for discovery if the object is available.
>
>> 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.
>
> Oh yes, I assumed that using "with" in the method name was a standard, 
> and so could be dropped - like getBlah and setBlah in jython...  Is 
> that true?
>
> Also, I didn't realize ObjC methods were ordered...  Does this mean 
> then that it's wrong to think of them as key/value or named parameters, 
> but as a single method name where variables are "interpolated"?
>
> Is there a possibility of more than one selector containing the same 
> "keys" in a different order?
>
>> 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.
>
> Well, probably because I'm syntax mad, but this doesn't seem like an 
> especially small reward.  Especially if you're trying to evangelize 
> it.  Right now PyObjC looks very little like Python, *or* ObjC; if the 
> thing looked more like python we'd basically have a native gui 
> framework finished and *polished*.
>
> It doesn't look like the ObjC runtime provides anything more than 
> NSSelectorFromString, is that  right?  So basically it'd have to run 
> through all the permutations of the parameter names, testing each one, 
> until it matched.  Maybe a little slow, and annoying, but it doesn't 
> seem that hard...?
>
> Anyway, now that it's building with distutils (thanks!) I think I'll 
> attempt it - just please don't say I told you so!
>
> Are the NSFunctions  (like NSSelectorFromString) made available to 
> Python somewhere?

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

[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] HelloWorld.py (demo code)

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

On Fri, 6 Apr 2001, Bill Bumgarner wrote:

> Very nice!  Very, very cool.... a HUGE bit of progress here.

Thanks, Bill.

I don't think it's practical for writing real Cocoa apps in
python yet -- not until I get Delegates to work and we can
figure out how to load and animate a IB Nib file from Python.

But now that we've got a release up on SF (I'll try to get
some docs up there soon!) and can demonstrate that it can do
*SOMETHING* , it might encourage a few more people to look
at it.

I sent a notice out on the python and pythonmac mailings lists.
I'm considering whether to forward one to macosx-dev.

-- Steve Majewski

Re: [Pyobjc-dev] HelloWorld.py (demo code)

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

Very nice!  Very, very cool.... a HUGE bit of progress here.

Add an Examples/ directory to the sourceforge repository (if it isn't 
already there) and shove this into the examples.

I'll have to resurrect my services provider.

b.bum

On Friday, April 6, 2001, at 04:15 PM, Steven D. Majewski wrote:

> # HelloWorld.py
> #
> # You have to run this script from the command line with
> # the full pathname for python:
> #    /usr/local/bin/python HelloWorld.py
> #
> # or else run from DropShell or gdb. Anything else and you will get a:
> #       Error 1011 in _sendFinishLaunchingNotification
> # and it wont work.
> #
> # -- Steve Majewski <sd...@Vi...>
> #
>
> import pyobjc
> from time import sleep
>
> rt = pyobjc.runtime
>
> def main():
>
>     pool = rt.NSAutoreleasePool()
>     # Load Application Framework:
>     rt.NSBundle.bundleWithPath_(
>         '/System/Library/Frameworks/AppKit.framework').load()
>
>     NSApp = rt.NSApplication.sharedApplication()
>
>     win = rt.NSWindow.alloc()
>     frame = ((200.0, 300.0), (250.0, 100.0))
>     win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0)
>     win.setTitle_ ('HelloWorld')
>     win.setLevel_ (3)                   # floating window
>
>     hel = rt.NSButton.alloc().initWithFrame_ (((10.0, 10.0), (80.0, 
> 80.0)))
>     win.contentView().addSubview_ (hel)
>     hel.setBezelStyle_( 4 )
>     hel.setTitle_( 'Hello!' )
>
>     beep = rt.NSSound.alloc()
>     beep.initWithContentsOfFile_byReference_(
>         '/System/Library/Sounds/tink.aiff', 1 )
>     hel.setSound_( beep )
>
>     bye = rt.NSButton.alloc().initWithFrame_ (((100.0, 10.0), (80.0, 
> 80.0)))
>     win.contentView().addSubview_ (bye)
>     bye.setBezelStyle_( 4 )
>     bye.setTarget_ (NSApp)
>     bye.setAction_ ('stop:')
>     bye.setEnabled_ ( 1 )
>     bye.setTitle_( 'Goobye!' )
>
>     adios = rt.NSSound.alloc()
>     adios.initWithContentsOfFile_byReference_(
>         '/System/Library/Sounds/Basso.aiff', 1 )
>     bye.setSound_( adios )
>
>     win.display()
> #    win.makeKeyAndOrderFront_ (NSApp)  ## This doesn't seem to  work
>     win.orderFrontRegardless()          ## but this one does
>
>     NSApp.run()
>
>
> if __name__ == '__main__' : main()

[Pyobjc-dev] HelloWorld.py (demo code)

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

# HelloWorld.py
#
# You have to run this script from the command line with
# the full pathname for python:
#    /usr/local/bin/python HelloWorld.py
#
# or else run from DropShell or gdb. Anything else and you will get a:
#       Error 1011 in _sendFinishLaunchingNotification
# and it wont work.
#
# -- Steve Majewski <sd...@Vi...>
#

import pyobjc
from time import sleep

rt = pyobjc.runtime

def main():

    pool = rt.NSAutoreleasePool()
    # Load Application Framework:
    rt.NSBundle.bundleWithPath_(
        '/System/Library/Frameworks/AppKit.framework').load()

    NSApp = rt.NSApplication.sharedApplication()

    win = rt.NSWindow.alloc()
    frame = ((200.0, 300.0), (250.0, 100.0))
    win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0)
    win.setTitle_ ('HelloWorld')
    win.setLevel_ (3)                   # floating window

    hel = rt.NSButton.alloc().initWithFrame_ (((10.0, 10.0), (80.0, 80.0)))
    win.contentView().addSubview_ (hel)
    hel.setBezelStyle_( 4 )
    hel.setTitle_( 'Hello!' )

    beep = rt.NSSound.alloc()
    beep.initWithContentsOfFile_byReference_(
        '/System/Library/Sounds/tink.aiff', 1 )
    hel.setSound_( beep )

    bye = rt.NSButton.alloc().initWithFrame_ (((100.0, 10.0), (80.0, 80.0)))
    win.contentView().addSubview_ (bye)
    bye.setBezelStyle_( 4 )
    bye.setTarget_ (NSApp)
    bye.setAction_ ('stop:')
    bye.setEnabled_ ( 1 )
    bye.setTitle_( 'Goobye!' )

    adios = rt.NSSound.alloc()
    adios.initWithContentsOfFile_byReference_(
        '/System/Library/Sounds/Basso.aiff', 1 )
    bye.setSound_( adios )

    win.display()
#    win.makeKeyAndOrderFront_ (NSApp)  ## This doesn't seem to  work
    win.orderFrontRegardless()          ## but this one does

    NSApp.run()


if __name__ == '__main__' : main()

Re: [Pyobjc-dev] Time for a release ?

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

Sure.

Of course, there is always .9[0-9][0-9]... numbers are neat that way, 
there is always in infinite # of 'em available between two points.

(Seriously, though, 0.6 is more appropriate)

On Friday, April 6, 2001, at 12:24 PM, Steven D. Majewski wrote:

>
>
> I bumped the version in ObjC.h up to .56, then I saw that
> you set it to 0.9 in setup.py.
>
> Considering that we're going to tackle some major upgrading
> and weeding of obsolete methods, I think we need to leave
> a bit more "space" before a 1.0 release.
>
> How about 0.6 ?
>
> -- Steve
>
>

Re: [Pyobjc-dev] Time for a release ?

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

I bumped the version in ObjC.h up to .56, then I saw that
you set it to 0.9 in setup.py.

Considering that we're going to tackle some major upgrading
and weeding of obsolete methods, I think we need to leave
a bit more "space" before a 1.0 release.

How about 0.6 ?

-- Steve

Re: [Pyobjc-dev] Time for a release ?

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

Just to back this up - I haven't been able to work with it much recently but
I did get the pyobjc module built with python 2.1b2 using distutils (after a
"patch" of my own to add .m).  It worked like a charm.

It would be great if pyObjC could be included in standard python as an
optional platform-specific module - they do stuff like that for sunAudioDev
etc right?  Like, part of the standard dist, only built on appropriate
platform?

Anyway, cheers to you to for the great work!

Re: [Pyobjc-dev] Time for a release ?

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

That makes sense to me.    It is definitely more useful than the last 
release.

python setup.py sdist  will do the right thing. :-)

I believe that the next step should be to look at replacing all the 
legacy stuff and cleaning up the method dispatch issues....

b.bum


On Friday, April 6, 2001, at 01:43 AM, Steven D. Majewski wrote:

>
> Bill -- I submitted that patch to add ".m" files to python, and
> I got a note it was accepted.
>
> With your changes to use distutils, it ought to build and install
> out of the box on OSX with Python2.1 once it is released.
> ( Which will probably be soon. )
>
> I think it's probably time for us to put out a release.
>
> I changed the #ifdefs, which, because I originally didn't know
> how to test for OSX, were a hack that probably broke the build
> for other platforms.
>
> Now:
>   In ObjC.h, MACOSX is defined if defined(__APPLE__) && 
> defined(__MACH__)
>
>   #ifdef MACOSX is used elsewhere.
>
> I did it that way because I think the __APPLE__ & __MACH__ trick is
> a little too tricky -- I would rather eventually change it so that
> setup adds a -D line with system name.
>
> I tried to make it #define DARWIN at first, but the compiler
> complained about it. Somewhere there is a precompiled header
> that uses DARWIN, but I didn't want to rely on it being defined
> elsewhere until I can find it.
>
> I'll probably try to see if I can shake out any more bugs, and
> then make a tar file and put it on sourceforge as a release.
>
> -- Steve Majewski
>
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev