Decide meaning of alias with one generic and one concrete parameter

[gvanrossum]

See python/mypy#606. We allow the following, and they are well-defined:

from typing import TypeVar, Dict
T = TypeVar('T')
U = TypeVar('U')
X = Dict[int, str]
Y = Dict[T, U]

But what does this mean?

Z = Dict[T, int]

In typing.py this currently defines Z as something with two parameters, the second constrained to int or subclasses thereof. But another reasonable interpretation would be that Z has one parameter, corresponding to T only.

The second interpretation is actually more reasonable. (As long as we require that all parameters are either concrete or a simple type variable, not another type expression or alias containing a type variable.)

If we agree, we should define this in the PEP and implement it in typing.py.

[gvanrossum]

On second thoungt I don't think we need language for aliases (they just mean whatever the expression on the RHS would mean in the context where the alias is used) but I added language clarifying that defining a class that inherits from Mapping[str, T] creates a class with one parameter, T.

This is not fixed in typing.py, so keeping the "bug" label.

[JukkaL]

Here are some examples to make sure I understand the feature right. Consider these definitions:

from typing import TypeVar, Dict

T = TypeVar('T')
S = TypeVar('S')

D1 = Dict[T, S]
D2 = Dict[T, int]

Now these two signatures would be equivalent:

def f(x: Dict[T, S]) -> Tuple[T, S]: ...
def g(x: D1) -> Tuple[T, S]: ...

Also, these two would be equivalent:

def f(x: Dict[int, T]) -> T: ...
def g(x: D2) -> T: ...

These would be errors:

def err1(x: D1[int, str]) -> None: ...
def err2(x: D2[str]) -> None: ...

[gvanrossum]

Here are some examples to make sure I understand the feature right.
Consider these definitions:

from typing import TypeVar, Dict

T = TypeVar('T')
S = TypeVar('S')

D1 = Dict[T, S]
D2 = Dict[T, int]

Now these two signatures would be equivalent:

def f(x: Dict[T, S]) -> Tuple[T, S]: ...
def g(x: D1) -> Tuple[T, S]: ...

Correct.

Also, these two would be equivalent:

def f(x: Dict[int, T]) -> T: ...
def g(x: D2) -> T: ...

No, for f, T is the dict's value type, while for g, T is the dict's key type. Maybe you meant this?

def f(x: Dict[T, int]) -> T: ...
def g(x: D2) -> T: ...

Those are indeed equivalent.

These would be errors:

def err1(x: D1[int, str]) -> None: ...

Why would that be an error? It just means (to me) that x is a dict with
int keys and str values.

def err2(x: D2[str]) -> None: ...

This example is the crux of the issue. The current implementation in
types.py disallows that -- it only accepts D2 with two parameters, and the
second parameter must be int (or a subclass). But I think this is wrong,
and I think it would be nice if we had some kind of rule that the following
are equivalent (in any context, and including situations where some part is
an alias expansion):

Dict[int, str]
Dict[int][str]

If you agree, can you update the PEP and then reassign to me so I can fix
typing.py? This will probably not be done by Friday.

[ilevkivskyi]

I must say that the idea to have both:

Dict[int, str] 
Dict[int][str]

means that generics have a very intuitive semantics, this is the same as for normal functions, normal variables, and partial application. With this generics feel like real first class members of the language. It would be cool to have this.

[gvanrossum]

Unfortunately I think I misspoke. I think allowing Dict[int] is too confusing and asking for trouble (it would be like calling a function with too few parameters return a partial function -- that's fine in Haskell, but not Python). However this should work:

T = TypeVar('T')
DS = Dict[str, T]
D = DS[int]
# Now D is the same type as Dict[str, int]

And this should work too:

T = TypeVar('T')
DI = Dict[T, int]
D = DI[str]
# Again, D is the same type as Dict[str, int]

[ilevkivskyi]

I agree, if one has two parameters, one must specify which parameter to fix, first or second.
Moreover, imagine that one has MyGenClass[A, B, C], it is absolutely not clear what would M = MyGenClass[int, str] mean. However, one can write M = MyGenClass[T, int, str] or M = MyGenClass[int, T, str], etc, and then for example M[bool]. Although, it is slightly verbose, it is really unambiguous and very flexible.

[spkersten]

I'm also in favor of the latest proposal. Allowing for currying would be another concept on top of something that might already be confusing.

On 21 mei 2015, at 23:12, ilevkivskyi notifications@github.com wrote:

I agree, if one has two parameters, one must specify which parameter to fix, first or second.
Moreover, imagine that one has MyGenClass[A, B, C], it is absolutely not clear what would M = MyGenClass[int, str] mean. However, one can write M = MyGenClass[T, int, str] or M = MyGenClass[int, T, str], etc, and then for example M[bool]. Although, it is slightly verbose, it is really unambiguous and flexible.

—
Reply to this email directly or view it on GitHub.

[gvanrossum]

Jukka, if you have time for this, it would be good to write this up in the PEP (if you think we've arrived at a workable and unambiguous proposal).