pyobjc-dev — CVS commit notices go here

[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

Re: [Pyobjc-dev] Doc, it hurts when I say +isKindOfClass...

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

Actually, all of those classes should be-- for all intents and 
purposes-- totally hidden from the pyobjc module from the ObjC side.  
They are all internal classes that are designed to support things like 
distributed objects [distant object, protocol checker (sort of), 
nsproxy], effeciency hacks [nsmutablestring proxy], or debuggin 
[nszombie].

In any case, they mostly stand in-- or act as proxies-- to other 
instances.  For example, an NSProxy is used to represent an object that 
actually resides in a different runtime.  The NSProxy speaks across an 
NSConnection instance such that any method invocation against NSProxy is 
passed across the wire and executed in the foreign runtime.  Very 
cool.   At runtime, it also menas that an NSProxy instance may very well 
exist, but is nearly indistinguishable from the object it is proxying.

NSProxy is a root class;  hence, doesn't inherit from NSObject and 
doesn't implement any of the standard methods.

b.bum


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

>
>
> In the following code, the classes in skiplist will all
> generate objective-c runtime exceptions if they are touched:
>
> ----
> from pyobjc import runtime,lookup_class
>
> _Pool = runtime.NSAutoreleasePool()
>
> skiplist = [ 'NSConcreteProtocolChecker', 'NSDistantObject',
>         'NSInvocationBuilder', 'NSMutableStringProxy', 
> 'NSProtocolChecker'
> ,
>         'NSProxy' , '_NSZombie' ]
>
> for x in runtime.__objc_classes__:
>         if x not in skiplist:
>                 print x
>                 print lookup_class(x)
> ----
>
>
> All of the exceptions happens in ObjCObject_new().
>
>
> #   NSConcreteProtocolChecker
> #   NSDistantObject
> #   NSMutableStringProxy
> #   NSProtocolChecker
> #   NSProxy
> # Apr 05 23:54:51 python[2259] *** Uncaught exception:
> <NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!
> #
> # caused by: [obj isKindOfClass: [NSAutoreleasePool class]]
> #
> #
> #   NSInvocationBuilder
> # Apr 05 23:54:41 python[2256] *** Uncaught exception:
> <NSInvalidArgumentException> target does not implement method
> #
> # caused by: [obj respondsToSelector:@selector (count)]
> #
> #
> #   _NSZombie           Bus error
>  (seems to be somewhere close to the one above)
>
> I'm quite willing to believe that whatever "_NSZombie" is, it
> probably shouln't be touched. Most likely all of the classes
> with a leading underscore in their names are not meant to be
> exposed and should be removed from the Python-Objc runtime.
>
> NSInvocationBuilder is undocumented (not even in the header
> files) and I'm even unable to see it in the Class Introspector.
>
> All of the first bunch, except for NSProxy are all subclasses of 
> NSProxy.
> NSProxy is another root class that is independent of NSObject.
> Looking at NSProxy with the Class Introspector, I can see that indeed,
> there is no class method for isKindOfClass: as there is in NSObject.
> ( NSObject has both a Class and an Instance isKindOfClass: )
>
>
> I was looking at this problem too see if it was related to some of
> the delegation bugs I've run into, but I'm now pretty convinced they
> are probably unrelated. I'm not sure if there is any likey case in
> which those classes would need to be called from Python -- perhaps
> they should all be removed from the runtime.
>
> For now, I'm going to leave them alone with just this warning:
>  don't try to access any of those classes from python.
>
> Does anyone know:
> Is there a reason that +[NSProxy isKindOfClass:] is not implemented
> or is it just an oversight (bug) ?
>
> -- Steve Majewski
>
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Time for a release ?

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

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] Doc, it hurts when I say +isKindOfClass...

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

In the following code, the classes in skiplist will all
generate objective-c runtime exceptions if they are touched:

----
from pyobjc import runtime,lookup_class

_Pool = runtime.NSAutoreleasePool()

skiplist = [ 'NSConcreteProtocolChecker', 'NSDistantObject',
        'NSInvocationBuilder', 'NSMutableStringProxy', 'NSProtocolChecker'
,
        'NSProxy' , '_NSZombie' ]

for x in runtime.__objc_classes__:
        if x not in skiplist:
                print x
                print lookup_class(x)
----


All of the exceptions happens in ObjCObject_new().


#   NSConcreteProtocolChecker
#   NSDistantObject
#   NSMutableStringProxy
#   NSProtocolChecker
#   NSProxy
# Apr 05 23:54:51 python[2259] *** Uncaught exception:
<NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!
#
# caused by: [obj isKindOfClass: [NSAutoreleasePool class]]
#
#
#   NSInvocationBuilder
# Apr 05 23:54:41 python[2256] *** Uncaught exception:
<NSInvalidArgumentException> target does not implement method
#
# caused by: [obj respondsToSelector:@selector (count)]
#
#
#   _NSZombie           Bus error
 (seems to be somewhere close to the one above)

I'm quite willing to believe that whatever "_NSZombie" is, it
probably shouln't be touched. Most likely all of the classes
with a leading underscore in their names are not meant to be
exposed and should be removed from the Python-Objc runtime.

NSInvocationBuilder is undocumented (not even in the header
files) and I'm even unable to see it in the Class Introspector.

All of the first bunch, except for NSProxy are all subclasses of NSProxy.
NSProxy is another root class that is independent of NSObject.
Looking at NSProxy with the Class Introspector, I can see that indeed,
there is no class method for isKindOfClass: as there is in NSObject.
( NSObject has both a Class and an Instance isKindOfClass: )


I was looking at this problem too see if it was related to some of
the delegation bugs I've run into, but I'm now pretty convinced they
are probably unrelated. I'm not sure if there is any likey case in
which those classes would need to be called from Python -- perhaps
they should all be removed from the runtime.

For now, I'm going to leave them alone with just this warning:
 don't try to access any of those classes from python.

Does anyone know:
Is there a reason that +[NSProxy isKindOfClass:] is not implemented
or is it just an oversight (bug) ?

-- Steve Majewski