Re: [Pyobjc-dev] Is the trailing _ really necessary?
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2005-07-04 05:58:16
|
On 3-jul-2005, at 22:04, Helge Hess wrote: > On 3. Jul 2005, at 21:40 Uhr, Bob Ippolito wrote: > >> Not really, we support lots of the good stuff that Python can >> bring to the table: iterators, string/array/dict methods, item >> getter syntax, automatic KVO, etc. >> > > Sure. > > >> The only thing that isn't Pythonic is when you're creating >> Objective-C objects using Objective-C methods. >> > > Which is the point of the bridge, no? > > view.setTarget_(target) > loop.performSelector_withObject_("doIt:", 15) getattr(loop, 'doit_')(15) or loop.doIt_(15) will both do something simular :-) > > Is somehow code which is _IMHO_ annoyingly UnPythonic. > > >> The only way to make that Pythonic is to write custom per-method >> "translations", which more maintenance than it's worth. >> > > Since this is only per selector, not per class+selector, the > maintenance overhead is not really significant. > > But then, as mentioned, this could probably be a separate project > on top of PyObjC. If people really want this. > > >> Apple, with all of their resources, couldn't even be bothered to >> maintain their Java bridge. >> > > This was stated several times as an argument. I don't buy it. Apple > documents API changes and adding a line to a .jobs file is a matter > of minutes. > Its just that Cocoa/Java isn't a particulary interesting project. Apple can't be bothered to do this for Java even when people *get paid* for working at Apple. All PyObjC maintainers are volunteers. > > > Yup, this discussion happened far too often ;-) Maybe we can > conclude that this will never see the light of PyObjC itself but > could be implemented on top of it if people want to go for it? This can be implemented on top of PyObjC, the mechanism that is used in objc._convenience could be used for this as well. But please note that this API is technically an unstable API (although it hasn't changed in a long time). Ronald |