Jython

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: jython-dev-admin@...
>> [mailto:jython-dev-admin@...] On Behalf Of brian
>> zimmer
>> Sent: Monday, January 24, 2005 1:26 PM
>> To: jython-dev@...
>> 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
>> Jython-dev@...
>> 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
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

Samuele Pedroni wrote:
>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.

BTW, there are serious problems with python's dict vs. Map, but list/List
is a lot easier.  The only weirdness I can see is the "remove" method,
which is overriden in Java to mean two entirely different things.  (Very
bad in Python; questionable style in Java).  The python list remove
corresponds to the Collections overload.

Other than that, I think PyList could implement List.

  -r

Samuele Pedroni wrote:
>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.

I just read this again.  Does this mean that getattr({}, 'values') might
be backed by some other method in PyDictionary?

This would remove any problems with PyDictionary implementing Map.

  -r

This is how I read it.  This is already possible through standard 
__getattr__ hooks so it's entirely possible to implement the Collection 
interfaces without having to resort to delegation.  I'm still in favor 
of implementing without delegation if we can.

brian

On Jan 25, 2005, at 08:00 PM, Randolph Brown wrote:

> Samuele Pedroni wrote:
>> 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.
>
> I just read this again.  Does this mean that getattr({}, 'values') 
> might
> be backed by some other method in PyDictionary?
>
> This would remove any problems with PyDictionary implementing Map.
>
>   -r
>
>
> -------------------------------------------------------
> 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
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev

For what it's worth:

<http://sourceforge.net/mailarchive/forum.php?thread_id=3D3632531&forum_i=
d
=3D5586>

This approach exposes the Map version of a python dictionary as=20
an unmodifiable attribute of the python class.  The python dictionary=20
backs the Map.  Although not as nice as having PyDictionary implement
Map, it could ease some of the compatibility issues.  I believe a=20
similar approach would apply to other Collection types as well.

-Clark

> -----Original Message-----
> From: jython-dev-admin@...
> [mailto:jython-dev-admin@...] On Behalf Of=20
> brian zimmer
> Sent: Monday, January 24, 2005 7:26 AM
> To: jython-dev@...
> Subject: [Jython-dev] better Collection integration
>=20
>=20
> Dropping JDK1.1 support means we can offer better integration=20
> with the=20
> Java Collections framework.
>=20
> I'd like to see the PySequence subclasses implement the corresponding=20
> Collection interface.  This means having a PyList instance means you=20
> have a List instance.  We'd also have to implement the Iterator and=20
> Enumeration interfaces as well.
>=20
> The other option is to continue with the delegation pattern as done=20
> with CollectionIter[2].
>=20
> I'm for the former.  Thoughts?  I'd like to get some of this design=20
> work documented so development can begin.
>=20
> thanks,
>=20
> brian
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive=20
> Reporting Tool for open source databases. Create drag-&-drop=20
> reports. Save time by over 75%! Publish reports on the web.=20
> Export to DOC, XLS, RTF, etc. Download a FREE copy at=20
http://www.intelliview.com/go/osdn_nl
_______________________________________________
Jython-dev mailing list
Jython-dev@...
https://lists.sourceforge.net/lists/listinfo/jython-dev

Updike, Clark wrote:

>For what it's worth:
>
><http://sourceforge.net/mailarchive/forum.php?thread_id=3632531&forum_id
>=5586>
>
>This approach exposes the Map version of a python dictionary as 
>an unmodifiable attribute of the python class.  The python dictionary 
>backs the Map.  Although not as nice as having PyDictionary implement
>Map, it could ease some of the compatibility issues.  I believe a 
>similar approach would apply to other Collection types as well.
>
>-Clark
>  
>
The problem I see with this approach is the Collection interface is 
still not exposed to Java.  You could implement a __tojava__ to return 
the public 'map' for the PyDictionary for Java but I'd like to avoid 
this if possible.

As Samuele pointed out, we can do this:

public class PyDictionary extends PyObject implements Map {
  public PyObject _values(); // this can be any name
  public Collection values();
}

The Jython method dispatching will call the correct method 'values' 
method and the instance can be passed to Java without any coercion 
requirements as it is a Map.  I think this is the best approach and one 
we should try to achieve.  Thoughts?

thanks,

brian