Mailman 3 Enabling / disabling optional type hinting - Python-ideas

newer
dict.merge(d1, d2, ...) (Counter...

Enabling / disabling optional type hinting

older
Re: [Python-ideas] PEP: Dict...

Andre Roberge

23 Mar 2019 23 Mar '19

2:36 p.m.

Consider the following example [1]: Python 3.7.0 (v3.7.0:1bf9cc5093...

...

...
...
d = { ... "injury": "flesh wound" ... } d["answer"]: 42 if "answer" in d: ... print("Don't panic!") ... else: ... print("Sorry, I can't help you.") ... Sorry, I can't help you.

= = 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.

Attachments:

attachment.htm (text/html — 3.1 KB)

Show replies by date

Gregory P. Smith

23 Mar 23 Mar

5:37 p.m.

On Sat, Mar 23, 2019 at 7:37 AM Andre Roberge wrote:

...

Consider the following example [1]:

Python 3.7.0 (v3.7.0:1bf9cc5093...

...
...
...
d = { ... "injury": "flesh wound" ... } d["answer"]: 42 if "answer" in d: ... print("Don't panic!") ... else: ... print("Sorry, I can't help you.") ... Sorry, I can't help you.

= = 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.

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

...

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

Too late. Requiring something like that would break existing code. 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.

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

Stefan Krah

5:59 p.m.

On Sat, Mar 23, 2019 at 10:37:43AM -0700, Gregory P. Smith wrote:

...

A useless statement like that isn't likely to be typed. I've never seen anyone do that.

Unlikely yes, but ideally type annotations should not alter program behavior:

...

...
...
d = {} try: d["x"] ... except KeyError: print("KeyError") ... KeyError

d = {} try: d["x"] : int ... except KeyError: print("KeyError") ...

Stefan Krah

Gregory P. Smith

7:44 p.m.

On Sat, Mar 23, 2019 at 11:00 AM Stefan Krah wrote:

...

On Sat, Mar 23, 2019 at 10:37:43AM -0700, Gregory P. Smith wrote:

...
A useless statement like that isn't likely to be typed. I've never seen anyone do that.

Unlikely yes, but ideally type annotations should not alter program behavior:

...
...
...
d = {} try: d["x"] ... except KeyError: print("KeyError") ... KeyError

d = {} try: d["x"] : int ... except KeyError: print("KeyError") ...

Unfortunately that isn't what PEP 526 said: https://www.python.org/dev/peps/pep-0526/#annotating-expressions -gps

Stefan Krah

7:52 p.m.

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

Ned Batchelder

9:25 p.m.

On 3/23/19 1:37 PM, Gregory P. Smith wrote:

...

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.

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.

Andre Roberge

9:41 p.m.

On Sat, Mar 23, 2019 at 6:26 PM Ned Batchelder wrote:

...

On 3/23/19 1:37 PM, Gregory P. Smith wrote:

...
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.

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

...

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.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum

11:20 p.m.

On Sat, Mar 23, 2019 at 2:43 PM Andre Roberge 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.

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)

David Mertz

11:36 p.m.

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 wrote:

...

On Sat, Mar 23, 2019 at 2:43 PM Andre Roberge 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.

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) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

1859

Age (days ago)

1859

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Andre Roberge
David Mertz
Gregory P. Smith
Guido van Rossum
Ned Batchelder
Stefan Krah

Enabling / disabling optional type hinting

tags

participants (6)