From: brian z. <bz...@zi...> - 2001-02-27 06:23:30
|
The method Py.java2py does not support all clases and is closed to the end user. I would like to add functionality for classes such as BigDecimal to have Python wrappers, but don't want to endlessly patch the core. Has there been any effort to make this a bit more extensible? I wrote a patch for JPython (since lost when I switched jobs) that allowed me to use a properties file to map a Java class to a Python wrapper. This allowed me to wrap a Money object and to have it perform all the magic methods. I would be willingly to write the patch again since I would like some of this functionality but didn't want to work on something that perhaps someone has already started. If no one has started, are there any ideas floating around, such as adding it to the registry the way the modules are loaded by first looking at "python.modules.builtin". Finally, if we do add such functionality, should we have as the ant project does an optional jar which contains Python-wrapped Java objects, for example PySession and PyRequest, that would be outside of the core? thanks, brian |
From: <bc...@wo...> - 2001-02-27 13:03:47
|
[brian] >The method Py.java2py does not support all clases and is closed to the end >user. I would like to add functionality for classes such as BigDecimal to >have Python wrappers, but don't want to endlessly patch the core. Has there >been any effort to make this a bit more extensible? > >I wrote a patch for JPython (since lost when I switched jobs) that allowed >me to use a properties file to map a Java class to a Python wrapper. This >allowed me to wrap a Money object and to have it perform all the magic >methods. > >I would be willingly to write the patch again since I would like some of >this functionality but didn't want to work on something that perhaps someone >has already started. If no one has started, are there any ideas floating >around, such as adding it to the registry the way the modules are loaded by >first looking at "python.modules.builtin". I can't remember anyone asking for this. A feature request that resembles the java2py wrappers are ProxyCollection creations. http://mail.python.org/pipermail/jpython-dev/2000-February/000022.html http://mail.python.org/pipermail/jpython-dev/2000-March/000023.html A possible problem with most such class->handler mappings are the lack of inheritance support. F.ex subclasses of BigDecimal should, by default, be handled by the same wrapper as BigDecimal. In addition to registry support, there should also be support for adding additinal wrapper (and proxy) classes through an python API. >Finally, if we do add such functionality, should we have as the ant project >does an optional jar which contains Python-wrapped Java objects, for example >PySession and PyRequest, that would be outside of the core? Not sure. I think the additional wrappers will be outside the core by definition. I don't believe that jython should search for a optional.jar and include it if found. IMO that is better done by the author by including her optional.jar on the classpath. regards, finn |
From: brian z. <bz...@zi...> - 2001-02-27 13:34:12
|
The reason I ask is I have some code which wants to iterate an instance using __len__ and __finditem__ magic methods on any sequence. I'll accept anything with those two methods and I thought the Collection classes where wrapped as such (thus my previous question about CollectionProxy; after thinking about, it makes sense as to why Java classes come in as PyJavaInstance instances.). In the meantime I do this: protected boolean isSeq(PyObject object) { if(object instanceof PyJavaInstance) { List list = (List)object.__tojava__(List.class); if(list == Py.NoConversion) { return false; } object = new PyList((PyObject[])list.toArray(new PyObject[list.size()])); } return object.__findattr__("__finditem__") != null && object.__findattr__("__len__") != null; } I'll look into writing the Java->Python wrapper factory and the developers can do what they want with it. As for subclass support, would not Class.isAssignableFrom(Class) be sufficient for handling these cases. I'm thinking of this off the top of my head so I'll have to test it out first. thanks, brian -----Original Message----- From: jyt...@li... [mailto:jyt...@li...]On Behalf Of Finn Bock Sent: Tuesday, February 27, 2001 7:03 AM To: jyt...@li... Subject: Re: [Jython-dev] Py.java2py [brian] >The method Py.java2py does not support all clases and is closed to the end >user. I would like to add functionality for classes such as BigDecimal to >have Python wrappers, but don't want to endlessly patch the core. Has there >been any effort to make this a bit more extensible? > >I wrote a patch for JPython (since lost when I switched jobs) that allowed >me to use a properties file to map a Java class to a Python wrapper. This >allowed me to wrap a Money object and to have it perform all the magic >methods. > >I would be willingly to write the patch again since I would like some of >this functionality but didn't want to work on something that perhaps someone >has already started. If no one has started, are there any ideas floating >around, such as adding it to the registry the way the modules are loaded by >first looking at "python.modules.builtin". I can't remember anyone asking for this. A feature request that resembles the java2py wrappers are ProxyCollection creations. http://mail.python.org/pipermail/jpython-dev/2000-February/000022.html http://mail.python.org/pipermail/jpython-dev/2000-March/000023.html A possible problem with most such class->handler mappings are the lack of inheritance support. F.ex subclasses of BigDecimal should, by default, be handled by the same wrapper as BigDecimal. In addition to registry support, there should also be support for adding additinal wrapper (and proxy) classes through an python API. >Finally, if we do add such functionality, should we have as the ant project >does an optional jar which contains Python-wrapped Java objects, for example >PySession and PyRequest, that would be outside of the core? Not sure. I think the additional wrappers will be outside the core by definition. I don't believe that jython should search for a optional.jar and include it if found. IMO that is better done by the author by including her optional.jar on the classpath. regards, finn _______________________________________________ Jython-dev mailing list Jyt...@li... http://lists.sourceforge.net/lists/listinfo/jython-dev |
From: <bc...@wo...> - 2001-02-28 13:15:26
|
On Tue, 27 Feb 2001 07:30:57 -0600, you wrote: >The reason I ask is I have some code which wants to iterate an instance >using __len__ and __finditem__ magic methods on any sequence. Incidently, I hope you are aware that __len__ are allowed to lie. The only correct way to iterate over a sequence from java are: PyObject item; for (int i = 0; (item = seq.__finditem__(i)) != null; i++) ; >I'll accept >anything with those two methods and I thought the Collection classes where >wrapped as such (thus my previous question about CollectionProxy; after >thinking about, it makes sense as to why Java classes come in as >PyJavaInstance instances.). In the meantime I do this: > >protected boolean isSeq(PyObject object) { > if(object instanceof PyJavaInstance) { > List list = (List)object.__tojava__(List.class); > if(list == Py.NoConversion) { > return false; > } > object = new PyList((PyObject[])list.toArray(new PyObject[list.size()])); > } > return object.__findattr__("__finditem__") != null && >object.__findattr__("__len__") != null; >} It should probably use __findattr__("__getitem__") if you want it to succeed on python classes with a "def __getitem__(self,idx):" method. OTOH, the best way of testing an objects sequence-ness is by indexing it: protected boolean isSeq(PyObject object) { try { object.__finditem__(0); } catch (PyException exc) { return !Py.matchException(exc, Py.AttributeError); } return true; } Generally the python language is very weak in this array. Jython's addition of java object does not improve the situation at all. >I'll look into writing the Java->Python wrapper factory and the developers >can do what they want with it. > >As for subclass support, would not Class.isAssignableFrom(Class) be >sufficient for handling these cases. I'm thinking of this off the top of >my head so I'll have to test it out first. Indeed that would work. Implementation wise I can come up with two simple design. One use a hashtable where the subclass support is difficult to achive, the other use a list of two-tuples that is traversed sequentually where it is easy. I think the list is best, but only if it can be self-sorting: If a user add one wrapper for java.util.Vector and another for java.util.List, the Vector must be tested before the List in the list. I don't want the user to be concerned about this sequence. regards, finn |