Enabling / disabling optional type hinting
Consider the following example [1]: Python 3.7.0 (v3.7.0:1bf9cc5093...
= = No SyntaxError raised (which would have been the case before version 3.5?) and yet what could be a very unexpected result occurred. Of course, the problem is with the line d["answer"]: 42 which is not an assignment but is an "optional" type hint. I think it would be very useful to have a way to turn off completely type hinting and flag any use of code like the above as a SyntaxError. My preference would be if type hinting would be something that is enabled per file with a top-level comment pragma, something like # type: enable Failing that, having a to-level comment pragma like # type: disable might be acceptable as it would not require any change to any existing file. However, the other option would be more inline with type hinting being "optional" and something that should not trip beginners who are not aware of its existence. André Roberge [1] This example was inspired by a blog post I read yesterday and which I cannot find; I apologize to the author of that blog post.
On Sat, Mar 23, 2019 at 7:37 AM Andre Roberge <andre.roberge@gmail.com> wrote:
A useless statement like that isn't likely to be typed. I've never seen anyone do that. Sure, someone is going to typo and omit the = from a := assignment in 3.8 but the walrus is unlikely to be used outside of an conditional or loop test context so this seems like a made up problem. (if anything, this possibility encourages people not to use the walrus in unintended places). Someone might also typo it by meaning to use a ; for multiple statements but enter : instead. Again, very rare. Because ; is frowned upon. A linter (running live as part of an editor/ide these days) can flag most meaningless annotations quite easily. I think it would be very useful to have a way to turn off completely type
Too late. Requiring something like that would break existing code. might be acceptable as it would not require any change to any existing
What evidence is there that this frequently trips up beginners? Enhancing the dev environments beginners use to automatically lint would be better and would automate some learning, handling cases way beyond this one. -gps
On Sat, Mar 23, 2019 at 11:00 AM Stefan Krah <skrah@bytereef.org> wrote:
Unfortunately that isn't what PEP 526 said: https://www.python.org/dev/peps/pep-0526/#annotating-expressions -gps
On Sat, Mar 23, 2019 at 12:44:29PM -0700, Gregory P. Smith wrote:
Unfortunately that isn't what PEP 526 said: https://www.python.org/dev/peps/pep-0526/#annotating-expressions
Which part though? I'd understand ... (x): int # Annotates x with int, (x) treated as expression by compiler. ... to mean that the expression is also evaluated if no assignment takes place. Stefan Krah
On 3/23/19 1:37 PM, Gregory P. Smith wrote:
Walruses aren't allowed as a top-level expression anyway: Python 3.8.0a2 (default, Feb 25 2019, 17:15:37) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d["answer"] := 42 File "<stdin>", line 1 d["answer"] := 42 ^ SyntaxError: invalid syntax --Ned.
On Sat, Mar 23, 2019 at 6:26 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
My original message was referring to someone writing ":" instead of "=" by mistake -- nothing to do with the walrus assignment, but rather using the same notation to assign a value to a key as they would when defining a dict. André Roberge
On Sat, Mar 23, 2019 at 2:43 PM Andre Roberge <andre.roberge@gmail.com> wrote:
OK, I read your Original Post for this thread, about accidentally writing `d["answer"]: 42` instead of `d["answer"] = 42`. My reaction is that this was a user mistake of the same kind as accidentally writing `x + 1` instead of `x += 1`. That's just going to happen, very occasionally. (Though why? The ':' and '=' keys are not that close together.) Read your code carefully, or in an extreme case step through it in a debugger, and you'll notice the mistake. It's not a reason to pick on that particular syntax, and not much of a reason to try and introduce a mechanism to disable type hints. Sorry. PS. This particular syntax was introduced by PEP 526, and introduced in Python 3.6. -- --Guido van Rossum (python.org/~guido)
I agree with Guido. Yes, there are sequences of symbols that used to be syntax errors but that now have some meaning in Python. The type annotation colon is one of them. There are moderately many other constructs this can be said of. I can vaguely imagine accidentally using a colon rather than an equal sign because the colon is similar to an assignment in a dict display. I don't think anyone would do that as a slip of the finger, but more as a brain glitch. However, this feels like a very uncommon hazard, and just one among dozens of similar ones. I don't think anything should be "fixed" at a language level. On Sat, Mar 23, 2019, 7:21 PM Guido van Rossum <guido@python.org> wrote:
On Sat, Mar 23, 2019 at 7:37 AM Andre Roberge <andre.roberge@gmail.com> wrote:
A useless statement like that isn't likely to be typed. I've never seen anyone do that. Sure, someone is going to typo and omit the = from a := assignment in 3.8 but the walrus is unlikely to be used outside of an conditional or loop test context so this seems like a made up problem. (if anything, this possibility encourages people not to use the walrus in unintended places). Someone might also typo it by meaning to use a ; for multiple statements but enter : instead. Again, very rare. Because ; is frowned upon. A linter (running live as part of an editor/ide these days) can flag most meaningless annotations quite easily. I think it would be very useful to have a way to turn off completely type
Too late. Requiring something like that would break existing code. might be acceptable as it would not require any change to any existing
What evidence is there that this frequently trips up beginners? Enhancing the dev environments beginners use to automatically lint would be better and would automate some learning, handling cases way beyond this one. -gps
On Sat, Mar 23, 2019 at 11:00 AM Stefan Krah <skrah@bytereef.org> wrote:
Unfortunately that isn't what PEP 526 said: https://www.python.org/dev/peps/pep-0526/#annotating-expressions -gps
On Sat, Mar 23, 2019 at 12:44:29PM -0700, Gregory P. Smith wrote:
Unfortunately that isn't what PEP 526 said: https://www.python.org/dev/peps/pep-0526/#annotating-expressions
Which part though? I'd understand ... (x): int # Annotates x with int, (x) treated as expression by compiler. ... to mean that the expression is also evaluated if no assignment takes place. Stefan Krah
On 3/23/19 1:37 PM, Gregory P. Smith wrote:
Walruses aren't allowed as a top-level expression anyway: Python 3.8.0a2 (default, Feb 25 2019, 17:15:37) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d["answer"] := 42 File "<stdin>", line 1 d["answer"] := 42 ^ SyntaxError: invalid syntax --Ned.
On Sat, Mar 23, 2019 at 6:26 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
My original message was referring to someone writing ":" instead of "=" by mistake -- nothing to do with the walrus assignment, but rather using the same notation to assign a value to a key as they would when defining a dict. André Roberge
On Sat, Mar 23, 2019 at 2:43 PM Andre Roberge <andre.roberge@gmail.com> wrote:
OK, I read your Original Post for this thread, about accidentally writing `d["answer"]: 42` instead of `d["answer"] = 42`. My reaction is that this was a user mistake of the same kind as accidentally writing `x + 1` instead of `x += 1`. That's just going to happen, very occasionally. (Though why? The ':' and '=' keys are not that close together.) Read your code carefully, or in an extreme case step through it in a debugger, and you'll notice the mistake. It's not a reason to pick on that particular syntax, and not much of a reason to try and introduce a mechanism to disable type hints. Sorry. PS. This particular syntax was introduced by PEP 526, and introduced in Python 3.6. -- --Guido van Rossum (python.org/~guido)
I agree with Guido. Yes, there are sequences of symbols that used to be syntax errors but that now have some meaning in Python. The type annotation colon is one of them. There are moderately many other constructs this can be said of. I can vaguely imagine accidentally using a colon rather than an equal sign because the colon is similar to an assignment in a dict display. I don't think anyone would do that as a slip of the finger, but more as a brain glitch. However, this feels like a very uncommon hazard, and just one among dozens of similar ones. I don't think anything should be "fixed" at a language level. On Sat, Mar 23, 2019, 7:21 PM Guido van Rossum <guido@python.org> wrote:
participants (6)
-
Andre Roberge -
David Mertz -
Gregory P. Smith -
Guido van Rossum -
Ned Batchelder -
Stefan Krah