[Python-Dev] Please reject or postpone PEP 526 (original) (raw)
Ivan Levkivskyi levkivskyi at gmail.com
Sun Sep 4 13:23:30 EDT 2016
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 4 September 2016 at 18:43, Nick Coghlan <ncoghlan at gmail.com> wrote:
On 4 September 2016 at 21:32, Ivan Levkivskyi <levkivskyi at gmail.com> wrote: > The first form still could be interpreted by type checkers > as annotation for value (a cast to more precise type): > > variable = cast(annotation, value) # visually also looks similar
I think a function based spelling needs to be discussed further, as it seems to me that at least some of the goals of the PEP could be met with a suitable definition of "cast" and "declare", with no syntactic changes to Python. Specifically, consider: def cast(value, annotation): return value def declare(annotation): return object()
Nick, If I understand you correctly, this idea is very similar to Undefined. It was proposed a year and half ago, when PEP 484 was discussed.
At that time it was abandoned, it reappeared during the discussion of this PEP, but many people (including me) didn't like this, so that we decided to put it in the list of rejected ideas to this PEP.
Some downsides of this approach:
People will start to expect Undefined (or whatever is returned by declare()) everywhere (as in Javascript) even if we prohibit this.
Some runtime overhead is still present: annotation gets evaluated at every call to cast, and many annotations involve creation of class objects (especially generics) that are very costly. Because of this overhead, such use of generics was prohibited in PEP 484:
x = Nodeint # prohibited by PEP 484 x = Node() # type: Node[int] # this was allowed
- Readability will be probably even worse than with comments: many types already have brackets and parens, so that two more form cast() is not good. Plus some noise of the if 0: that you mentioned, plus "cast" everywhere.
However, exploring this possibility still seems like a good idea to
me, as it should allow many of the currently thorny semantic questions to be resolved, and a future syntax-only PEP for 3.7+ can just be about defining syntactic sugar for semantics that can (by then) already be expressed via appropriate initialisers.
I think that motivation of the PEP is exactly opposite, this is why it has "Syntax" not "Semantics" in title. Also quoting Guido:
But I'm not in a hurry for that -- I'm only hoping to get the basic syntax accepted by Python 3.6 beta 1 so that we can start using this in 5 years from now rather than 7 years from now.
I also think that semantics should be up to the type checkers. Maybe it is not a perfect comparison, but prohibiting all type semantics except one is like prohibiting all Python web frameworks except one.
-- Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160904/1641c74d/attachment.html>
- Previous message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Next message (by thread): [Python-Dev] Please reject or postpone PEP 526
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]