Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Peter M. <zig...@po...>]

On Monday, November 11, 2002, at 04:43 AM, Ronald Oussoren wrote:

>
> On Saturday, Nov 9, 2002, at 15:42 Europe/Amsterdam, Peter Montagner 
> wrote:
>
>> Great! But why wouldn't NSArray be a subclass of NSObject under my 
>> scheme? ObjCObject isn't an NSObject is it? I though it was a proxy, 
>> passing method calls to an encapsulated id. I was thinking a list 
>> based NSArray wrapper would act the same: answering any sequence 
>> methods by translating them into NSArray methods and passing any non 
>> sequence methods (ie. native NSArray methods) on to the encapsulated 
>> NSArray. This way, any NSArray instances would look like sequences to 
>> pure python code but would still respond to all the Cocoa methods as 
>> per normal. Of course, I'm still pretty new to the inner workings of 
>> PyObjC so I could be completely mistaken. And I have absolutely no 
>> idea how hard that would be.
>
> Don't forget that there are two sets of classes with the same name: 
> The original Objective-C classes and the Python proxy classes. 
> Currently the latter have the same inheritence graph as the former, 
> with the addition of a single root: objc.objc_object. It would be 
> possible to make the Python class NSArray a subclass of list, but then 
> it can no longer be a subclass of objc.objc_object (imcompatible base 
> classes).

OK, I had a feeling it was impossible. It seemed too obvious. Thanks 
for the lesson.


> I just remembered that this wouldn't solve the list slicing problem on 
> Python 2.2, because the list slicing code directly accesses the PyList 
> representation (even if a subclass of list has overridden > __getitem__).

That was what I was referring to in the question below.


>> How is either method going to solve the splice problem if the splice 
>> code is trying to access the list directly? Did I understand that 
>> correctly?
> Subclassing list doesn't help with Python 2.2. In Python 2.3 either 
> method will work (not subclassing list actually works better at the 
> moment, but that will be fixed soon). Given this situation I'd prefer 
> to not change the base-class for NSArray.

Fine. These "suggestions" of mine are really just my way of extracting 
information about pyobjc from you guys. :-)


>>
>> BTW, how long do you think it will take Apple to include Python 2.3 
>> in the default install?
> Long. Apple seems to have a long feature-freeze for the Darwin part of 
> new OSX releases and Python 2.3 has not even reached an alpha release 
> at the moment, I wouldn't be surprised if Python 2.3 isn't released 
> before the summer of 2003.

Sooo, 10.5 is it?

Peter