You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Interoperability of java.Util.Arraylist with typing.List (in Jython) #7
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.)
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 :)
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.
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.
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.
Activity
jimbaker commentedon Oct 16, 2014
So the specifics would be anything implementing the
java.util.Listinterface 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 :)ambv commentedon 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 commentedon Jan 7, 2015
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 commentedon Jan 8, 2015
Requires decision on what to do with the stubs.
gvanrossum commentedon Jan 8, 2015
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 commentedon Aug 5, 2016
Closing. I presume Jython can figure something out; if they need something specific they can open an issue for mypy or typeshed.