From: Samuele P. <ped...@st...> - 2005-01-25 22:20:11
|
brian zimmer wrote: > Randy Brown brought up that there are some issues with method signatures > and functionality between Java and Python. For example: > > PyDictionary.java > PyObject values() > > Map.java > Collection values() > > Beyond the obvious conflict in method signatures, the requirements of > the two values differ. In Python, the result of values() is copy of the > contents. In Java, the result is backed by the Map. This means > building a delegation framework is probably going to be the best > approach to integration the Collections framework with the PySequence > family of classes. > notice that in the new-style classes world, PyDictionary.values is not going to be exposed directly through reflection anymore. So if breaking old code relying on calling values from Java code can live with a name change, this is not an issue. > The following code demonstrates some of the differences. > > thanks, > > brian > > ''' > import os > > u = {1:2,3:4,5:6} > print u > v = u.values() > print v > x = v.index(2) > del v[x] > print v, u > > del u[3] > print v, u > > if os.name == 'java': > from java.util import HashMap > u = HashMap() > u.put(1,2) > u.put(3,4) > u.put(5,6) > v = u.values() > print v > > v.remove(2) > print v, u > > u.remove(3) > print v, u > ''' > > And for further proof: > > $ python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > >>> o = {1:2} > >>> id(o.values()) > 419888 > >>> id(o.values()) > 418896 > >>> > > $ jython > Jython 2.2a0 on java1.4.2_05 (JIT: null) > >>> from java.util import HashMap > >>> m = HashMap() > >>> m.put(1,2) > >>> id(m.values()) > 1 > >>> id(m.values()) > 1 > >>> > > On Jan 24, 2005, at 07:21 AM, Mike Garcia (Paris) wrote: > >> I agree with Brian. The Collections API is the standard so it makes >> sense to me. It will have positive impact for integration with other >> APIs and tools as Kent pointed out. >> >> I've been tinkering around and discovered a few things. So far here is >> what I've got. >> >> PyArray (1), PyList (2), PyString (3), PyTuple (4), PyXRange (5) all >> depend on PySequence so; it seems to make sense that PySequence >> implement the Collection interface IMHO. From there it appears that >> PyList can implement List, PyDictionary can implement Map, PyTuple can >> implement List, and PyXRange I'm not sure yet. PyString is a PySequence >> but I don't have any ideas yet what to do with it either. >> >> This will probably trickle down the object hierarchy going forward for >> example, iterators of these types will be used throughout jython >> eventually in lieu of getting an array of PyObjects. >> >> Classes 1 to 5 all override the abstract protected PyObject get(int) >> method in PySequence. I renamed this method to getPyObj (which is what >> it really does) to facilitate List, Map etc. implementations b/c of the >> naming issue. The impact of the change is that PackageManager, >> ThreadState, PathPackageManager, and PyDictionary classes also have to >> call getPyObj of the PyList class. Not a big deal I don't think. >> >> Any thoughts or ideas? >> >> Mike G. >> >> >> >> -----Original Message----- >> From: jyt...@li... >> [mailto:jyt...@li...] On Behalf Of brian >> zimmer >> Sent: Monday, January 24, 2005 1:26 PM >> To: jyt...@li... >> Subject: [Jython-dev] better Collection integration >> >> Dropping JDK1.1 support means we can offer better integration with the >> Java Collections framework. >> >> I'd like to see the PySequence subclasses implement the corresponding >> Collection interface. This means having a PyList instance means you >> have a List instance. We'd also have to implement the Iterator and >> Enumeration interfaces as well. >> >> The other option is to continue with the delegation pattern as done >> with CollectionIter[2]. >> >> I'm for the former. Thoughts? I'd like to get some of this design >> work documented so development can begin. >> >> thanks, >> >> brian >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |