Re: [Pyobjc-dev] 1.3/svn: not bridging NSNumber breakage
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2005-02-11 15:53:42
|
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. > >Just > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Pyobjc-dev mailing list >Pyo...@li... >https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > > |