Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interoperability of java.Util.Arraylist with typing.List (in Jython) #7

Closed
gvanrossum opened this issue Oct 15, 2014 · 6 comments
Closed

Comments

@gvanrossum
Copy link
Member

This very specific case was brought up by Jim Baker. While in general typing.List is meant to be the parametrizable version of builtins.list, I am fine with having it support the registration mechanism of ABCs and registering java.util.ArrayList to be equivalent, given that Jim says that in practice it is indeed duck-substitutable (is that even a word? :-) for the built-in list type. (I assume that this means it has a sort() method.)

@jimbaker
Copy link

So the specifics would be anything implementing the java.util.List interface should be substitutable in this fashion. (I've been saying stuff like "semantically equivalent".)

Note that this is not actually not true yet; see http://bugs.jython.org/issue2215. But it will be fixed shortly, just as we have recently done for java.util.Map. The reason why it should be is very simple: Jython goes to great lengths to present Java objects as being equivalent Python objects. We need to complete this fiction, aka proxying :)

>>> from java.util import ArrayList
>>> dir(ArrayList)
['__class__', '__contains__', '__copy__', '__deepcopy__', '__delattr__', '__delitem__', '__doc__', '__ensure_finalizer__', '__eq__', '__format__', '__getattribute__', '__getitem__', '__hash__', '__init__', '__iter__', '__len__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__str__', '__subclasshook__', '__unicode__', 'add', 'addAll', 'class', 'clear', 'clone', 'contains', 'containsAll', 'empty', 'ensureCapacity', 'equals', 'get', 'getClass', 'hashCode', 'indexOf', 'isEmpty', 'iterator', 'lastIndexOf', 'listIterator', 'notify', 'notifyAll', 'remove', 'removeAll', 'retainAll', 'set', 'size', 'subList', 'toArray', 'toString', 'trimToSize', 'wait']
>>> # but no sort method yet!

@ambv
Copy link
Contributor

ambv commented Jan 7, 2015

Danger, danger, Will Robinson.

The registration mechanism of ABCs is runtime-based and it's causing some headaches for type hinting. We can't be sure what implementations are going to be registered without importing the entire program first. Moreover, the import order matters. So I wonder what implementation @gvanrossum is suggesting here.

@gvanrossum
Copy link
Member Author

I think it's fine if this is just hacked using some Jython-specific stub. We can have a registration mechanism using (or similar to) the one defined in collections.abc to make things work at runtime, and a stub hack to teach the type checker.

@ambv
Copy link
Contributor

ambv commented Jan 8, 2015

Requires decision on what to do with the stubs.

@gvanrossum
Copy link
Member Author

Well, Jython 3.<anything> is a ways off (Jim is just about to finalize Jython 2.7.0 beta 4). I am convinced that we can provide a stub for java.Util.Arraylist that makes it an alias for or subclass of List (covariance be damned :-). Details of where that stub should live and how exactly it should be spelled needn't hold up the PEP, I think. We will do stubs, see #22.

@gvanrossum
Copy link
Member Author

Closing. I presume Jython can figure something out; if they need something specific they can open an issue for mypy or typeshed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants