pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Snowleopard GC & 64-bit (also easy_install)

[Ronald O. <ron...@ma...>]

On 19 Oct, 2009, at 16:36, Jonathan Wight wrote:

> What's the state of some of the non-mainline features of pyobjc these
> days? Particularly:
>
> * Any particular reason why latest build of pyobjc can't be installed
> via easy_install on Snow Leopard?

I haven't gotten around doing a release of the current state yet.

>
> * What's the current state of 64-bit _AND_ Garbage Collection with
> PyObjc on Snow Leopard? I have an app that is both - and PyObjc (at
> least w/Snow Leopard's pre-installed PyObjc) can't even be linked in
> (at least with GC).

PyObjC does not support GC.

The expand on that:

* AFAIK Python is not build correctly to link into GC enabled  
applications

* While I try to ensure that PyObjC's reference management is safe  
w.r.t. GC (using CFRetain/CFRelease rather than -retain/-release) I  
have never tested if this is sufficient. That means PyObjC is almost  
certainly unsafe w.r.t. GC.

Ronald

[Pyobjc-dev] Snowleopard GC & 64-bit (also easy_install)

[Jonathan W. <jwi...@to...>]

What's the state of some of the non-mainline features of pyobjc these  
days? Particularly:

* Any particular reason why latest build of pyobjc can't be installed  
via easy_install on Snow Leopard?

* What's the current state of 64-bit _AND_ Garbage Collection with  
PyObjc on Snow Leopard? I have an app that is both - and PyObjc (at  
least w/Snow Leopard's pre-installed PyObjc) can't even be linked in  
(at least with GC).

	Jon.

[Pyobjc-dev] [ pyobjc-Bugs-2881682 ] License?

[SourceForge.net <no...@so...>]

Bugs item #2881682, was opened at 2009-10-19 13:59
Message generated for change (Tracker Item Submitted) made by kiilerix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=2881682&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kiilerix (kiilerix)
Assigned to: Nobody/Anonymous (nobody)
Summary: License?

Initial Comment:
Could you please make a clear statement about the pyobjc license on http://pyobjc.sourceforge.net/ or about or something like that

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=2881682&group_id=14534

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Nathan <nat...@gm...>]

On Wed, Sep 30, 2009 at 3:12 PM, Ronald Oussoren <ron...@ma...> wrote:
> Hi,
>
> Is anyone still interested in PyObjC on OSX 10.4?  I haven't done any
> development on 10.4 in a long time and while having 10.4 support would be
> nice to have I don't think I'll ever get around to finishing 10.4 support in
> PyObjC 2.x.

We are not.  We dropped PPC and Tiger support in 2008.

~ Nathan

Re: [Pyobjc-dev] Blocks support in PyObjC

[Ronald O. <ron...@ma...>]

On 12 Oct, 2009, at 11:11, Ronald Oussoren wrote:

> Vladimir,
>
> Pyobjc does support blocks and you should pass a function wherever the
> obc side expects a block.
>
> Sadly enough blocks are not introspectable at runtime in the objc (or
> blocks) runtime which means we have to provide additional custom
> metadata. You seem to have found a method where we haven't done that
> yet and I'll fix that for the next release.

Guido's timemachine rules again... It turns out this was already fixed  
in the repository.

Ronald

>
> Ronald
>
>
>
> On 12 okt 2009, at 09:08, Vladimir Pouzanov <far...@gm...>  
> wrote:
>
>> Hi all,
>>
>> Does PyObjC support selectors with block arguments? I'm trying to  
>> make
>> use of NSOpenPanel's beginSheetModalForWindow_completionHandler_, but
>> I'm somewhat unsure what to pass as the second argument. I've tried
>> creating a callback function like this:
>>
>> def doneImport_(res):
>>   print "panel","returned",res
>>
>> But I'm getting <type 'exceptions.TypeError'>: Argument 3 is a block,
>> but no signature available
>>
>> Wrapping the function with @objc.signature('vI') doesn't help
>> either. Any hints?
>>
>> -- 
>> Sincerely,
>> Vladimir "Farcaller" Pouzanov
>> http://farcaller.net/
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] __getitem__objectForKey_ shadows __getitem__

[Ronald O. <ron...@ma...>]

On 9 Oct, 2009, at 14:46, James R Eagan wrote:

>
>
>
> From what I can tell, the relevant code is in pyobc-core/Lib/objc/ 
> _convenience.py:88 :
>
>        if sel in CONVENIENCE_METHODS:
>            v = CONVENIENCE_METHODS[sel]
>            for nm, value in v:
>                if nm in type_dict and isinstance(type_dict[nm],  
> selector):
>
>                    # Clone attributes of already existing version
>
>                    t = type_dict[nm]
>                    v = selector(value, selector=t.selector,
>                        signature=t.signature,  
> isClassMethod=t.isClassMethod)
>
>                    type_dict[nm] = v
>                else:
>                    type_dict[nm] = value
>
> This seems to be a fairly core portion of the PyObjC, and I have not  
> explored the ramifications of modifying the inner if ... else block  
> to only add the convenience methods if the nm is not already in  
> type_dict.  Should that else really be an "elif nm not in type_dict" ?

Yes. I've just commited a patch that does that.

The patch is not perfect though, if you override objectForKey: in a  
subclass that subclass will once again get the generic __getitem__  
from pyobjc.

Ronald

>
> Cheers!
> James
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Blocks support in PyObjC

[Ronald O. <ron...@ma...>]

Vladimir,

Pyobjc does support blocks and you should pass a function wherever the  
obc side expects a block.

Sadly enough blocks are not introspectable at runtime in the objc (or  
blocks) runtime which means we have to provide additional custom  
metadata. You seem to have found a method where we haven't done that  
yet and I'll fix that for the next release.

Ronald



On 12 okt 2009, at 09:08, Vladimir Pouzanov <far...@gm...> wrote:

> Hi all,
>
> Does PyObjC support selectors with block arguments? I'm trying to make
> use of NSOpenPanel's beginSheetModalForWindow_completionHandler_, but
> I'm somewhat unsure what to pass as the second argument. I've tried
> creating a callback function like this:
>
> def doneImport_(res):
>    print "panel","returned",res
>
> But I'm getting <type 'exceptions.TypeError'>: Argument 3 is a block,
> but no signature available
>
> Wrapping the function with @objc.signature('vI') doesn't help  
> either. Any hints?
>
> -- 
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Blocks support in PyObjC

[Vladimir P. <far...@gm...>]

Hi all,

Does PyObjC support selectors with block arguments? I'm trying to make
use of NSOpenPanel's beginSheetModalForWindow_completionHandler_, but
I'm somewhat unsure what to pass as the second argument. I've tried
creating a callback function like this:

def doneImport_(res):
    print "panel","returned",res

But I'm getting <type 'exceptions.TypeError'>: Argument 3 is a block,
but no signature available

Wrapping the function with @objc.signature('vI') doesn't help either. Any hints?

-- 
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/

Re: [Pyobjc-dev] Using C Datatypes

[Ronald O. <ron...@ma...>]

On 11 Oct, 2009, at 17:54, Leonardo Santagada wrote:

>
> On Oct 11, 2009, at 8:03 AM, Ronald Oussoren wrote:
>
>>
>> On 10 Oct, 2009, at 1:42, Jan-Hendrik Hanne wrote:
>>
>>> Hi Ronald,
>>>
>>> Ronald Oussoren schrieb:
>>>> - how does it not work?
>>>> - and on which os-release?
>>>
>>> I am using the Iphone, this might be the problem.
>>
>> I don't support PyObjC on iPhone and won't do so until there is a
>> way to run python code on the iPhone without breaking the SDK rules.
>>
>
> What sdk rules does it break? Aparently the no interpreter rule is
> just for the download of code to be interpreted. Theres already a ton
> of lua apps on the iphone.

Last time I checked (around the 3.0 release) the SDK did not allow  
interpreted languages other than the ones supplied by Apple.

Other than that I don't have the time to work on an official port of  
PyObjC to the iPhone, its hard enough to find enough time to seriously  
work on PyObjC for OSX.

Ronald

Re: [Pyobjc-dev] Using C Datatypes

[Leonardo S. <san...@gm...>]

On Oct 11, 2009, at 8:03 AM, Ronald Oussoren wrote:

>
> On 10 Oct, 2009, at 1:42, Jan-Hendrik Hanne wrote:
>
>> Hi Ronald,
>>
>> Ronald Oussoren schrieb:
>>> - how does it not work?
>>> - and on which os-release?
>>
>> I am using the Iphone, this might be the problem.
>
> I don't support PyObjC on iPhone and won't do so until there is a  
> way to run python code on the iPhone without breaking the SDK rules.
>

What sdk rules does it break? Aparently the no interpreter rule is  
just for the download of code to be interpreted. Theres already a ton  
of lua apps on the iphone.

--
Leonardo Santagada
santagada at gmail.com

Re: [Pyobjc-dev] Using C Datatypes

[Ronald O. <ron...@ma...>]

On 10 Oct, 2009, at 1:42, Jan-Hendrik Hanne wrote:

> Hi Ronald,
>
> Ronald Oussoren schrieb:
>> - how does it not work?
>> - and on which os-release?
>
> I am using the Iphone, this might be the problem.

I don't support PyObjC on iPhone and won't do so until there is a way  
to run python code on the iPhone without breaking the SDK rules.

>
> This is my code:
>
> self.stream=NSOutputStream.alloc().initToFileAtPath_append_ 
> (self.pathToFile,YES)
> self.stream.open()
>
> Works great so far. Empty file is created.
>
> stream.write_maxLength_("test",4)
> App crashes here
>

This works fine with the current trunk on OSX 10.6:

 >>> from Foundation import NSOutputStream
 >>> s = NSOutputStream.alloc().initToFileAtPath_append_('/tmp/ 
log.txt', False)
 >>> s.open()
 >>> s.write_maxLength_('test', 4)
4
 >>> s.close()

The file then contains the bytes I wrote to it.

>> - which version of pyobjc are you using?
>
> 1946-3

I have no idea what this version number means, this might be some  
internal version code for the iPhone port.

Please ask the developer of the iPhone port to investigate, this seems  
to be a problem in that port.

Ronald

>
> Jan
>
>> Ronald
>> On 9 okt 2009, at 20:04, Jan-Hendrik Hanne <j-h...@tu...>  
>> wrote:
>>> Hi!
>>>
>>> Ronald Oussoren wrote:
>>>> On Friday, October 09, 2009, at 04:53PM, "Jan-Hendrik Hanne" <j-h...@tu... 
>>>> > wrote:
>>>>> Hi!
>>>>>
>>>>> Maybe this question was answered before, but I couldn't find it  
>>>>> in the archive.
>>>>> How can I use C data types in Python?
>>>>> Concrete: I want to use
>>>>> - (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger) 
>>>>> length
>>>>> of the NSOutputStream class.
>>>>> How can I create the buffer?
>>>> The buffer should be a python string, or another type that  
>>>> implements the buffer protocol (an array.array of bytes should  
>>>> therefore also work).
>>>> That is:
>>>>     aStream.write_maxLength_("hello world", 10)
>>>
>>> Thank you for your fast answer. Unfortunately, it doesn't work  
>>> with a string. I decided to write the file in the python way.  
>>> Hopefully it is fast enough.
>>>
>>> Jan
>>>
>>>> Ronald
>>>>> Thanks
>>>>> Jan
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Come build with us! The BlackBerry(R) Developer Conference in  
>>>>> SF, CA
>>>>> is the only developer event you need to attend this year.  
>>>>> Jumpstart your
>>>>> developing skills, take BlackBerry mobile applications to market  
>>>>> and stay ahead of the curve. Join us from November 9 - 12, 2009.  
>>>>> Register now!
>>>>> http://p.sf.net/sfu/devconference
>>>>> _______________________________________________
>>>>> Pyobjc-dev mailing list
>>>>> Pyo...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>>>
>>>>>
>>>
>
> -- 
> Jan-Hendrik Hanne
> Mittelweg 94
> 38106 Braunschweig
> Tel: 0531/2889855

Re: [Pyobjc-dev] Using C Datatypes

[Jan-Hendrik H. <j-h...@tu...>]

Hi Ronald,

Ronald Oussoren schrieb:
> - how does it not work?
> - and on which os-release?

I am using the Iphone, this might be the problem.

This is my code:

self.stream=NSOutputStream.alloc().initToFileAtPath_append_(self.pathToFile,YES)
self.stream.open()

Works great so far. Empty file is created.

stream.write_maxLength_("test",4)
App crashes here

> - which version of pyobjc are you using?

1946-3

Jan

> Ronald
> 
> 
> 
> On 9 okt 2009, at 20:04, Jan-Hendrik Hanne <j-h...@tu...> wrote:
> 
>> Hi!
>>
>> Ronald Oussoren wrote:
>>> On Friday, October 09, 2009, at 04:53PM, "Jan-Hendrik Hanne" 
>>> <j-h...@tu...> wrote:
>>>> Hi!
>>>>
>>>> Maybe this question was answered before, but I couldn't find it in 
>>>> the archive.
>>>> How can I use C data types in Python?
>>>> Concrete: I want to use
>>>> - (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger)length
>>>> of the NSOutputStream class.
>>>> How can I create the buffer?
>>> The buffer should be a python string, or another type that implements 
>>> the buffer protocol (an array.array of bytes should therefore also 
>>> work).
>>> That is:
>>>      aStream.write_maxLength_("hello world", 10)
>>
>> Thank you for your fast answer. Unfortunately, it doesn't work with a 
>> string. I decided to write the file in the python way. Hopefully it is 
>> fast enough.
>>
>> Jan
>>
>>> Ronald
>>>> Thanks
>>>> Jan
>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart 
>>>> your
>>>> developing skills, take BlackBerry mobile applications to market and 
>>>> stay ahead of the curve. Join us from November 9 - 12, 2009. 
>>>> Register now!
>>>> http://p.sf.net/sfu/devconference
>>>> _______________________________________________
>>>> Pyobjc-dev mailing list
>>>> Pyo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>>
>>>>
>>
> 

-- 
Jan-Hendrik Hanne
Mittelweg 94
38106 Braunschweig
Tel: 0531/2889855

Re: [Pyobjc-dev] Using C Datatypes

[Ronald O. <ron...@ma...>]

Jan,

- how does it not work?

- which version of pyobjc are you using?

- and on which os-release?

Ronald



On 9 okt 2009, at 20:04, Jan-Hendrik Hanne <j-h...@tu...> wrote:

> Hi!
>
> Ronald Oussoren wrote:
>> On Friday, October 09, 2009, at 04:53PM, "Jan-Hendrik Hanne" <j-h...@tu... 
>> > wrote:
>>> Hi!
>>>
>>> Maybe this question was answered before, but I couldn't find it in  
>>> the archive.
>>> How can I use C data types in Python?
>>> Concrete: I want to use
>>> - (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger) 
>>> length
>>> of the NSOutputStream class.
>>> How can I create the buffer?
>> The buffer should be a python string, or another type that  
>> implements the buffer protocol (an array.array of bytes should  
>> therefore also work).
>> That is:
>>      aStream.write_maxLength_("hello world", 10)
>
> Thank you for your fast answer. Unfortunately, it doesn't work with  
> a string. I decided to write the file in the python way. Hopefully  
> it is fast enough.
>
> Jan
>
>> Ronald
>>> Thanks
>>> Jan
>>>
>>> --- 
>>> --- 
>>> --- 
>>> --- 
>>> ------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year.  
>>> Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market  
>>> and stay ahead of the curve. Join us from November 9 - 12, 2009.  
>>> Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>
>>>
>

Re: [Pyobjc-dev] Using C Datatypes

[Jan-Hendrik H. <j-h...@tu...>]

Hi!

Ronald Oussoren wrote:
>  
> On Friday, October 09, 2009, at 04:53PM, "Jan-Hendrik Hanne" <j-h...@tu...> wrote:
>> Hi!
>>
>> Maybe this question was answered before, but I couldn't find it in the 
>> archive.
>> How can I use C data types in Python?
>> Concrete: I want to use
>> - (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger)length
>> of the NSOutputStream class.
>> How can I create the buffer?
> 
> The buffer should be a python string, or another type that implements the buffer protocol (an array.array of bytes should therefore also work).
> 
> That is:
>    
>    aStream.write_maxLength_("hello world", 10)

Thank you for your fast answer. Unfortunately, it doesn't work with a 
string. I decided to write the file in the python way. Hopefully it is 
fast enough.

Jan

> 
> Ronald
>> Thanks
>> Jan
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay 
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
> 

Re: [Pyobjc-dev] Using C Datatypes

[Ronald O. <ron...@ma...>]

 
On Friday, October 09, 2009, at 04:53PM, "Jan-Hendrik Hanne" <j-h...@tu...> wrote:
>Hi!
>
>Maybe this question was answered before, but I couldn't find it in the 
>archive.
>How can I use C data types in Python?
>Concrete: I want to use
>- (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger)length
>of the NSOutputStream class.
>How can I create the buffer?

The buffer should be a python string, or another type that implements the buffer protocol (an array.array of bytes should therefore also work).

That is:
   
   aStream.write_maxLength_("hello world", 10)

Ronald
>
>Thanks
>Jan
>
>------------------------------------------------------------------------------
>Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>is the only developer event you need to attend this year. Jumpstart your
>developing skills, take BlackBerry mobile applications to market and stay 
>ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>http://p.sf.net/sfu/devconference
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

[Pyobjc-dev] Using C Datatypes

[Jan-Hendrik H. <j-h...@tu...>]

Hi!

Maybe this question was answered before, but I couldn't find it in the 
archive.
How can I use C data types in Python?
Concrete: I want to use
- (NSInteger)write:(const uint8_t *)buffer maxLength:(NSUInteger)length
of the NSOutputStream class.
How can I create the buffer?

Thanks
Jan

Re: [Pyobjc-dev] __getitem__objectForKey_ shadows __getitem__

[James R E. <Jam...@lr...>]

On 9 oct. 2009, at 16:53, Ronald Oussoren wrote:

> PyObjC currently blindly adds its own version of __getitem__ when it  
> detects that a Cocoa class implements objectForKey: or  
> objectAtIndex:.  It should be easy enough to check that the Cocoa  
> class doesn't have its own version of __getitem__ before adding the  
> generic version.

Is the method I suggested to do that appropriate, or does it look like  
it should have unforeseen consequences?

> BTW. In the longer run (that is, post 2.2 final) I will remove this  
> logic and switch to class-based logic instead. That is, rather then  
> looking for objectForKey: I'll add a list of classes that will get a  
> __getitem__ implementation.

Yikes.  In that case, I'll uncomment my own __getitem__ handlers, even  
though it's currently a dead code path.  I don't want that interface  
to suddenly break in a future PyObjC.

Cheers!
James

--
James R. Eagan
LRI — Bâtiment 490
Université de Paris-Sud XI          email: Jam...@lr...
91405 Orsay Cedex — France          web: http://www.lri.fr/~eaganj

Re: [Pyobjc-dev] __getitem__objectForKey_ shadows __getitem__

[Ronald O. <ron...@ma...>]

James,

PyObjC currently blindly adds its own version of __getitem__ when it detects that a Cocoa class implements objectForKey: or objectAtIndex:.  It should be easy enough to check that the Cocoa class doesn't have its own version of __getitem__ before adding the generic version.

BTW. In the longer run (that is, post 2.2 final) I will remove this logic and switch to class-based logic instead. That is, rather then looking for objectForKey: I'll add a list of classes that will get a __getitem__ implementation. This is slightly less generic, but allows me to optimize method dispatch. 

Ronald
 
On Friday, October 09, 2009, at 02:46PM, "James R Eagan" <Jam...@lr...> wrote:
>Hi folks,
>
>I was trying to be smart in a class that provides both a Cocoa-style  
>and Pythonic interface (i.e. implementing both objectForKey_ and  
>__getitem__ and friends).  It turns out that PyObjC already does that  
>for me (cool!), but in the process of debugging an unrelated fault in  
>my program, I noticed that the implementation in PyObjC will always  
>replace __getitem__ with __getitem__objectForKey_, meaning that it is  
>impossible to combine different lookup behaviors for the Objective-C  
>and Pythonic interfaces.  (I'm haven't yet convinced myself that this  
>is necessarily a bad thing.)  See the following example:
>
>	>>> from Foundation import *
>	>>> import objc
>	>>> class Foo(NSObject):
>	...     def objectForKey_(self, key):
>	...             return 'object for key'
>	...     def __getitem__(self, key):
>	...             return 'getitem'
>	...
>	>>> foo = Foo.alloc().init()
>	>>> foo.objectForKey_('foo')
>	'object for key'
>	>>> foo['foo']
>	'object for key'
>	>>> foo.__getitem__
>	<bound method Foo.__getitem__objectForKey_ of <Foo: 0x370e880>>
>
>
> From what I can tell, the relevant code is in pyobc-core/Lib/objc/ 
>_convenience.py:88 :
>
>         if sel in CONVENIENCE_METHODS:
>             v = CONVENIENCE_METHODS[sel]
>             for nm, value in v:
>                 if nm in type_dict and isinstance(type_dict[nm],  
>selector):
>
>                     # Clone attributes of already existing version
>
>                     t = type_dict[nm]
>                     v = selector(value, selector=t.selector,
>                         signature=t.signature,  
>isClassMethod=t.isClassMethod)
>
>                     type_dict[nm] = v
>                 else:
>                     type_dict[nm] = value
>
>This seems to be a fairly core portion of the PyObjC, and I have not  
>explored the ramifications of modifying the inner if ... else block to  
>only add the convenience methods if the nm is not already in  
>type_dict.  Should that else really be an "elif nm not in type_dict" ?
>
>Cheers!
>James
>
>
>
>------------------------------------------------------------------------------
>Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>is the only developer event you need to attend this year. Jumpstart your
>developing skills, take BlackBerry mobile applications to market and stay 
>ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>http://p.sf.net/sfu/devconference
>_______________________________________________
>Pyobjc-dev mailing list
>Pyo...@li...
>https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

[Pyobjc-dev] __getitem__objectForKey_ shadows __getitem__

[James R E. <Jam...@lr...>]

Hi folks,

I was trying to be smart in a class that provides both a Cocoa-style  
and Pythonic interface (i.e. implementing both objectForKey_ and  
__getitem__ and friends).  It turns out that PyObjC already does that  
for me (cool!), but in the process of debugging an unrelated fault in  
my program, I noticed that the implementation in PyObjC will always  
replace __getitem__ with __getitem__objectForKey_, meaning that it is  
impossible to combine different lookup behaviors for the Objective-C  
and Pythonic interfaces.  (I'm haven't yet convinced myself that this  
is necessarily a bad thing.)  See the following example:

	>>> from Foundation import *
	>>> import objc
	>>> class Foo(NSObject):
	...     def objectForKey_(self, key):
	...             return 'object for key'
	...     def __getitem__(self, key):
	...             return 'getitem'
	...
	>>> foo = Foo.alloc().init()
	>>> foo.objectForKey_('foo')
	'object for key'
	>>> foo['foo']
	'object for key'
	>>> foo.__getitem__
	<bound method Foo.__getitem__objectForKey_ of <Foo: 0x370e880>>


 From what I can tell, the relevant code is in pyobc-core/Lib/objc/ 
_convenience.py:88 :

         if sel in CONVENIENCE_METHODS:
             v = CONVENIENCE_METHODS[sel]
             for nm, value in v:
                 if nm in type_dict and isinstance(type_dict[nm],  
selector):

                     # Clone attributes of already existing version

                     t = type_dict[nm]
                     v = selector(value, selector=t.selector,
                         signature=t.signature,  
isClassMethod=t.isClassMethod)

                     type_dict[nm] = v
                 else:
                     type_dict[nm] = value

This seems to be a fairly core portion of the PyObjC, and I have not  
explored the ramifications of modifying the inner if ... else block to  
only add the convenience methods if the nm is not already in  
type_dict.  Should that else really be an "elif nm not in type_dict" ?

Cheers!
James

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Karsten W. <kar...@go...>]

Hi,


Am 30.09.2009 um 23:12 schrieb Ronald Oussoren:

> Hi,
>
> Is anyone still interested in PyObjC on OSX 10.4?
...

Yes. And unfortunately I'll have to for some time... and I gave up  
hopes for PyObjC 2.0 on Tiger a long time ago ;-)


-karsten

[Pyobjc-dev] Newbie problem with Cocoa Bindings

[Andrea M. <am...@am...>]

Hi to all!
I'm a new member of this ML and I'm even a new coder in PyObjC. I've  
quite experience with python and I've started using Xcode for a little  
project we have here at work.

I've read some documentation, expecially the great "An Epic  
Introduction to PyObjC and Cocoa" (http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/ 
) and I've put up my application fast and clean. Great! On Leopard!  
Than I've upgraded to Snow Leopard and all Cocoa Bindings stopped  
working.
More details: my application is very simple, it should show an array  
of dictionaries in a TableView. First I've put up an arrayObject  
linked to the TableView and every thing worked but it was too dirty, I  
had to "refill" the array linked to the TableView every time something  
changed in the original array. Than, reading the Epic Introduction I  
discovered the power of Cocoa Bindings. I've added an Array Controller  
to my xib file, put up all bindings and every thing went really  
smooth! That was great. Suddenly on Snow Leopard Cocoa Bindings seem  
to fail.
I've put up a little test application at http://dl.getdropbox.com/u/683371/bind.zip 
  . On Leopard it works and on Xcode console you see that the Array  
Controller is full, on Snow Leopard it remains empty.

I know it is a bit confused, but I hope someone has suggestions :)

TIA
Andrea Mistrali

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[David E. <dav...@gm...>]

On Tue, Oct 6, 2009 at 11:10 PM, Ronald Oussoren <ron...@ma...> wrote:
>
> On 7 Oct, 2009, at 3:09, David Eppstein wrote:
>
>> Just a follow-up on all this. The fix to the way I was wrongly calling
>> super.init worked and my app is happy again. Because it all works I
>> haven't yet tested the code to tell objc to be more verbose when an
>> exception hits the border, but I assume that works too
>>
>> The XCode version of the app is about 200k and the setup.py version is
>> about 16Mb, I assume because the setup.py version includes its own
>> copy of Python. I haven't yet decided which of these two build styles
>> is preferable; under 10.4 and before I would have definitely wanted
>> the one that included its own Python, because otherwise there was no
>> way of counting on it working on anyone else's computer, but is that
>> still necessary these days?
>
> The setup.py version is larger because py2app copies more stuff into the
> application bundle. Are you using Apple's python or do you have a separate
> python install?

Apple's.

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[Ronald O. <ron...@ma...>]

On 7 Oct, 2009, at 3:09, David Eppstein wrote:

> Just a follow-up on all this. The fix to the way I was wrongly calling
> super.init worked and my app is happy again. Because it all works I
> haven't yet tested the code to tell objc to be more verbose when an
> exception hits the border, but I assume that works too
>
> The XCode version of the app is about 200k and the setup.py version is
> about 16Mb, I assume because the setup.py version includes its own
> copy of Python. I haven't yet decided which of these two build styles
> is preferable; under 10.4 and before I would have definitely wanted
> the one that included its own Python, because otherwise there was no
> way of counting on it working on anyone else's computer, but is that
> still necessary these days?

The setup.py version is larger because py2app copies more stuff into the
application bundle. Are you using Apple's python or do you have a  
separate
python install?

>
> However, I still have one minor hangup that is causing the setup.py
> version not to work: my source code has a .xib file inside
> English.lproj which XCode helpfully translates to a .nib while
> packaging up the app, but setup.py doesn't seem to know to do that
> translation. If I manually move XCode's nib into the English.lproj of
> the app created by setup.py, it all works, so I'm pretty sure that's
> the only problem. Is there a way of doing the xib-to-nib conversion
> outside of xcode under the control of setup.py?

The most recent version of py2app has support for compiling .xib files.

Ronald

>
> On Tue, Oct 6, 2009 at 8:46 AM, Ronald Oussoren <ron...@ma... 
> > wrote:
>>
>> On 6 Oct, 2009, at 17:42, David Eppstein wrote:
>>
>>>
>>> """
>>> Script for building LaTeX Unicodifier
>>> D. Eppstein, October 2009
>>>
>>> Usage:
>>> python setup.py py2app
>>> """
>>>
>>> from distutils.core import setup
>>> import py2app
>>>
>>> plist = {
>>>  'CFBundleDevelopmentRegion': 'English',
>>>  'CFBundleExecutable': 'LaTeX Unicodifier',
>>>  'CFBundleIconFile': 'LaTeX Unicodifier.icns',
>>> }
>>>
>>> setup(
>>>  app = ['Latex.py', 'LaTeX_Unicodifier.py'],
>>
>> Use:
>>     app = ['main.py'],
>>>
>>>  data_files = ['English.lproj', 'LaTeX Unicodifier.icns'],
>>>  options = { 'py2app': {'plist': plist} }
>>> )
>>
>> The interface design for py2app was copied from py2exe, which is  
>> why you can
>> list several applications in the 'app' argument. Having more than one
>> application in setup.py is not implemented, and is luckily also not  
>> what you
>> need.
>>
>> Ronald
>>
>>
>>
>>

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[David E. <dav...@gm...>]

Just a follow-up on all this. The fix to the way I was wrongly calling
super.init worked and my app is happy again. Because it all works I
haven't yet tested the code to tell objc to be more verbose when an
exception hits the border, but I assume that works too

The XCode version of the app is about 200k and the setup.py version is
about 16Mb, I assume because the setup.py version includes its own
copy of Python. I haven't yet decided which of these two build styles
is preferable; under 10.4 and before I would have definitely wanted
the one that included its own Python, because otherwise there was no
way of counting on it working on anyone else's computer, but is that
still necessary these days?

However, I still have one minor hangup that is causing the setup.py
version not to work: my source code has a .xib file inside
English.lproj which XCode helpfully translates to a .nib while
packaging up the app, but setup.py doesn't seem to know to do that
translation. If I manually move XCode's nib into the English.lproj of
the app created by setup.py, it all works, so I'm pretty sure that's
the only problem. Is there a way of doing the xib-to-nib conversion
outside of xcode under the control of setup.py?

On Tue, Oct 6, 2009 at 8:46 AM, Ronald Oussoren <ron...@ma...> wrote:
>
> On 6 Oct, 2009, at 17:42, David Eppstein wrote:
>
>>
>> """
>> Script for building LaTeX Unicodifier
>> D. Eppstein, October 2009
>>
>> Usage:
>> python setup.py py2app
>> """
>>
>> from distutils.core import setup
>> import py2app
>>
>> plist = {
>>   'CFBundleDevelopmentRegion': 'English',
>>   'CFBundleExecutable': 'LaTeX Unicodifier',
>>   'CFBundleIconFile': 'LaTeX Unicodifier.icns',
>> }
>>
>> setup(
>>   app = ['Latex.py', 'LaTeX_Unicodifier.py'],
>
> Use:
>      app = ['main.py'],
>>
>>   data_files = ['English.lproj', 'LaTeX Unicodifier.icns'],
>>   options = { 'py2app': {'plist': plist} }
>> )
>
> The interface design for py2app was copied from py2exe, which is why you can
> list several applications in the 'app' argument. Having more than one
> application in setup.py is not implemented, and is luckily also not what you
> need.
>
> Ronald
>
>
>
>

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[Ronald O. <ron...@ma...>]

On 6 Oct, 2009, at 17:42, David Eppstein wrote:

>
> """
> Script for building LaTeX Unicodifier
> D. Eppstein, October 2009
>
> Usage:
> python setup.py py2app
> """
>
> from distutils.core import setup
> import py2app
>
> plist = {
>    'CFBundleDevelopmentRegion': 'English',
>    'CFBundleExecutable': 'LaTeX Unicodifier',
>    'CFBundleIconFile': 'LaTeX Unicodifier.icns',
> }
>
> setup(
>    app = ['Latex.py', 'LaTeX_Unicodifier.py'],

Use:
       app = ['main.py'],
>    data_files = ['English.lproj', 'LaTeX Unicodifier.icns'],
>    options = { 'py2app': {'plist': plist} }
> )

The interface design for py2app was copied from py2exe, which is why  
you can list several applications in the 'app' argument. Having more  
than one application in setup.py is not implemented, and is luckily  
also not what you need.

Ronald