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 <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/T7E54DZW6EENRT373ZMCTU5WWRQ5M2TN/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/YUPJNZVGYDANDHFD5VI54GRRNLGUAFBP/
Code of Conduct: http://python.org/psf/codeofconduct/
