To me, these are mostly convincing examples that people need to name parts of a complex type like this :-)
I don't actually find any of the syntaxes better than any other. They are all a bit bad, but I view that as the fault of the complex nested types, not the syntax (hence my preference for naming things). It's hard to give examples of how I'd name things, because you need to know the "business logic" to name things well, and I don't for these. Frankly, if people were writing normal Python expressions like this, everyone would be telling them that Python isn't about writing one-liners and they should factor out named subexpressions. Why should type annotations be any different? Paul PS If I wanted any improvement for callables, it would be to use parentheses for the arguments rather than square brackets (which look too "heavy" in my view). So Callable[(int, str), bool] rather than Callable[[int, str], bool]. I understand why the outer brackets have to be square (abuse of indexing notation) but as far as I can see there's no reason the inner ones need to be (OK, for single arguments, Callable[(int,), bool] is a bit clumsy...) On Tue, 21 Dec 2021 at 22:10, Steven Troxler <steven.trox...@gmail.com> wrote: > > In the example I was aiming for something easy to understand that produced a > type illustrating potential problems of PEP 677, which is at its worst when > there are callables in both argument and return position. I don't have a > great real-world example of this worst-case, most of what I've seen involves > simpler and the current PEP 677 proposal isn't as bad. > > As for formatting I agree that I wouldn't hand-write the type as > ``` > ((int) -> float, (str) -> bool) -> (int, str) -> tuple[float, bool] > ``` > but a lot of code formatters might fight me on this, so I think it's worthy > of consideration, and I was trying to illustrate a readability problem and > possible fix. Formatting the code nicely so that my proposal looks good would > have meant not really engaging with the concern. > > If you're looking for examples from real code where Callable is unweildy, > Pradeep collected a few at [1] from typeshed although most of them look just > fine with the current PEP 677 proposal. A couple examples: > > Callable[[AnyStr, Callable[[AnyStr, AnyStr, AnyStr], AnyStr]], AnyStr] > Callable[[Optional[str], tuple[_Marshallable, ...]], Union[Fault, > tuple[_Marshallable, ...]]] > Callable[[str, Callable[[Iterable[str], str], str]], None] > > versus the same types written using the current PEP 677 syntax: > > (AnyStr, (AnyStr, AnyStr, AnyStr) -> AnyStr) -> AnyStr > (Optional[str], tuple[_Marshallable, ...]) -> Union[Fault, > tuple[_Marshallable, ...]] > (str, (Iterable[str], str) -> str) -> None > > versus with outer parentheses: > > (AnyStr, (AnyStr, AnyStr, AnyStr -> AnyStr) -> AnyStr) > (Optional[str], tuple[_Marshallable, ...] -> Union[Fault, > tuple[_Marshallable, ...]]) > (str, (Iterable[str], str -> str) -> None) > > and another idea, requiring both outer parentheses and argument parentheses: > > ((AnyStr, ((AnyStr, AnyStr, AnyStr )-> AnyStr)) -> AnyStr) > ((Optional[str], tuple[_Marshallable, ...]) -> Union[Fault, > tuple[_Marshallable, ...]]) > (str, (Iterable[str], str) -> str) -> None) > > To me, these are convincing examples of where Callable is hard to read and an > arrow syntax is easier, but that doesn't necessarily mean it's worth the > price of new syntax. > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/KWQVEQDZFBZDQDLOGATXSFN7KSF4WVYJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CMDXHQPLJMGCJLL2SVPFJLC3CRE5AUYU/ Code of Conduct: http://python.org/psf/codeofconduct/
