Re: Structure Pattern for annotation
I agree with Steven. I very much like Abdulla's proposed syntax for dicts, TypedDicts and sets. But I'm not sure that the idea for `Annotated` is workable, and the proposal for lists seems too prone to ambiguity, given how extensively square brackets are already used in typing syntax. One question about the proposals, however: how would we represent other mappings apart from dicts? Would `collections.abc.Mapping` and `types.MappingProxyType` still be spelled as `Mapping[str, int]` and `MappingProxyType[str, int]`? If so, that would be a slightly annoying inconsistency. I do also quite like the idea of an improved syntax for tuples specifically. Tuples are already very different types to lists/strings/etc in the context of typing, essentially representing heterogeneous structs of fixed length rather than homogenous sequences of unspecified length. As such, I think it "makes sense" to special-case tuples without special-casing other sequences such as list, `collections.abc.Sequence` or `collections.deque`. def foo() -> tuple[list[list[str]], list[list[str]]] would become def foo() -> (list[list[str]], list[list[str]]) That feels quite readable and natural, to me. Best, Alex
I think all of this additional syntax is just a mistake. The reason is it will encourage people to not properly annotate their input types for duck typing. Some of these shortcuts might be nice for output types. But the more general trying.Mapping, typing.Sequence and friends should be preferred for input types. If terse shortcuts are available for the concrete data structure types, but not for the generic types, a lot of people are going to feel nudged to type hint their python improperly. On Thu, Oct 14, 2021, 4:54 AM Alex Waygood <alex.waygood@gmail.com> wrote:
On Thu, 14 Oct 2021 at 13:04, Ricky Teachey <ricky@teachey.org> wrote:
I think all of this additional syntax is just a mistake.
The reason is it will encourage people to not properly annotate their input types for duck typing. Some of these shortcuts might be nice for output types. But the more general trying.Mapping, typing.Sequence and friends should be preferred for input types. If terse shortcuts are available for the concrete data structure types, but not for the generic types, a lot of people are going to feel nudged to type hint their python improperly.
+1. I'm not sure how much of my reservations about this whole discussion are ultimately reservations about typing in general, but I feel that the more we make it easier to express "exact" types, the more we encourage people to constrain their APIs to take precise types rather than to work with duck types. (I saw an example recently where even Mapping was over-specified, all that was needed was __getitem__, not even __len__ or __iter__). I know protocols allow duck typing in a static type checking context - maybe the energy focused on "making basic types easier to write" should be focused on making protocols easier to write, instead. Paul
I love the proposal for dicts, but I agree that this discourages duck typing. Could the curly braces notation represent Mapping, not dict specifically? +1 to shortening tuples but not other sequences. -- Finn Mason On Thu, Oct 14, 2021, 6:46 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, Oct 15, 2021 at 1:06 PM Finn Mason <finnjavier08@gmail.com> wrote:
That might be useful. But don't forget there is also MutableMapping. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
I don’t understand why tuple structure is not supported already. It makes reading the function signature a breeze and very natural. You can also do it without parentheses which mimics the return of multiple objects often seen in functions(def func(*args: int) -> str, [int])
El vie, 15 oct 2021 a las 14:42, Abdulla Al Kathiri (< alkathiri.abdulla@gmail.com>) escribió:
GenericClass[(A, B)] # parameterized by the type Tuple[A, B] GenericClass[A, B] # two type parameters The ASTs for both of those are the same, so it would be difficult for mypy to distinguish them. I do agree that it would be nice to write types like ([str], [int]), but there are some practical problems.
I guess you could work around this by exploiting the slicing operator: GenericClass[:(A, B)] It makes sense to use the : in the context of typing, but I can see how this syntax can be confusing. The least confusing implementation I could think of is to limit the use of GenericClass[:_] to tuples, lists, sets and dicts (and future callable type signatures?), i.e.; it should only be used for structural type pattern matching. Here is a simple demo: https://gist.github.com/jorenham/1c241a1cf33d2cc8235631b63fa8f279
I think all of this additional syntax is just a mistake. The reason is it will encourage people to not properly annotate their input types for duck typing. Some of these shortcuts might be nice for output types. But the more general trying.Mapping, typing.Sequence and friends should be preferred for input types. If terse shortcuts are available for the concrete data structure types, but not for the generic types, a lot of people are going to feel nudged to type hint their python improperly. On Thu, Oct 14, 2021, 4:54 AM Alex Waygood <alex.waygood@gmail.com> wrote:
On Thu, 14 Oct 2021 at 13:04, Ricky Teachey <ricky@teachey.org> wrote:
I think all of this additional syntax is just a mistake.
The reason is it will encourage people to not properly annotate their input types for duck typing. Some of these shortcuts might be nice for output types. But the more general trying.Mapping, typing.Sequence and friends should be preferred for input types. If terse shortcuts are available for the concrete data structure types, but not for the generic types, a lot of people are going to feel nudged to type hint their python improperly.
+1. I'm not sure how much of my reservations about this whole discussion are ultimately reservations about typing in general, but I feel that the more we make it easier to express "exact" types, the more we encourage people to constrain their APIs to take precise types rather than to work with duck types. (I saw an example recently where even Mapping was over-specified, all that was needed was __getitem__, not even __len__ or __iter__). I know protocols allow duck typing in a static type checking context - maybe the energy focused on "making basic types easier to write" should be focused on making protocols easier to write, instead. Paul
I love the proposal for dicts, but I agree that this discourages duck typing. Could the curly braces notation represent Mapping, not dict specifically? +1 to shortening tuples but not other sequences. -- Finn Mason On Thu, Oct 14, 2021, 6:46 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, Oct 15, 2021 at 1:06 PM Finn Mason <finnjavier08@gmail.com> wrote:
That might be useful. But don't forget there is also MutableMapping. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
I don’t understand why tuple structure is not supported already. It makes reading the function signature a breeze and very natural. You can also do it without parentheses which mimics the return of multiple objects often seen in functions(def func(*args: int) -> str, [int])
El vie, 15 oct 2021 a las 14:42, Abdulla Al Kathiri (< alkathiri.abdulla@gmail.com>) escribió:
GenericClass[(A, B)] # parameterized by the type Tuple[A, B] GenericClass[A, B] # two type parameters The ASTs for both of those are the same, so it would be difficult for mypy to distinguish them. I do agree that it would be nice to write types like ([str], [int]), but there are some practical problems.
I guess you could work around this by exploiting the slicing operator: GenericClass[:(A, B)] It makes sense to use the : in the context of typing, but I can see how this syntax can be confusing. The least confusing implementation I could think of is to limit the use of GenericClass[:_] to tuples, lists, sets and dicts (and future callable type signatures?), i.e.; it should only be used for structural type pattern matching. Here is a simple demo: https://gist.github.com/jorenham/1c241a1cf33d2cc8235631b63fa8f279
participants (7)
-
Abdulla Al Kathiri -
Alex Waygood -
Finn Mason -
Jelle Zijlstra -
Joren Hammudoglu -
Paul Moore -
Ricky Teachey