I am against this. First, syntax like this formal_to_actual: [[int]] = [] is IMO quite cryptic, and can quickly become unreadable in real-world code. This is of course subjective, but my opinion is quite strong here. Also, in real-world code type names are much longer that `List` or `Dict`, I see `List[FrameworkNameModelFactoryConfigRule]` every day. So relative win in terms of keystrokes will be minimal. Second, this idea targets people who are already familiar with types. For ordinary Python devs, learning types is already hard (this is just a fact, I have seen many experience Python devs making basic mistakes). Although current syntax is verbose, it is very homogeneous, just a bunch of nested `Type[OneType, OtherType]`. Instead of trying to invent a fancy syntax, we need to write a good extended tutorial about types in Python and polish unexpected/inconsistent *semantics*. Third, we have more important problems than suboptimal syntax. Some people think verbosity is a big problem of statically typed languages, but this is IMO not the case. For example, after trying Scala, and Kotlin (both claim to be less verbose than Java), I still find Java easiest to write/read. I think a big problem of statically typed languages is that one needs to "fight" the language often -- if you can't express the type of your function it will not compile. This is something people never do in Python. It means our type system should be expressive enough to easily express types in idiomatic Python code. This is far from being true currently, and this is IMO of of the reasons why people don't use types, rather than them being verbose. Finally, I also don't think the current syntax is optimal, I would rather have `Optional` -> `Opt`, `Callable` -> `Call`, plus maybe some _limited_ amount of special forms (for example only unions and tuples, because they are actually special). But this is still relatively minor and can be partially fixed by `from typing import Optional as Opt`, etc. -- Ivan On Tue, 20 Nov 2018 at 10:23, Elazar wrote:

בתאריך יום ג׳, 20 בנוב׳ 2018, 10:10, מאת Sebastian Rittau ‏< srittau@rittau.biz>:

...

<snip>

On a more general note, Python's type annotation syntax is quite verbose, often cumbersome to write and hard to read, due to the original requirement of not introducing new syntax. Working towards a more concise shorthand syntax is worthwhile, in my opinion.

Allowing

v: [int] x: (int, str) y: {str} z: {str: Any}

Could be a start.

Elazar _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/typing-sig.python.org/

On 20.11.18 14:02, Ivan Levkivskyi wrote:

Finally, I also don't think the current syntax is optimal, I would rather have `Optional` -> `Opt`, `Callable` -> `Call`, plus maybe some _limited_ amount of special forms (for example only unions and tuples, because they are actually special). But this is still relatively minor and can be partially fixed by `from typing import Optional as Opt`, etc.

I think the big wins would be unions and optional types. These are the big two that are frequently used and often nested. Another one is the callable syntax, because it is easy to make mistakes, but since we have protocol based syntax now this is less important for complicated cases. Shorthanding lists, dicts, and other fundamental container types is more problematic, especially since Iterable, Sequence, Mapping, etc. should be used more frequently in argument types.  - Sebastian

I don't really have a strong opinion on this, but I also agree with postponing the discussion, at least until "from __future__ import annotations" becomes more widespread and we have more design space to work with. Regarding the problem with type aliases: just to throw out some wild ideas, maybe we could add special syntax for type aliases to bring symmetry? Or look into adding some more general form of lazy evaluation? (I know python-ideas keeps bringing this idea up). Both ideas are probably overkill though -- the existing syntax is verbose, but not that bad IMO. On Tue, Nov 20, 2018 at 12:10 AM Sebastian Rittau wrote:

On 20.11.18 07:12, Michael Lee wrote:

...

During the typing meetup from a week or two ago, I mentioned that we (the mypy team) were planning on implementing Literal types and would have a draft of the proposed semantics ready soon. Well, here it is: https://github.com/Michael0x2a/peps/blob/literal-types/pep-9999.rst

I still think that we should eventually be able to use plain integers, True, False, and strings as shorthand for literals (in addition to the verbose Literal syntax). typing could be fixed for 3.8, strings are more difficult, but eventually a __future__ import could be introduced that disallows strings for quoting and allows it to be used as literal type.

[...snip...]

I agree this would be nice -- I also miss being able to write concise signatures a little. But due to the practical limitations discussed above, I don't think this kind of change is in scope of at least the literals PEP. -- Michael On Fri, Nov 23, 2018 at 3:37 AM Ivan Levkivskyi wrote:

On Tue, 20 Nov 2018 at 13:50, Sebastian Rittau wrote:

...

On 20.11.18 14:02, Ivan Levkivskyi wrote:

Finally, I also don't think the current syntax is optimal, I would rather have `Optional` -> `Opt`, `Callable` -> `Call`, plus maybe some _limited_ amount of special forms (for example only unions and tuples, because they are actually special). But this is still relatively minor and can be partially fixed by `from typing import Optional as Opt`, etc.

I think the big wins would be unions and optional types. These are the big two that are frequently used and often nested. Another one is the callable syntax, because it is easy to make mistakes, but since we have protocol based syntax now this is less important for complicated cases. Shorthanding lists, dicts, and other fundamental container types is more problematic, especially since Iterable, Sequence, Mapping, etc. should be used more frequently in argument types

The main problem with special syntax for unions is that annotations, type aliases, generic base classes etc. are evaluated at runtime, so for example we will need to add `type.__or__()`. I could imagine many people will be against this. Also we still don't have any evidence (not even a Twitter poll) that verbose syntax is a problem in adoption of typing in Python. I would propose to postpone this discussion, unless there is a strong evidence this is a problem.

-- Ivan

_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mm3/mailman3/lists/typing-sig.python.org/