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:
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.Mappingand `types.MappingProxyType` still be spelled as `Mapping[str, int]` and `MappingProxyType[str, int]`? If so, that would be a slightly annoying inconsistency.

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.


On 14 Oct 2021, at 09:25, Steven D'Aprano <steve@pearwood.info> wrote:

On Thu, Oct 14, 2021 at 12:32:57AM +0400, Abdulla Al Kathiri wrote:

Today I found myself write a function that returns a tuple of list of
list of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it
easier to read to write it like the following:
([[str]], [[str]])?

Not really. Your first example is explicit and I can get the meaning by
just reading it out loud:

   tuple[list[list[str]], list[list[str]]]

   "tuple (of) list (of) list (of) str, list (of) list (of) str

Your abbreviated version:

   ([[str]], [[str]])

is too terse. I have to stop and think about what it means, not just
read it out loud. Without the hint of named types (tuple and list), my
first reaction to seeing [str] is "is this an optional string?".

And then I wonder why it's not written:

   ([[""]], [[""]])

Why abbreviate list and tuple but not string?

Code is read more than it is written, and can be too terse as well as
too verbose.

On the other hand:

Similarly for TypedDict, replace the following..
class Movie(TypedDict):
   name: str
   year: int
{‘name’: str, ‘year’: int}

To my eye, that one does work. As far as I know, curly brackets {}
aren't otherwise used in annotations (unlike square brackets), and they
don't look like "optional" to me. They look like a dict.

So on first glance at least, I think that:

   {'name': str, 'year': int}

is better than the class syntax we already have.


dict[str, int] will be {str: int}
set[int] will be {int}.

work for me too.

Also, Annotated[float, “seconds”] can be replaced with something like
float #seconds indicating whatever comes after the hashtag is just
extra information similar to a normal comment in the code.

No, because the # indicates that the rest of the line is a comment. This
is already legal:

   def func(d: {str  # this is an actual comment
                : int}) -> Any: ...

so this would be ambiguous between a real comment and an annotation.

Even if we agreed to change the behaviour of comments, you suggested:

   func(d: {str # product label: [float] # prices from 2000 to 2015})

How is the interpreter to know that the first annotation is just

   "product label"

rather than this?

   "product label: [float] # prices from 2000 to 2015"

So I don't think this works.

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T7E54DZW6EENRT373ZMCTU5WWRQ5M2TN/
Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YUPJNZVGYDANDHFD5VI54GRRNLGUAFBP/
Code of Conduct: http://python.org/psf/codeofconduct/