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])
> On 14 Oct 2021, at 12:53 PM, Alex Waygood <alex.wayg...@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.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 <st...@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-le...@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/
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/YUPJNZVGYDANDHFD5VI54GRRNLGUAFBP/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/LQYVBXNP3UVMBU6WYONNR6PLU45DHWNM/
Code of Conduct: http://python.org/psf/codeofconduct/
