Re: [Pyobjc-dev] 1.3/svn: not bridging NSNumber breakage
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2005-02-11 16:05:27
|
On Friday, February 11, 2005, at 05:01PM, Bob Ippolito <bo...@re...> wrote: > >On Feb 11, 2005, at 10:53 AM, Ronald Oussoren wrote: > >> >> On Friday, February 11, 2005, at 04:24PM, Just van Rossum >> <ju...@le...> wrote: >> >>> Bob Ippolito wrote: >>> >>>> On Feb 11, 2005, at 7:58, Just van Rossum wrote: >>>> >>>>> I just upgraded from 1.2 to svn, and had my code break because >>>>> NSNumber is no longer bridged: I use >>>>> NSTableView.selectedRowEnumerator(), which, when iterating over, >>>>> now returns NSCFNumber instances. Those can't be used as index in a >>>>> Python list (TypeError: list indices must be integers). This is >>>>> fairly inconvenient as well as surprising. >>>> >>>> Not bridging NSNumber fixes several other important things, so it >>>> still has to happen. Perhaps we'll have to go through the trouble of >>>> creating three more special classes that subclass float, int, and >>>> long to make up for Python's stupidity? >> >> What stupidity? Python's behaviour is perfectly reasonable, PyObjC's >> is less so. >> >>> >>> <cue Ronald> >>> >>> Other than that, how could we fix Python's stupidity, say for Python >>> 2.5? I'm not too familiar with list indexing implementation details, >>> but >>> simply implying int(index) won't do, since that would allow "1" or 1.2 >>> to "work" as list indices. >> >> I'd prefer to revert the trunk back to 1.2's behaviour w.r.t. NSNumber >> instances. It might be prudent to create subclasses of int, float and >> long anyway if we want to make sure that roundtripping NSNumber >> objects from objc to python and back will retain object identity. > >I don't want to revert to that behavior unless these instances have all >of the NSNumber methods like pyobjc_unicode does. Why? NSNumber doesn't have useful methods. The only thing we need is an 'reinterpret_as_unsigned' method/function. Ronald |