Flaw with type aliases containing type variables #2690
Comments
|
In don't think this is a flaw. The function def output2(inp: T, processor: Processor[T]) -> T:
...Then everything works as expected. Note that that it is We discussed this some time ago and everyone agreed that generic aliases should use the same rules as generic types. This is how it is now documented in PEP 484, for example: Vector = Iterable[Tuple[T, T]]
def inproduct(v: Vector[T]) -> T:
return sum(x*y for x, y in v)and also in mypy and typing docs. Note it is |
|
You're right I had forgotten this. But it's a subtle point!
…--Guido (mobile)
On Jan 13, 2017 5:12 PM, "Ivan Levkivskyi" ***@***.***> wrote:
In don't think this is a flaw. The function output2 should be annotated
as:
def output2(inp: T, processor: Processor[T]) -> T:
...
Then everything works as expected. Note that that it is Processor[T], not
Processor, because plain generic alias Processor is treated as
Processor[Any].
We discussed this some time ago and everyone agreed that generic aliases
should use the same rules as generic types. This is how it is now
documented in PEP 484, for example:
Vector = Iterable[Tuple[T, T]]
def inproduct(v: Vector[T]) -> T:
return sum(x*y for x, y in v)
and also in mypy and typing docs. Note it is Vector[T] not Vector. I
still believe this is the right way to do it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2690 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACwrMpqBJMRJ6hZOKmRqLrTtX5yDHcHyks5rSCDwgaJpZM4LjbLB>
.
|
|
I was also hit by this issue once or twice. I think it would make sense to a have a flag that disables implicit |
|
@gvanrossum @ilevkivskyi Thanks for the swift responses and explanations. The assumption came from the constrained type variable, which I guess one would assume Do you think it is possible for |
|
@mohabusama @roganov |
|
@ilevkivskyi @roganov I have created an issue |
Reported by @mohabusama on gitter -- short version:
There should be an error on the last line, but there isn't. Surrounding the line with
reveal_type()shows that the inferred value forTisList[int].If we expand the type alias
Processorinline in the signature ofoutput2()we get the expected error:This feels like a flaw in @ilevkivskyi's #2378 (which added support for type aliases containing type variables).
The text was updated successfully, but these errors were encountered: