Hello! 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 It basically combines and elaborates on the discussion from https://github.com/python/typing/issues/478 and https://github.com/python/mypy/issues/3062, so hopefully there shouldn't be too many surprises. This is probably a little premature in that we've only just barely started the PoC work in mypy: we'll almost certainly need to tweak some things as we work through the implementation. But we're reasonably happy with the proposed semantics and thought it would be nice to just publish it now so that people can start giving feedback. (Also, I guess we wanted an excuse to try using this shiny new mailing list, lol) -- Michael
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. 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. - Sebastian
בתאריך יום ג׳, 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
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 <elazarg@gmail.com> 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/
I also find TypeScript's more lightweight syntax around unions (`x | y` vs. Union[x, y]), optionals (`x?` vs. `Optional[x]` - approximately), arrays/lists (`x[]` vs. `List[x]`) etc. more pleasant to read and write. However, in TypeScript, the types are entirely erased, while in Python, they have a runtime representation and everything is imported. I think this initial choice tilts the scale towards the more verbose, but more consistent syntax.
I would rather have `Optional` -> `Opt`, `Callable` -> `Call`
Maybe `Literal` should be `Lit`?
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
On Tue, 20 Nov 2018 at 13:50, Sebastian Rittau <srittau@rittau.biz> 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
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 <srittau@rittau.biz> 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 <levkivskyi@gmail.com> wrote:
On Tue, 20 Nov 2018 at 13:50, Sebastian Rittau <srittau@rittau.biz> 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/
On Tue, 20 Nov 2018 at 08:10, Sebastian Rittau <srittau@rittau.biz> 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).
I am against this. A single literal is a rare case, much more common case is something like Literal[1, 2, 3] or Literal["rb", "wb"]. Introducing the special shorthand for rare use cases will only introduce confusion. Also explicit is better than implicit. I would potentially only consider `True` and `False`, because: * There are know cases for overloads on them in stdlib an third party. * We already have `None` special cased: `Literal[None]` is the same as `None`. -- Ivan
Thanks for writing the draft! I left a bunch of inline comments here https://github.com/Michael0x2a/peps/pull/1. May main suggestion is to move from brainstorming-like doc to more PEP-like (more strict) document, and move all things we are not doing now to the "Rejected/postponed ideas" section. -- Ivan On Tue, 20 Nov 2018 at 06:12, Michael Lee <michael.lee.0x2a@gmail.com> wrote:
Hello!
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
It basically combines and elaborates on the discussion from https://github.com/python/typing/issues/478 and https://github.com/python/mypy/issues/3062, so hopefully there shouldn't be too many surprises.
This is probably a little premature in that we've only just barely started the PoC work in mypy: we'll almost certainly need to tweak some things as we work through the implementation.
But we're reasonably happy with the proposed semantics and thought it would be nice to just publish it now so that people can start giving feedback.
(Also, I guess we wanted an excuse to try using this shiny new mailing list, lol)
-- Michael _______________________________________________ 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/
participants (5)
-
Elazar -
Ivan Levkivskyi -
Michael Lee -
Ran Benita -
Sebastian Rittau