From: Chris K. <cla...@ca...> - 2000-11-28 02:07:52
|
All, I would like to use PyLists and PyDictionaries interchangably between Java and Jython. I thought of subclassing PyDictionary and implementing the Map interface, but there's a name collision with the "values()" method (as PyDictionary returns a PyList. Friggin' Java and it's lack of return type overloading.) Needless to say, I thought of one other way, modify the PyList and PyDictionary classes so that they implement the above-mentioned interfaces. Given that they use Java classes under the hood that do support these interfaces, these methods would simply be a pass-through to the protected object's methods by the same name. Additionally, given that PyLists would (indirectly) implement the Collection interface, the values() method would make both Jython and Java happy. I can probably perform these changes and send a patch set out via e-mail...Interested? Also, one other thing of note: I've been trying to execute CGI scripts under the Servlet architecture without having to make code mods to the Python script (or at least making minimal changes.) As such, I've implemented a cgi.FieldStorage class in Java that acts like the CPython equivalent, as well as a Java class equivalent for Cookie.SimpleCookie. They're surely not fully-fleshed out and may have bugs but I would be quite happy to send the source out via e-mail or post them to an appropriate site. It might be worthwhile to include them as standard libraries once the bugs are all worked out and they're fully compatable with the CPython equivalents. |
From: <bc...@wo...> - 2000-11-28 11:13:53
|
On Mon, 27 Nov 2000 18:07:45 -0800, you wrote: >All, I would like to use PyLists and PyDictionaries interchangably between >Java and Jython. Me too. So would JimH a long time ago (item #2): http://www.python.org/pipermail/jpython-interest/1998-October/003270.html The seconds half of this item is already in place, but the first "This will both allow JPython collections to be easily used from Java" is not. >I thought of subclassing PyDictionary and implementing the >Map interface, but there's a name collision with the "values()" method (as >PyDictionary returns a PyList. Friggin' Java and it's lack of return type >overloading.) > >Needless to say, I thought of one other way, modify the PyList and >PyDictionary classes so that they implement the above-mentioned interfaces. >Given that they use Java classes under the hood that do support these >interfaces, these methods would simply be a pass-through to the protected >object's methods by the same name. > >Additionally, given that PyLists would (indirectly) implement the Collection >interface, the values() method would make both Jython and Java happy. It is not that simple, but it can be done. Python must use a different version of values() than the one java is seeing. That can be done in PyDictionary.classDictInit where the "values" entry already are exchanged with a high performence version. The real problem with this approach is java1 compatibility. It is an unmoving requirement that jython can be used in a java1 browser like IE. So all uses of java2 features must be wrapped in a separate class. See CollectionProxy2.java and Java2Accessibility.java for example on how this can be done. A possible alternative to implementing Map & Collection, could be to extend the __tojava__() behaviour of PyList and PyDictionary. For PyDictionary: public Object __tojava__(Class c) { if (java.util.Map.class.isAssignableFrom(c)) return table; return super.__tojava__(c); } but where the actual test is moved into a separate and dynamicly loaded class. Things get trickier for PyList & PyStringMap because they doesn't already have a class that implements Collection or Map. If we want to maintain the mutability of these collections, the returned object from __tojava__ must be able to modify the original collection. If we make such changes we can then pass python lists and dicts to java methods: from java.util import LinkedList, HashMap print LinkedList([1,2,3,4]) print HashMap({ 'a':1, 'b':2 }) but I'm not sure that is what most people will expect. Take a look at the utility functions from "Thinking in Patterns with Java" http://www.mindview.net/TIPatterns/ There is a method that converts a dict to a map: public static Map toMap(PythonInterpreter interp, String pyName){ PyList pa = ((PyDictionary)interp.get(pyName)).items(); Map map = new HashMap(); while(pa.__len__() != 0) { PyTuple po = (PyTuple)pa.pop(); Object first = po.__finditem__(0).__tojava__(Object.class); Object second = po.__finditem__(1).__tojava__(Object.class); map.put(first, second); } return map; } The interesting thing is the __tojava__(Object.class) on both key and values. That will unwrap the python wrapper and make the Map must more usefull in java IMO. But that will break all attempts to maintain mutability. Any modification that is done on the java Map or List does no longer show up in python dict or list. All in all, I don't think it is worth it to add direct support for java2 collections to python. I would rather see a utility module which had the necessary functions to convert python collection into java collections: import jcollection print jcollection.LinkedList([1,2,3,4]) print jcollection.HashMap({ 'a':1, 'b':2 }) This conversion should then be done recursively. >I can probably perform these changes and send a patch set out via >e-mail...Interested? > >Also, one other thing of note: I've been trying to execute CGI scripts >under the Servlet architecture without having to make code mods to the >Python script (or at least making minimal changes.) As such, I've >implemented a cgi.FieldStorage class in Java that acts like the CPython >equivalent, as well as a Java class equivalent for Cookie.SimpleCookie. Couldn't these classes also be created as python modules? >They're surely not fully-fleshed out and may have bugs but I would be quite >happy to send the source out via e-mail or post them to an appropriate site. >It might be worthwhile to include them as standard libraries once the bugs >are all worked out and they're fully compatable with the CPython >equivalents. regards, finn |
From: Chris K. <ck...@ma...> - 2000-11-28 14:50:31
|
Finn Bock: > >All, I would like to use PyLists and PyDictionaries > interchangably between > >Java and Jython. > > The real problem with this approach is java1 compatibility. It is an > unmoving requirement that jython can be used in a java1 browser like IE. > So all uses of java2 features must be wrapped in a separate class. See > CollectionProxy2.java and Java2Accessibility.java for example on how > this can be done. Gah, you're correct...My biggest problem is I'm constructing Py classes in Java and sometimes wanting to pass them to Python and sometimes wanting to pass them to other Java methods that are expecting Maps or Lists. (Actually, I wonder if the Map and Collection interfaces would compile in Java 1.1? They're fairly simplistic. I don't really need the functionality in 1.1 but I don't want to break Jython.) > >Also, one other thing of note: I've been trying to execute CGI scripts > >under the Servlet architecture without having to make code mods to the > >Python script (or at least making minimal changes.) As such, I've > >implemented a cgi.FieldStorage class in Java that acts like the CPython > >equivalent, as well as a Java class equivalent for Cookie.SimpleCookie. > > Couldn't these classes also be created as python modules? Eh, I went that route for a while and found it to be a pain in the arse, in particular, when you need to send the cookie information back to the client, you'd have to traverse through the Jython objects, calling methods along the way to properly format the cookie data. (It's not just a matter of doing "str(cookies)", since they have to be mapped into the addCookie() method.) I also ran into some weird incompatability problems with the SmartCookie classes, since JPython mis-identified an e-mail address cookie as a serialized object and tried to deserialize it. |
From: Robert W. B. <rb...@di...> - 2000-11-28 19:29:11
|
[On Tue, 28 Nov 2000, Finn Bock wrote:] > The real problem with this approach is java1 compatibility. It is an > unmoving requirement that jython can be used in a java1 browser like IE. This 'unmoving' part makes me curious. I would like to hear more of the reasoning behind it. The conditional sounds like: 1. We must support Java1 browsers, so 2. we must support Java1 compatibility. This often repeated scenario assumes there's no other way to support these browsers, and there is no other reason given for Java1 compatibility. However: 1. Java2 plug-in is intended to support such browsers, and 2. it seems there must be other reasons involved in choosing Java1 compatibility, so 3. both antecedent and consequent of the conditional seem arbitrary and flimsy to me. Does the Java2 plug-in not work well? Is there a legal implication to requiring the plug-in that bothers people? Are there essential tools other than browsers that lack 1.2 drivers/support? Are embedded or real-time-Java ventures working only with Java1? Does Java1 compatibility increase chances of eventually working with alternative JVM's? Without additional reasons, someone could propose: *"The Java2 plug-in enables Java2 for most broswers" *"Java1 compatibility is not essential for Java1 browsers because of the Java2 plug-in" *"Unless other valid reasons are proposed, using Java2 with the plug-in is reasonable." I expected more of a discussion after last years conference. See: http://www.python.org/pipermail/jpython-interest/2000-January/005222.html This is just sincere curiosity- not a proposal, and I look forward to hearing comments. -Robert |
From: <bc...@wo...> - 2000-11-29 10:37:13
|
[Finn Bock] > The real problem with this approach is java1 compatibility. It is an > unmoving requirement that jython can be used in a java1 browser like IE. [Robert W. Bill] >This 'unmoving' part makes me curious. I would like to >hear more of the reasoning behind it. This is my personal opinion, but as long the default JVM on windows is 1.1.4, I prefer to stay on that as the minimum requirement. >The conditional sounds like: > 1. We must support Java1 browsers, so > 2. we must support Java1 compatibility. > >This often repeated scenario assumes there's no other way to >support these browsers, and there is no other reason >given for Java1 compatibility. The fact that you most likely can point your browser to http://jython.sourceforge.net/applets/index.html and see a jython applet is IMHO such a valuable marketing point, that I will loath to lose it. >However: > 1. Java2 plug-in is intended to support such browsers, and > 2. it seems there must be other reasons involved in > choosing Java1 compatibility, so > 3. both antecedent and consequent of the conditional > seem arbitrary and flimsy to me. > >Does the Java2 plug-in not work well? I'm sure it works perfectly. I don't make applets myself, so I'm not familiar with the features and possible tradeoff with the java2 plug-in. >Is there a legal >implication to requiring the plug-in that bothers people? >Are there essential tools other than browsers that lack 1.2 >drivers/support? Are embedded or real-time-Java ventures >working only with Java1? Does Java1 compatibility increase >chances of eventually working with alternative JVM's? > >Without additional reasons, someone could propose: > *"The Java2 plug-in enables Java2 for most broswers" > *"Java1 compatibility is not essential for Java1 browsers > because of the Java2 plug-in" > *"Unless other valid reasons are proposed, using > Java2 with the plug-in is reasonable." > >I expected more of a discussion after last years conference. >See: >http://www.python.org/pipermail/jpython-interest/2000-January/005222.html Unfortunately, I was not attending the conference, so I don't know what the discussion turned up. Deciding that java2 is the requirement, would make certain things easier for the jython-dev'ers, but would not gain anything usefull for the users. We can still include java2 features in jython, it is just more difficult to do so. I predict that I will remain unmoved, at least until there is a java2 feature that is impossible to implement without braking java1 compatibility. I have not yet seen such a feature. PS. Please keep in mind that a java2 requirement isn't needed to improve the support for java2 collections in jython. We can still do that, but first there are some issues regarding the exact design of mutability that must be finalized. regards, finn |
From: Chris K. <ck...@ma...> - 2000-11-29 15:23:20
|
Finn Bock: > This is my personal opinion, but as long the default JVM on windows is > 1.1.4, I prefer to stay on that as the minimum requirement. Unluckily, given Microsoft's goals with .NET and C#, I suspect IE will always stick with Java 1.1. (What better way to limit Java's acceptance rate?) Needless to say, any possibility of using conditional compilation? (I use CPP in my Java project for such a thing, any preprocessor would do.) |
From: <bc...@wo...> - 2000-11-29 22:08:07
|
[Chris Knight] >Needless to say, any possibility of using conditional compilation? (I use >CPP in my Java project for such a thing, any preprocessor would do.) If the need emerge, we can look at that as a possibility. So far, the dynamic Class.forName("<java2supportclass>") have worked nicely. regards, finn |