Message8572

Author zyasoft
Recipients santa4nt, zyasoft
Date 2014-05-23.15:55:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1400860539.88.0.793039722245.issue2153@psf.upfronthosting.co.za>
In-reply-to
Content
It's a bit strange I agree. Let's see how it works out:

1. The type of the keys and values in d, the instance of HashMap in your example, is Object, not PyObject.

2. Jython, via __tojava__, takes your item (1, 'a') and converts the PyInteger, PyString to an java.lang.Integer and java.lang.String respectively. In the case of PyString, it actually just returns the underlying j.l.String used (the string field), but that's just an optimization (and one that's guaranteed to work because of string immutability). This is what is inserted into the HashMap d.

3. Later on you ask for item, eg, d[1]. Once again, the Python PyInteger is reboxed as j.l.Integer; it's looked up in the map d; it get backs a j.l.String. In order to work with this in Python, the j.l.String is reboxed (via Py.java2py), but not as a PyString, but as PyUnicode. This is because j.l.String actually corresponds to a Python unicode string.

You can also observe that the effect of reboxing in how object identity is lost:

>>> d = {}
>>> a = 'a'
>>> d[1] = a
>>> d[1] is a
True
>>> from java.util import HashMap
>>> d = HashMap(d)
>>> d[1]
u'a'
>>> d[1] is a
False

Jython 3.x would make most of this strangeness go away, per my message here: http://bugs.jython.org/msg8473
History
Date User Action Args
2014-05-23 15:55:39zyasoftsetmessageid: <1400860539.88.0.793039722245.issue2153@psf.upfronthosting.co.za>
2014-05-23 15:55:39zyasoftsetrecipients: + zyasoft, santa4nt
2014-05-23 15:55:39zyasoftlinkissue2153 messages
2014-05-23 15:55:38zyasoftcreate