PEP 613: Explicit Type Aliases
Hi everyone, I'm emailing to flag the submission of PEP 613 to formally define the motivation and syntax for explicit type alias. https://github.com/python/peps/pull/1278/files [https://avatars3.githubusercontent.com/u/6366891?s=400&v=4]<https://github.com/python/peps/pull/1278/files> PEP 613: Initial submission by shannonzhu · Pull Request #1278 · python/peps<https://github.com/python/peps/pull/1278/files> Note: Python CLA has been signed but is pending the check at https://check-python-cla.herokuapp.com/ github.com The original discussion on this topic occurred on this list last August (https://mail.python.org/archives/list/typing-sig@python.org/thread/MWRJOBEEE...), and the conclusions we reached were hashed out again in the most recent typing meetup at Facebook late last year. Thoughts and opinions on the PEP draft are appreciated! Thanks, Shannon
Hi Shannon, I like this idea (I have suffered a lot implementing some tricky heuristics for _implicit_ type aliases in mypy :-)). I will not have time for a detailed review soon, but I will be glad to sponsor this PEP. Best regards, Ivan On Wed, 22 Jan 2020 at 01:39, Shannon Zhu <szhu@fb.com> wrote:
Hi everyone,
I'm emailing to flag the submission of PEP 613 to formally define the motivation and syntax for explicit type alias. https://github.com/python/peps/pull/1278/files <https://github.com/python/peps/pull/1278/files> PEP 613: Initial submission by shannonzhu · Pull Request #1278 · python/peps <https://github.com/python/peps/pull/1278/files> Note: Python CLA has been signed but is pending the check at https://check-python-cla.herokuapp.com/ github.com The original discussion on this topic occurred on this list last August ( https://mail.python.org/archives/list/typing-sig@python.org/thread/MWRJOBEEE...), and the conclusions we reached were hashed out again in the most recent typing meetup at Facebook late last year.
Thoughts and opinions on the PEP draft are appreciated!
Thanks, Shannon _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/
On Wed, Jan 22, 2020 at 3:45 AM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
I like this idea (I have suffered a lot implementing some tricky heuristics for _implicit_ type aliases in mypy :-)). I will not have time for a detailed review soon, but I will be glad to sponsor this PEP.
Oh, in Shannon's PR I had offered to be sponsor. I'll leave the choice up to Shannon. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
So I have another idea. Not sure if this should hold up PEP 613 or be a separate one or if it's just silly. In mypy (not sure about pyre), if you write T = TypeVar('T') A = List[T] then A becomes a *parametrized* type and must itself be instantiated as A[some_type], e.g. A[int] will mean List[T]. (Plain A means List[Any], unfortunately, for historic reasons.) It's easy to forget this behavior and accidentally end up with an unintentional List[All]. Perhaps we could reinforce it by requiring A: TypeAlias[T] = List[T] and otherwise reject type vars in the RHS? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
Excited to slightly belatedly announce that PEP 613 is accepted! Thanks Guido for sponsoring + all of your help through the process. Re: the generic aliases idea -- Currently Pyre doesn't properly support generic aliases... the proposed syntax sounds reasonable. This also helps solve the issue of making ordering of generics explicit for type aliases. For example, in A = Dict[S, List[T] A: TypeAlias[S, T] = Dict[S, List[T]] The explicit ordering is also related to classes inheriting from generic classes; Pyre has plans to require such classes to also inherit from `typing.Generic` in order to specify each type variable in the intended order. Making this explicit would help avoid quietly breaking a lot of downstream code when modifying class bases, etc. ________________________________ From: Guido van Rossum <guido@python.org> Sent: Wednesday, January 29, 2020 11:16 PM To: Ivan Levkivskyi <levkivskyi@gmail.com> Cc: Shannon Zhu <szhu@fb.com>; typing-sig@python.org <typing-sig@python.org> Subject: [Typing-sig] Re: PEP 613: Explicit Type Aliases So I have another idea. Not sure if this should hold up PEP 613 or be a separate one or if it's just silly. In mypy (not sure about pyre), if you write T = TypeVar('T') A = List[T] then A becomes a *parametrized* type and must itself be instantiated as A[some_type], e.g. A[int] will mean List[T]. (Plain A means List[Any], unfortunately, for historic reasons.) It's easy to forget this behavior and accidentally end up with an unintentional List[All]. Perhaps we could reinforce it by requiring A: TypeAlias[T] = List[T] and otherwise reject type vars in the RHS? -- --Guido van Rossum (python.org/~guido<https://urldefense.proofpoint.com/v2/url?u=http-3A__python.org_-7Eguido&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=j6-YRB8UY9YIqi5vSSyJ-A&m=N358pnbEzCaAYC1jS_L_4udDTyOxk-__gjDBmbbkWfI&s=6RWJuBMSMtfhxRrMfw1xxJ8Rms9lkZXb_b3GNJ4w4jc&e=>) Pronouns: he/him (why is my pronoun here?)<https://urldefense.proofpoint.com/v2/url?u=http-3A__feministing.com_2015_02_03_how-2Dusing-2Dthey-2Das-2Da-2Dsingular-2Dpronoun-2Dcan-2Dchange-2Dthe-2Dworld_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=j6-YRB8UY9YIqi5vSSyJ-A&m=N358pnbEzCaAYC1jS_L_4udDTyOxk-__gjDBmbbkWfI&s=xLJ1aZa_ck9rAtzb4-Tjsesnn9E19_NUP_b80hKLyKo&e=>
On Tue, Feb 4, 2020 at 3:35 PM Shannon Zhu <szhu@fb.com> wrote:
Excited to slightly belatedly announce that PEP 613 is accepted! Thanks Guido for sponsoring + all of your help through the process.
Re: the generic aliases idea --
Currently Pyre doesn't properly support generic aliases... the proposed syntax sounds reasonable. This also helps solve the issue of making ordering of generics explicit for type aliases. For example, in
A = Dict[S, List[T] A: TypeAlias[S, T] = Dict[S, List[T]]
The explicit ordering is also related to classes inheriting from generic classes; Pyre has plans to require such classes to also inherit from `typing.Generic` in order to specify each type variable in the intended order. Making this explicit would help avoid quietly breaking a lot of downstream code when modifying class bases, etc.
Are you saying that this would prevent people to write K = TypeVar('K') V = TypeVar('V') class MyMapping(Mapping[K, V]): ... forcing them to use class MyMapping(Mapping[K, V], Generic[K, V]): ... instead? There's absolutely no way that the list of type variables for Mapping will ever change, so that would seem to be unnecessarily verbose. I realize it might be different if the base class were some obscure user-defined class -- perhaps you can find a way to require it for some base classes but not for others? --Guido
------------------------------ *From:* Guido van Rossum <guido@python.org> *Sent:* Wednesday, January 29, 2020 11:16 PM *To:* Ivan Levkivskyi <levkivskyi@gmail.com> *Cc:* Shannon Zhu <szhu@fb.com>; typing-sig@python.org < typing-sig@python.org> *Subject:* [Typing-sig] Re: PEP 613: Explicit Type Aliases
So I have another idea. Not sure if this should hold up PEP 613 or be a separate one or if it's just silly.
In mypy (not sure about pyre), if you write
T = TypeVar('T') A = List[T]
then A becomes a *parametrized* type and must itself be instantiated as A[some_type], e.g. A[int] will mean List[T]. (Plain A means List[Any], unfortunately, for historic reasons.)
It's easy to forget this behavior and accidentally end up with an unintentional List[All]. Perhaps we could reinforce it by requiring
A: TypeAlias[T] = List[T]
and otherwise reject type vars in the RHS?
-- --Guido van Rossum (python.org/~guido <https://urldefense.proofpoint.com/v2/url?u=http-3A__python.org_-7Eguido&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=j6-YRB8UY9YIqi5vSSyJ-A&m=N358pnbEzCaAYC1jS_L_4udDTyOxk-__gjDBmbbkWfI&s=6RWJuBMSMtfhxRrMfw1xxJ8Rms9lkZXb_b3GNJ4w4jc&e=> ) *Pronouns: he/him **(why is my pronoun here?)* <https://urldefense.proofpoint.com/v2/url?u=http-3A__feministing.com_2015_02_03_how-2Dusing-2Dthey-2Das-2Da-2Dsingular-2Dpronoun-2Dcan-2Dchange-2Dthe-2Dworld_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=j6-YRB8UY9YIqi5vSSyJ-A&m=N358pnbEzCaAYC1jS_L_4udDTyOxk-__gjDBmbbkWfI&s=xLJ1aZa_ck9rAtzb4-Tjsesnn9E19_NUP_b80hKLyKo&e=>
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
participants (3)
-
Guido van Rossum
-
Ivan Levkivskyi
-
Shannon Zhu