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

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
with
{‘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.

Likewise:

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.

--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.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/