Message12414

Second thoughts on this, since I find test_dict2java now fails. I think I have learned:

1. PyDictionary uses a Map internally that stores PyObjects, but offers a Java Map interface (to Java clients of the PyDictionary) through which these internal PyObjects appear as Java equivalents in put and get operations. (Clever.) In particular, a Py.None internally maps to/from a null externally.

2. In a proxy for a Java Map, the backing Map stores Java objects, and Java put and get operations should operate on the backing Map directly, while Python __setitem__ and __getitem__ involve translation from Python to Java, and Java to Python respectively. In particular, a Py.None on the Python side becomes null to the Java Map, and it's just too bad if the Map does not accept nulls.

Others before me have tried to work around this rejection of nulls by excepting Py.None from conversion on the way in. My first solution was to do that more consistently, but the result is that PyDictionary has to do it too in its Java interface, so that putAll does not receive a null in the constructor of the proxied Map type. But then an otherwise pure Java data structure ends up containing this one kind of PyObject.

I think the consistency should actually be the other way around: operations that try to store None in a proxied data structure where null is not accepted should consistently fail. I see this as another expression of the choice to let types that claim a "Java name" behave as themselves, not as the Python types they resemble.