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 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) strYour 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.orgTo unsubscribe send an email to python-ideas-leave@python.orghttps://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/