Thread: [Pyobjc-dev] Objc-agnostic model classes
Brought to you by:
ronaldoussoren
From: Jordan K. <jo...@kr...> - 2004-08-12 23:15:26
|
Perhaps my last mail was asking too many questions, so I'll keep this=20 one simple. I'm attempting to follow Hillegass' RaiseMan project from Cocoa=20 Programming for OS X (2nd Ed), using bindings, but in PyObjc instead. =20= The below code works just fine, with addition, editing, and deletion=20 all working fine with no errors. Person.py: """ from Foundation import * import objc class Person (NSObject): def init(self): # This works without super(), do I need it? # super(Person, self).init() self._expectedRaise =3D 5.0 self._personName =3D 'New Person' return self =09 def expectedRaise(self): return self._expectedRaise def setExpectedRaise_(self, x): self._expectedRaise =3D x setExpectedRaise_ =3D objc.accessor(setExpectedRaise_) def personName(self): return self._personName =09 def setPersonName_(self, aName): self._personName =3D aName setPersonName_ =3D objc.accessor(setPersonName_) """ However, in another project, I'm trying to have a resuable, pure-Python=20= model class that can be used verbatim in the Twisted server to which=20 this Cocoa app will communicate, with the model objects ultimately=20 residing on said server (using Twisted's cacheable PB objects, perhaps) I tried making a pure-Python (no objc references) class that was=20 created for each above Person class: class PyPerson (object): def __init__(self): self.personName =3D 'New Person' self.expectedRaise =3D 6.0 ...and instantiating it as self.pyPerson in Person.py's init(), and=20 then get/set self.pyPerson.whatever from Person.py's setters/getters,=20 like so: def setExpectedRaise_(self, x): self.pyPerson.expectedRaise =3D x.doubleValue() setExpectedRaise_ =3D objc.accessor(setExpectedRaise_) (ignoring setter/getter methods in PyPerson for now, using direct=20 attribute access) This works, but is this the recommended way of doing things? Will I=20 have to wrap all my pure-Python model objects with KVC shims like this?=20= Should I simply override setValue:forKey: and valueForKey: and access=20= the pure-Python model's methods that way? Will this bugger up=20 nil-related attribute setting =E0 la setNilValueForKey: ? Is there an auto-converter for any given objc type to a native,=20 non-objc Python type, so that I don't have to call x.doubleValue(), or=20= str(personName) every time, or should I write my own? One more obligatory question, where I don't mean to offend, and I know=20= that few people in this world are capable of fixing it, but: Any hope=20= of getting Twisted to work with PyObjC again soon?: http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue648 I'm spending a lot of time trying to figure out how to get Cocoa to=20 talk to the remote server, and may have to set up XML-RPC blocking=20 calls to the Twisted server for now, and it's a bunch of extra work,=20 and really doesn't give me the object access I'd want. Imagine having=20= expectedRaise() call to a remote XML-RPC service every time the=20 tableView calls it! Thanks in advance, J.= |
From: Bob I. <bo...@re...> - 2004-08-12 23:27:23
|
On Aug 12, 2004, at 7:15 PM, Jordan Krushen wrote: > However, in another project, I'm trying to have a resuable,=20 > pure-Python model class that can be used verbatim in the Twisted=20 > server to which this Cocoa app will communicate, with the model=20 > objects ultimately residing on said server (using Twisted's cacheable=20= > PB objects, perhaps) > > I tried making a pure-Python (no objc references) class that was=20 > created for each above Person class: > > class PyPerson (object): > def __init__(self): > self.personName =3D 'New Person' > self.expectedRaise =3D 6.0 > > ...and instantiating it as self.pyPerson in Person.py's init(), and=20 > then get/set self.pyPerson.whatever from Person.py's setters/getters,=20= > like so: > > def setExpectedRaise_(self, x): > self.pyPerson.expectedRaise =3D x.doubleValue() > setExpectedRaise_ =3D objc.accessor(setExpectedRaise_) > > (ignoring setter/getter methods in PyPerson for now, using direct=20 > attribute access) > > > This works, but is this the recommended way of doing things? Will I=20= > have to wrap all my pure-Python model objects with KVC shims like=20 > this? Should I simply override setValue:forKey: and valueForKey: and=20= > access the pure-Python model's methods that way? Will this bugger up=20= > nil-related attribute setting =E0 la setNilValueForKey: ? Having Python objects that don't inherit from NSObject cross the bridge=20= doesn't work as well as it could. Personally I think that everything=20 in PyObjC should support KVC unless explicitly told not to, especially=20= bridged pure python objects. That's more up to bill and ronald though. > Is there an auto-converter for any given objc type to a native,=20 > non-objc Python type, so that I don't have to call x.doubleValue(), or=20= > str(personName) every time, or should I write my own? There is and can't really be an "auto-converter". BTW: You should never str(personName) .. you should use unicode(...). =20= As for doubleValue(), etc. You don't know whether it's an integer,=20 double, etc. from the NSNumber so you're better off calling what you=20 want explicitly. > One more obligatory question, where I don't mean to offend, and I know=20= > that few people in this world are capable of fixing it, but: Any hope=20= > of getting Twisted to work with PyObjC again soon?: > http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue648 > > I'm spending a lot of time trying to figure out how to get Cocoa to=20 > talk to the remote server, and may have to set up XML-RPC blocking=20 > calls to the Twisted server for now, and it's a bunch of extra work,=20= > and really doesn't give me the object access I'd want. Imagine having=20= > expectedRaise() call to a remote XML-RPC service every time the=20 > tableView calls it! I'd like to fix it but I'm too busy. I'm not sure when I'll have time.=20= I don't use PyObjC+Twisted in any sort of production application right=20= now. -bob |
From: Jordan K. <jo...@kr...> - 2004-08-13 00:01:32
|
On 12-Aug-04, at 4:26 PM, Bob Ippolito wrote: > Having Python objects that don't inherit from NSObject cross the > bridge doesn't work as well as it could. Personally I think that > everything in PyObjC should support KVC unless explicitly told not to, > especially bridged pure python objects. That's more up to bill and > ronald though. Are you saying that this shouldn't be done this way at all (shim PyObjC class -> pure python class), or that in the shim's getters, I should convert the pure Python objects back into an NSSomething: def expectedRaise(self): return NSNumber.numberWithFloat_(self.pyPerson.expectedRaise) def personName(self): return NSString.stringWithString_(self.pyPerson.personName) If this shimming is what it takes, that's fine.. I'm mostly concerned with how I can reuse the same model classes in Twisted and in PyObjC. I do plan on having the model objects contain getters/setters to make the shim classes easier, but I can't see how to have a pure Python object support KVC without using objc.accessor or inheriting from NSObject. > BTW: You should never str(personName) .. you should use unicode(...). > As for doubleValue(), etc. You don't know whether it's an integer, > double, etc. from the NSNumber so you're better off calling what you > want explicitly. Thanks for the tip. > I'd like to fix it but I'm too busy. I'm not sure when I'll have > time. I don't use PyObjC+Twisted in any sort of production > application right now. Ok. I'll try to think of some other way of doing this for now. Is this really hairy stuff, or is there somewhere I should look to try to help? I know you've mentioned that you're not sure where the bug actually lies (Twisted v. PyObjC), but I'll be glad to help however I can. Haven't written C in years, but I'm pretty sure I can still mostly read it :) J. |
From: Bob I. <bo...@re...> - 2004-08-13 00:09:41
|
On Aug 12, 2004, at 8:01 PM, Jordan Krushen wrote: > On 12-Aug-04, at 4:26 PM, Bob Ippolito wrote: > >> Having Python objects that don't inherit from NSObject cross the >> bridge doesn't work as well as it could. Personally I think that >> everything in PyObjC should support KVC unless explicitly told not >> to, especially bridged pure python objects. That's more up to bill >> and ronald though. > > Are you saying that this shouldn't be done this way at all (shim > PyObjC class -> pure python class), or that in the shim's getters, I > should convert the pure Python objects back into an NSSomething: > > def expectedRaise(self): > return NSNumber.numberWithFloat_(self.pyPerson.expectedRaise) This isn't necessary, float should be bridged to NSNumber implicitly unless the selector says it should return an actual float. > def personName(self): > return NSString.stringWithString_(self.pyPerson.personName) This also isn't necessary, but you should ALWAYS USE UNICODE, or else you can have problems because NSString WILL NOT take arbitrary data. > If this shimming is what it takes, that's fine.. I'm mostly concerned > with how I can reuse the same model classes in Twisted and in PyObjC. > I do plan on having the model objects contain getters/setters to make > the shim classes easier, but I can't see how to have a pure Python > object support KVC without using objc.accessor or inheriting from > NSObject. Pure python objects could have KVC if the bridge supported it, which I am +1 on.. but I can't implement this right now and Bill or Ronald may have an objection to it. Basically I think that KVC on a pure python object should be just regular Python setting and getting. It may cause problems if the object explicitly inherits from NSObject (because you might want to do something else, or it could get in the way of a superclass' implemention) but for a non-NSObject it should be just what you want 100% of the time. >> BTW: You should never str(personName) .. you should use >> unicode(...). As for doubleValue(), etc. You don't know whether >> it's an integer, double, etc. from the NSNumber so you're better off >> calling what you want explicitly. > > Thanks for the tip. > >> I'd like to fix it but I'm too busy. I'm not sure when I'll have >> time. I don't use PyObjC+Twisted in any sort of production >> application right now. > > Ok. I'll try to think of some other way of doing this for now. Is > this really hairy stuff, or is there somewhere I should look to try to > help? I know you've mentioned that you're not sure where the bug > actually lies (Twisted v. PyObjC), but I'll be glad to help however I > can. Haven't written C in years, but I'm pretty sure I can still > mostly read it :) It's in Pyrex, and it's not very much code. It almost definitely has something to do with how using the GIL changed, but I just can't spend a few hours at it right now. -bob |
From: Jordan K. <jo...@kr...> - 2004-08-13 00:21:25
|
On 12-Aug-04, at 5:08 PM, Bob Ippolito wrote: >> def personName(self): >> return NSString.stringWithString_(self.pyPerson.personName) > > This also isn't necessary, but you should ALWAYS USE UNICODE, or else > you can have problems because NSString WILL NOT take arbitrary data. Understood. I've changed all the Python class' strings to be u'foo'. Had forgotten that part earlier. >> If this shimming is what it takes, that's fine.. I'm mostly concerned >> with how I can reuse the same model classes in Twisted and in PyObjC. >> I do plan on having the model objects contain getters/setters to >> make the shim classes easier, but I can't see how to have a pure >> Python object support KVC without using objc.accessor or inheriting >> from NSObject. > > Pure python objects could have KVC if the bridge supported it, which I > am +1 on.. but I can't implement this right now and Bill or Ronald may > have an objection to it. Basically I think that KVC on a pure python > object should be just regular Python setting and getting. It may > cause problems if the object explicitly inherits from NSObject > (because you might want to do something else, or it could get in the > way of a superclass' implemention) but for a non-NSObject it should be > just what you want 100% of the time. Agreed. That would be exactly what I'm looking for. Maybe once decorators kick in and we can define signatures more easily with them, I could just define the Python class and auto-build the PyObjc shim class from that. I imagine I'd still want the shim, as it may be acting as delegate as well? >> Ok. I'll try to think of some other way of doing this for now. Is >> this really hairy stuff, or is there somewhere I should look to try >> to help? I know you've mentioned that you're not sure where the bug >> actually lies (Twisted v. PyObjC), but I'll be glad to help however I >> can. Haven't written C in years, but I'm pretty sure I can still >> mostly read it :) > > It's in Pyrex, and it's not very much code. It almost definitely has > something to do with how using the GIL changed, but I just can't spend > a few hours at it right now. Ok. Really not my strong point then. I'll wait :) J. |
From: b.bum <bb...@ma...> - 2004-08-13 00:25:38
|
On Aug 12, 2004, at 5:08 PM, Bob Ippolito wrote: > Pure python objects could have KVC if the bridge supported it, which I > am +1 on.. but I can't implement this right now and Bill or Ronald may > have an objection to it. Basically I think that KVC on a pure python > object should be just regular Python setting and getting. It may > cause problems if the object explicitly inherits from NSObject > (because you might want to do something else, or it could get in the > way of a superclass' implemention) but for a non-NSObject it should be > just what you want 100% of the time. +1. With a caveat. I also want KVO to work. b.bum |
From: Bob I. <bo...@re...> - 2004-08-13 00:32:57
|
On Aug 12, 2004, at 8:25 PM, b.bum wrote: > On Aug 12, 2004, at 5:08 PM, Bob Ippolito wrote: >> Pure python objects could have KVC if the bridge supported it, which >> I am +1 on.. but I can't implement this right now and Bill or Ronald >> may have an objection to it. Basically I think that KVC on a pure >> python object should be just regular Python setting and getting. It >> may cause problems if the object explicitly inherits from NSObject >> (because you might want to do something else, or it could get in the >> way of a superclass' implemention) but for a non-NSObject it should >> be just what you want 100% of the time. > > +1. > > With a caveat. > > I also want KVO to work. KVO definitely can't work with arbitrary Python objects. It could work with SOME arbitrary Python objects, but only if we do the same EVIL hack as the ObjC runtime (replacing the class at runtime). -1 to attempting KVO for arbitrary Python objects. We could have a 'PyKVObject' class that makes KVC and KVO work "as you want them to" with specific Python classes, though. -bob |
From: b.bum <bb...@ma...> - 2004-08-13 00:36:19
|
On Aug 12, 2004, at 5:32 PM, Bob Ippolito wrote: > KVO definitely can't work with arbitrary Python objects. It could > work with SOME arbitrary Python objects, but only if we do the same > EVIL hack as the ObjC runtime (replacing the class at runtime). > > -1 to attempting KVO for arbitrary Python objects. > > We could have a 'PyKVObject' class that makes KVC and KVO work "as you > want them to" with specific Python classes, though. Bummer. But I understand. A convenience mix-in is often useful, in this context? b.bum |
From: Ronald O. <ron...@ma...> - 2004-08-13 06:02:54
|
On 13-aug-04, at 2:32, Bob Ippolito wrote: > > On Aug 12, 2004, at 8:25 PM, b.bum wrote: > >> On Aug 12, 2004, at 5:08 PM, Bob Ippolito wrote: >>> Pure python objects could have KVC if the bridge supported it, which >>> I am +1 on.. but I can't implement this right now and Bill or Ronald >>> may have an objection to it. Basically I think that KVC on a pure >>> python object should be just regular Python setting and getting. It >>> may cause problems if the object explicitly inherits from NSObject >>> (because you might want to do something else, or it could get in the >>> way of a superclass' implemention) but for a non-NSObject it should >>> be just what you want 100% of the time. >> >> +1. >> >> With a caveat. >> >> I also want KVO to work. > > KVO definitely can't work with arbitrary Python objects. It could > work with SOME arbitrary Python objects, but only if we do the same > EVIL hack as the ObjC runtime (replacing the class at runtime). > > -1 to attempting KVO for arbitrary Python objects. I'm +1 on attempting this, but without replacing the class pointer. It might be possible to use the python debugger to intercept interesting events. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Ronald O. <ron...@ma...> - 2004-08-13 06:09:00
|
On 13-aug-04, at 8:02, Ronald Oussoren wrote: > > On 13-aug-04, at 2:32, Bob Ippolito wrote: > >> >> KVO definitely can't work with arbitrary Python objects. It could >> work with SOME arbitrary Python objects, but only if we do the same >> EVIL hack as the ObjC runtime (replacing the class at runtime). >> >> -1 to attempting KVO for arbitrary Python objects. > > I'm +1 on attempting this, but without replacing the class pointer. It > might be possible to use the python debugger to intercept interesting > events. BTW. One way to help getting us there is to write an extensive set of unittests for KVO and KVC. There are some tests, but they are not good enough. We need tests with a {Objectictive-C, PyObjC} observer and a {Objective-C, PyObjC, pure-Python} observed object, and probably several layers of that. I would be nice if there was 1 template file that gets expanded, to make it easier to think about the completeness of the tests. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Ronald O. <ron...@ma...> - 2004-08-13 06:00:18
|
On 13-aug-04, at 2:01, Jordan Krushen wrote: > On 12-Aug-04, at 4:26 PM, Bob Ippolito wrote: > >> Having Python objects that don't inherit from NSObject cross the >> bridge doesn't work as well as it could. Personally I think that >> everything in PyObjC should support KVC unless explicitly told not >> to, especially bridged pure python objects. That's more up to bill >> and ronald though. > > Are you saying that this shouldn't be done this way at all (shim > PyObjC class -> pure python class), or that in the shim's getters, I > should convert the pure Python objects back into an NSSomething: > > def expectedRaise(self): > return NSNumber.numberWithFloat_(self.pyPerson.expectedRaise) > > def personName(self): > return NSString.stringWithString_(self.pyPerson.personName) Those are never necessary. When your strings contain non-ASCII values you have to convert them to unicode, but thats about it. > > If this shimming is what it takes, that's fine.. I'm mostly concerned > with how I can reuse the same model classes in Twisted and in PyObjC. > I do plan on having the model objects contain getters/setters to make > the shim classes easier, but I can't see how to have a pure Python > object support KVC without using objc.accessor or inheriting from > NSObject. Neither of which are pretty in a plaform-independent layer :-) Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Ronald O. <ron...@ma...> - 2004-08-13 05:57:44
|
On 13-aug-04, at 1:26, Bob Ippolito wrote: > On Aug 12, 2004, at 7:15 PM, Jordan Krushen wrote: > >> However, in another project, I'm trying to have a resuable,=20 >> pure-Python model class that can be used verbatim in the Twisted=20 >> server to which this Cocoa app will communicate, with the model=20 >> objects ultimately residing on said server (using Twisted's cacheable=20= >> PB objects, perhaps) >> >> I tried making a pure-Python (no objc references) class that was=20 >> created for each above Person class: >> >> class PyPerson (object): >> def __init__(self): >> self.personName =3D 'New Person' >> self.expectedRaise =3D 6.0 >> >> ...and instantiating it as self.pyPerson in Person.py's init(), and=20= >> then get/set self.pyPerson.whatever from Person.py's setters/getters,=20= >> like so: >> >> def setExpectedRaise_(self, x): >> self.pyPerson.expectedRaise =3D x.doubleValue() >> setExpectedRaise_ =3D objc.accessor(setExpectedRaise_) >> >> (ignoring setter/getter methods in PyPerson for now, using direct=20 >> attribute access) >> >> >> This works, but is this the recommended way of doing things? Will I=20= >> have to wrap all my pure-Python model objects with KVC shims like=20 >> this? Should I simply override setValue:forKey: and valueForKey: and=20= >> access the pure-Python model's methods that way? Will this bugger up=20= >> nil-related attribute setting =E0 la setNilValueForKey: ? > > Having Python objects that don't inherit from NSObject cross the=20 > bridge doesn't work as well as it could. Personally I think that=20 > everything in PyObjC should support KVC unless explicitly told not to,=20= > especially bridged pure python objects. That's more up to bill and=20 > ronald though. Key-Value *Coding* should work just fine, Key-Value *Observing* (aka=20 Cocoa Bindings) probably isn't. The major problem there is that there's=20= no easy way to generate the required notifications. It might be=20 possible to use the python debugger to create hooks on __getattr__ and=20= __setattr__ though. (The alternative is generating the notification=20 yourself in python code, but that isn't a very useful alternative). I am interested in adding a way to use pure python objects with Cocoa=20 Bindings, that would make it easier to have a platform-independent core=20= with a Cocoa GUI layer on top (and a GTK layer on Linux, etc.) > >> Is there an auto-converter for any given objc type to a native,=20 >> non-objc Python type, so that I don't have to call x.doubleValue(),=20= >> or str(personName) every time, or should I write my own? > > There is and can't really be an "auto-converter". > > BTW: You should never str(personName) .. you should use unicode(...).=20= > As for doubleValue(), etc. You don't know whether it's an integer,=20= > double, etc. from the NSNumber so you're better off calling what you=20= > want explicitly. Isn't NSNumber automaticly converted at the moment? You do have to call=20= x.doubleValue() (or intValue, or strValue, or ...) on text fields, but=20= automaticly converting those really isn't possible. > >> One more obligatory question, where I don't mean to offend, and I=20 >> know that few people in this world are capable of fixing it, but: =20 >> Any hope of getting Twisted to work with PyObjC again soon?: >> http://www.twistedmatrix.com/users/roundup.twistd/twisted/issue648 >> >> I'm spending a lot of time trying to figure out how to get Cocoa to=20= >> talk to the remote server, and may have to set up XML-RPC blocking=20 >> calls to the Twisted server for now, and it's a bunch of extra work,=20= >> and really doesn't give me the object access I'd want. Imagine=20 >> having expectedRaise() call to a remote XML-RPC service every time=20 >> the tableView calls it! > > I'd like to fix it but I'm too busy. I'm not sure when I'll have=20 > time. I don't use PyObjC+Twisted in any sort of production=20 > application right now. > I don't use Twisted at all. I'd like to, but the sheer size of it=20 scares me away :-) Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Jordan K. <jo...@kr...> - 2004-08-13 06:40:25
|
On 12-Aug-04, at 10:57 PM, Ronald Oussoren wrote: > Isn't NSNumber automaticly converted at the moment? You do have to > call x.doubleValue() (or intValue, or strValue, or ...) on text > fields, but automaticly converting those really isn't possible. When I do the following from a PyObjC class (Person) to a pure Python class (self.pyPerson): def setExpectedRaise_(self, x): self.pyPerson.expectedRaise = x setExpectedRaise_ = objc.accessor(setExpectedRaise_) And then, from the pure-Python class, ask for self.expectedRaise.__class__, I get this: <objective-c class NSDecimalNumber at 0xa0a061f8> This isn't something I want to send across the wire to a pure Python remote server that has no concept of PyObjC or Cocoa, is it?. That's why I'm using self.pyPerson.expectedRaise = x.doubleValue() instead. I've removed the casts from Python to ObjC, but when going ObjC -> Python, I'm trying to make sure that the pure Python code only uses stock Python types, otherwise I haven't much hope of using the same class definition on both ends of the wire, so that I can use remote object protocols like Twisted's Perspective Broker. If I can pickle the objects, I'm happy. pickle doesn't care much for objective-c classes. > I don't use Twisted at all. I'd like to, but the sheer size of it > scares me away :-) I'm actually kinda surprised that I'm the only one wanting to do this, what with the Twisted examples in the PyObjC distro. :) I'm hoping to some day end up with a pure Python model object that can be used with Bindings, that forwards KVC/KVO methods to a remote PB object (using local caching where appropriate to avoid the performance nightmare, of course). For now, I'm happy to be able to have a shim object in the middle, but it's the PB part that's hard. Using method-based RPC like XML-RPC isn't appealing, and I lose the bi-directionality of it, without constant polling. That, and it blocks the rest of the application unless I spin off threads. J. |
From: Ronald O. <ron...@ma...> - 2004-08-13 07:41:37
|
On 13-aug-04, at 8:40, Jordan Krushen wrote: > On 12-Aug-04, at 10:57 PM, Ronald Oussoren wrote: > >> Isn't NSNumber automaticly converted at the moment? You do have to >> call x.doubleValue() (or intValue, or strValue, or ...) on text >> fields, but automaticly converting those really isn't possible. > > When I do the following from a PyObjC class (Person) to a pure Python > class (self.pyPerson): > > def setExpectedRaise_(self, x): > self.pyPerson.expectedRaise = x > setExpectedRaise_ = objc.accessor(setExpectedRaise_) > > And then, from the pure-Python class, ask for > self.expectedRaise.__class__, I get this: > <objective-c class NSDecimalNumber at 0xa0a061f8> NSDecimalNumber is not converted to a python type because it has no direct python equivalent. Python 2.4 has a decimal type that is simular. > > This isn't something I want to send across the wire to a pure Python > remote server that has no concept of PyObjC or Cocoa, is it?. That's > why I'm using self.pyPerson.expectedRaise = x.doubleValue() instead. That's right. > I've removed the casts from Python to ObjC, but when going ObjC -> > Python, I'm trying to make sure that the pure Python code only uses > stock Python types, otherwise I haven't much hope of using the same > class definition on both ends of the wire, so that I can use remote > object protocols like Twisted's Perspective Broker. If I can pickle > the objects, I'm happy. pickle doesn't care much for objective-c > classes. I've broken pickle on purpose :-) > >> I don't use Twisted at all. I'd like to, but the sheer size of it >> scares me away :-) > > I'm actually kinda surprised that I'm the only one wanting to do this, > what with the Twisted examples in the PyObjC distro. :) Those are Bob's fault ;-) > > I'm hoping to some day end up with a pure Python model object that can > be used with Bindings, that forwards KVC/KVO methods to a remote PB > object (using local caching where appropriate to avoid the performance > nightmare, of course). That would be neat, but I think someone will have to write lot's of code to make that happen. My first target is to get KVC and KVO fully functional with 100% python objects. Implementing them for remote objects without blocking the application is a hard problem, and I don't know if it is possible to implement that without adding KVO support to the PB protocol. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Jordan K. <jo...@kr...> - 2004-08-13 08:00:49
|
On 13-Aug-04, at 12:41 AM, Ronald Oussoren wrote: > On 13-aug-04, at 8:40, Jordan Krushen wrote: > >> And then, from the pure-Python class, ask for >> self.expectedRaise.__class__, I get this: >> <objective-c class NSDecimalNumber at 0xa0a061f8> > > NSDecimalNumber is not converted to a python type because it has no > direct python equivalent. Python 2.4 has a decimal type that is > simular. Gotcha. I probably wouldn't have noticed this if I were using other types, so I'm glad I caught it now. >> I'm actually kinda surprised that I'm the only one wanting to do >> this, what with the Twisted examples in the PyObjC distro. :) > Those are Bob's fault ;-) Bob mentioned that some changes to the GIL's handling may have broken things. I only blame him for teasing us with it, and myself for not knowing where to begin to fix it. >> I'm hoping to some day end up with a pure Python model object that >> can be used with Bindings, that forwards KVC/KVO methods to a remote >> PB object (using local caching where appropriate to avoid the >> performance nightmare, of course). > > That would be neat, but I think someone will have to write lot's of > code to make that happen. My first target is to get KVC and KVO fully > functional with 100% python objects. Implementing them for remote > objects without blocking the application is a hard problem, and I > don't know if it is possible to implement that without adding KVO > support to the PB protocol. Well, ObjC <> Python <> KVC shim <> PB is still better than ObjC <> KVC shim <> Python <> KVC shim <> PB :) The problem with blocking is exactly what Twisted is for -- async, non-blocking requests. It sneaks itself into the Cocoa app's runtime loop instead of using its own native reactor, AFAIK. I figure that once pure Python objects can be used for KVC, I can sneak PB in the middle myself. Thanks to you guys for helping clear up this stuff for me. It's been an educational day! J. |
From: Ronald O. <ron...@ma...> - 2004-08-13 08:19:51
|
On 13-aug-04, at 10:00, Jordan Krushen wrote: > On 13-Aug-04, at 12:41 AM, Ronald Oussoren wrote: > >> On 13-aug-04, at 8:40, Jordan Krushen wrote: >> >>> And then, from the pure-Python class, ask for >>> self.expectedRaise.__class__, I get this: >>> <objective-c class NSDecimalNumber at 0xa0a061f8> >> >> NSDecimalNumber is not converted to a python type because it has no >> direct python equivalent. Python 2.4 has a decimal type that is >> simular. > > Gotcha. I probably wouldn't have noticed this if I were using other > types, so I'm glad I caught it now. > >>> I'm actually kinda surprised that I'm the only one wanting to do >>> this, what with the Twisted examples in the PyObjC distro. :) > >> Those are Bob's fault ;-) > > Bob mentioned that some changes to the GIL's handling may have broken > things. I only blame him for teasing us with it, and myself for not > knowing where to begin to fix it. > >>> I'm hoping to some day end up with a pure Python model object that >>> can be used with Bindings, that forwards KVC/KVO methods to a remote >>> PB object (using local caching where appropriate to avoid the >>> performance nightmare, of course). >> >> That would be neat, but I think someone will have to write lot's of >> code to make that happen. My first target is to get KVC and KVO fully >> functional with 100% python objects. Implementing them for remote >> objects without blocking the application is a hard problem, and I >> don't know if it is possible to implement that without adding KVO >> support to the PB protocol. > > Well, ObjC <> Python <> KVC shim <> PB is still better than ObjC <> > KVC shim <> Python <> KVC shim <> PB :) > > The problem with blocking is exactly what Twisted is for -- async, > non-blocking requests. It sneaks itself into the Cocoa app's runtime > loop instead of using its own native reactor, AFAIK. I figure that > once pure Python objects can be used for KVC, I can sneak PB in the > middle myself. The problem is that you can't do a non-blocking RPC without returning, the KVC code assumes that you will return the requested value right away. Adding a KVO work-alike to or on top of PB is probably useful in itself. KVO is basically an interface to get a callback when an attribute is updated. This would be a nice to have feature in a remote object model, because it allows you to show an up-to-date representation of remote objects even when the object is updated by another client. If you'd have a KVO work-alike in PB adding full support for Cocoa Bindings would be easy. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 |
From: Jordan K. <jo...@kr...> - 2004-08-14 02:54:41
|
On 13-Aug-04, at 1:19 AM, Ronald Oussoren wrote: > The problem is that you can't do a non-blocking RPC without returning, > the KVC code assumes that you will return the requested value right > away. Thinking out loud here.. PB would be using local proxy objects; at least for the use cases I'm thinking of, the objects would be cached locally, so immediate returns would (I think) be possible. I'm wondering if simply returning the current existing value, or accepting the new one, triggering a deferred, and letting something KVO-ish take care of the reply would do the trick. PB knows the class/type of an object before accessing it, so maybe some kind of placeholder for each type could be returned until the request comes home (in my imagined objc-agnostic, PB-aware pure-Python model object). The immediate return could be some form of status, say for a textField, or some CheckIsInTheMail constant that the caller can act upon. I take it this is what KVC interception by the bridge would be all about? > Adding a KVO work-alike to or on top of PB is probably useful in > itself. KVO is basically an interface to get a callback when an > attribute is updated. This would be a nice to have feature in a remote > object model, because it allows you to show an up-to-date > representation of remote objects even when the object is updated by > another client. If you'd have a KVO work-alike in PB adding full > support for Cocoa Bindings would be easy. This is what PB's Cacheable (sic?) objects do currently, I think. I haven't had the chance to play with them extensively yet, but I believe they register themselves as observers with their peer, and change notifications (and IIRC only object deltas) are sent from there. Bob, please correct me if I'm wrong -- I don't want to be making the wrong assumptions about Twisted's viability for what I'm hoping to accomplish with it. That, and it's Friday, and I'm starting to relax about work, so my mind is drifting :) J. |