Issue #26204: compiler now emits a SyntaxWarning on constant statement
Hi, I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204 The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python. The warning is *not* emited for strings, since triple quoted strings are a common syntax for multiline comments. The warning is *not* emited neither for ellispis (...) since "f(): ..." is a legit syntax for abstract function. Are you ok with the new warning? New behaviour: haypo@smithers$ ./python Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23)
def f(): ... False ... <stdin>:2: SyntaxWarning: ignore constant statement
import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Old behaviour: haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... False ... import dis; dis.dis(f) 2 0 LOAD_CONST 1 (False) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE
Before strings and numbers were already ignored. Example: haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... 123 ... import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Victor
Hi, On 02/08/2016 06:44 PM, Victor Stinner wrote:
Hi,
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
[...]
New behaviour:
haypo@smithers$ ./python Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23)
def f(): ... False ... <stdin>:2: SyntaxWarning: ignore constant statement
Just for my understanding: What would happen if someone has functions where some return constant expressions and others not and then that functions are used depending on some other context. E.g: def behaviour2(ctx): return 1 def behaviour1(ctx): return some_calculation_with(ctx) [...] if ... : return behaviour1(ctx) else : return behaviour2() Is that going to raise a warning? Thanks in advance! francis
On 02/08/2016 10:00 AM, francismb wrote:
On 02/08/2016 06:44 PM, Victor Stinner wrote:
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
[...]
New behaviour:
haypo@smithers$ ./python Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23) --> def f(): ... False ... <stdin>:2: SyntaxWarning: ignore constant statement
Just for my understanding:
What would happen if someone has functions where some return constant expressions and others not and then that functions are used depending on some other context. E.g:
def behaviour2(ctx): return 1
def behaviour1(ctx): return some_calculation_with(ctx)
[...]
if ... : return behaviour1(ctx) else : return behaviour2()
Is that going to raise a warning?
No, because those constants are being used (returned). Only constants that aren't used at all get omitted. -- ~Ethan~
On Mon, Feb 8, 2016 at 9:44 AM Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
The warning is *not* emited for strings, since triple quoted strings are a common syntax for multiline comments.
The warning is *not* emited neither for ellispis (...) since "f(): ..." is a legit syntax for abstract function.
Are you ok with the new warning?
I'm +1 on this. -gps
New behaviour:
haypo@smithers$ ./python Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23)
def f(): ... False ... <stdin>:2: SyntaxWarning: ignore constant statement
import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Old behaviour:
haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... False ... import dis; dis.dis(f) 2 0 LOAD_CONST 1 (False) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE
Before strings and numbers were already ignored. Example:
haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... 123 ... import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
Hum. I'm not excited by this idea. It is not bad syntax. Have you actually seen newbies who were confused by such things? -- --Guido van Rossum (python.org/~guido)
On Feb 8, 2016, at 11:13, Guido van Rossum <guido@python.org> wrote:
On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner <victor.stinner@gmail.com> wrote: I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
Hum. I'm not excited by this idea. It is not bad syntax. Have you actually seen newbies who were confused by such things?
This does overlap to some extent with a problem that newbies *do* get confused by (and that transplants from Ruby don't find confusing, but do keep forgetting): writing an expression as the last statement in a function and then getting a TypeError or AttributeError about NoneType from the caller. Victor's example of a function that was presumably meant to return False, but instead just evaluates False and returns None, does happen. But often, that last expression isn't a constant, but something like self.y - self.x. So I'm not sure how much this warning would help that case. In fact, it might add to the confusion if sometimes you get a warning and sometimes you don't. (And you wouldn't want a warning about any function with no return whose last statement is an expression, because often that's perfectly reasonable code, where the expression is a mutating method call, like self.spam.append(arg).) Also, there are plenty of other common newbie/transplant problems that are similar to this one but can't be caught with a warning, like just referencing a function or method instead of calling it because you left the parens off. That's *usually* a bug, but not always--it could be a LBYL check for an attribute's presence, for example.
Le 8 févr. 2016 8:14 PM, "Guido van Rossum" <guido@python.org> a écrit :
Hum. I'm not excited by this idea. It is not bad syntax.
Do you see an use case for "constant statements" other than strings and ellipsis? Such statement does nothing. Previously the compiler emited LOAD_CONST+POP_TOP. GCC also emits a warning on such code.
Have you actually seen newbies who were confused by such things?
Well, not really. But I don't see any use case of such code except of obvious mistakes. Sometimes such code appears after multiple refactoring (and mistakes). Are you suggesting to remove the warning? Victor
On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Le 8 févr. 2016 8:14 PM, "Guido van Rossum" <guido@python.org> a écrit :
Hum. I'm not excited by this idea. It is not bad syntax.
Do you see an use case for "constant statements" other than strings and ellipsis?
The same use case as for all dead code: it could be a placeholder for something better in the future. It could also be generated code where the generator expects the optimizer to remove it (or doesn't care). If you want to do linter integration that should probably be integrated with the user's editor, like it is in PyCharm, and IIUC people can do this in e.g. Emacs, Sublime or Vim as well. Leave the interpreter alone.
Such statement does nothing. Previously the compiler emited LOAD_CONST+POP_TOP.
GCC also emits a warning on such code.
Have you actually seen newbies who were confused by such things?
Well, not really. But I don't see any use case of such code except of obvious mistakes. Sometimes such code appears after multiple refactoring (and mistakes).
Are you suggesting to remove the warning?
I haven't seen this warning yet. I take it this is new in the 3.6 branch? -- --Guido van Rossum (python.org/~guido)
Le 8 févr. 2016 9:34 PM, "Guido van Rossum" <guido@python.org> a écrit :
If you want to do linter integration that should probably be integrated with the user's editor, like it is in PyCharm, and IIUC people can do this in e.g. Emacs, Sublime or Vim as well. Leave the interpreter alone.
In GCC, warnings are welcome because it does one thing: compile code. GCC is used by developers. Users use the produced binary. In Python, it's different because it executes code and runs code. It's used by developers and users. It's more tricky to make choices like showing or not deprecation warnings. It looks like most Python developers prefer to use an external linter. I don't really care of the warning, I will remove it.
I haven't seen this warning yet. I take it this is new in the 3.6 branch?
Yes it's a recent change in the default branch (a few hours ago). Victor
On Mon, Feb 8, 2016 at 1:20 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Le 8 févr. 2016 9:34 PM, "Guido van Rossum" <guido@python.org> a écrit :
If you want to do linter integration that should probably be integrated with the user's editor, like it is in PyCharm, and IIUC people can do this in e.g. Emacs, Sublime or Vim as well. Leave the interpreter alone.
In GCC, warnings are welcome because it does one thing: compile code. GCC is used by developers. Users use the produced binary.
In Python, it's different because it executes code and runs code. It's used by developers and users.
It's more tricky to make choices like showing or not deprecation warnings.
It looks like most Python developers prefer to use an external linter.
I don't really care of the warning, I will remove it.
Thanks! -- --Guido van Rossum (python.org/~guido)
On Tue, Feb 9, 2016 at 8:20 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Le 8 févr. 2016 9:34 PM, "Guido van Rossum" <guido@python.org> a écrit :
If you want to do linter integration that should probably be integrated with the user's editor, like it is in PyCharm, and IIUC people can do this in e.g. Emacs, Sublime or Vim as well. Leave the interpreter alone.
In GCC, warnings are welcome because it does one thing: compile code. GCC is used by developers. Users use the produced binary.
In Python, it's different because it executes code and runs code. It's used by developers and users.
It's more tricky to make choices like showing or not deprecation warnings.
It looks like most Python developers prefer to use an external linter.
fwiw, pyflakes doesnt detect this. I've created a bug for that https://bugs.launchpad.net/pyflakes/+bug/1543246 -- John Vandenberg
On 2/8/2016 16:37, John Mark Vandenberg wrote:
fwiw, pyflakes doesnt detect this. I've created a bug for that https://bugs.launchpad.net/pyflakes/+bug/1543246
Flake8 does, so it might be in the ... poorly named ... pep8 checker.
On Tue, Feb 9, 2016 at 8:41 AM, Alexander Walters <tritium-list@sdamon.com> wrote:
On 2/8/2016 16:37, John Mark Vandenberg wrote:
fwiw, pyflakes doesnt detect this. I've created a bug for that https://bugs.launchpad.net/pyflakes/+bug/1543246
Flake8 does, so it might be in the ... poorly named ... pep8 checker.
I believe the pep8 checker does not have a check for this. Could you confirm; which flake8 code are you seeing? -- John Vandenberg
On Tue, Feb 9, 2016 at 7:34 AM, Guido van Rossum <guido@python.org> wrote:
On Mon, Feb 8, 2016 at 11:51 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
Le 8 févr. 2016 8:14 PM, "Guido van Rossum" <guido@python.org> a écrit :
Hum. I'm not excited by this idea. It is not bad syntax.
Do you see an use case for "constant statements" other than strings and ellipsis?
The same use case as for all dead code: it could be a placeholder for something better in the future.
Allowing dead code is useful as it allows complex code to be left in place. It can be risky removing the code. Unused literals are stupefyingly simple statements. A line of merely a constant, e.g. 'True' or '1', does not present the same risks or benefits. That it is a hope for something better? It could be easily replaced with 'pass', '...', a comment, and/or a string literal explaining what needs improving.
It could also be generated code where the generator expects the optimizer to remove it (or doesn't care).
Why shouldnt a user see that it is generating such code? There is a decent chance that it is a bug in the generated code. fwiw, this is a syntax warning in Ruby - "unused literal ignored", since 2003 (5aadcd9). -- John Vandenberg
Hello, Le 08/02/2016 20:13, Guido van Rossum a écrit :
On Mon, Feb 8, 2016 at 9:44 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python. Hum. I'm not excited by this idea. It is not bad syntax. Have you actually seen newbies who were confused by such things?
I give regular Python trainings and I see similar errors regularly such as: - not returning something; - using something without putting the result back in a variable. However, these are impossible to warn about. What's more, I have yet to see somebody creating a constant and not doing anything with it. I never worked with Ruby dev though. My sample of dev is not big enough to be significant, but I haven't met this issue yet. I still like the idea, anything making Python easier for beginers is a good thing for me. One particular argument against it is the use of linters, but you must realize most beginers don't use linters. Just like they don't use virtualenv, pip, pdb, etc. They are part of a toolkit you learn to use on the way, but not something you start with. Besides, many people using Python are not dev, and will just never take the time to use linters, not learn about them.
On Tuesday, February 9, 2016 8:14 AM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
I give regular Python trainings and I see similar errors regularly such as:
- not returning something; - using something without putting the result back in a variable.
However, these are impossible to warn about.
What's more, I have yet to see somebody creating a constant and not doing anything with it. I never worked with Ruby dev though.
My sample of dev is not big enough to be significant, but I haven't met this issue yet. I still like the idea, anything making Python easier for beginers is a good thing for me.
What idea do you like? Somehow warning about the things that are impossible to warn about? Or warning about something different that isn't any of the things your novices have faced? Or...?
One particular argument against it is the use of linters, but you must realize most beginers don't use linters.
That doesn't mean the compiler should do everything linters do. Rank beginners are generally writing very simple programs, where the whole thing can be visualized at once, so many warnings aren't relevant. And they haven't learned many important language features, so many warnings are relevant, but they aren't prepared to deal with them (e.g., global variables everywhere because they haven't learned to declare functions yet). As a teacher, do you want to explain all those warnings to them? Or teach them the bad habit of ignoring warnings? Or just not teach them to use linters (or static type checkers, or other such tools) until they're ready to write code that should pass without warnings? Part of learning to use linters effectively is learning to configure them. That's almost certainly not something you want to be teaching beginners when they're just starting out. But if the compiler started adding a bunch of warnings that people had to configure, a la gcc, you'd be forced to teach them right off the bat. And meanwhile, once past the initial stage, many beginners _do_ use linters, they just don't realize it. If you use PyCharm or Eclipse/PyDev or almost any IDE except IDLE, it may be linting in the background and showing you the results as inline code hints, or in some other user-friendly way, or at least catching some of the simpler things a linter would check for. Whether you want to use those tools in your teaching is up to you, but they exist. And if they need any support from the compiler to do their job better, presumably they'd ask for it.
They are part of a toolkit you learn to use
on the way, but not something you start with. Besides, many people using Python are not dev, and will just never take the time to use linters, not learn about them.
If people who aren't going to go deep enough into Python to write scripts longer than a page don't need linters, then they certainly don't need a bunch of warnings from the compiler either.
I am not keen on a SyntaxWarning. Either something is python syntax, or it is not. This warning catches something linters have been catching for ages. I really don't see the value in adding this, and can see it causing more confusion than it solves. In the #python irc channel, we see quite a few newbie mistakes, but declaring a constant that isn't used is rarely if ever one of them. On 2/8/2016 12:44, Victor Stinner wrote:
Hi,
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
The warning is *not* emited for strings, since triple quoted strings are a common syntax for multiline comments.
The warning is *not* emited neither for ellispis (...) since "f(): ..." is a legit syntax for abstract function.
Are you ok with the new warning?
New behaviour:
haypo@smithers$ ./python Python 3.6.0a0 (default:759a975e1230, Feb 8 2016, 18:21:23)
def f(): ... False ... <stdin>:2: SyntaxWarning: ignore constant statement
import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Old behaviour:
haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... False ... import dis; dis.dis(f) 2 0 LOAD_CONST 1 (False) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE
Before strings and numbers were already ignored. Example:
haypo@smithers$ python3 Python 3.4.3 (default, Jun 29 2015, 12:16:01)
def f(): ... 123 ... import dis; dis.dis(f) 2 0 LOAD_CONST 0 (None) 3 RETURN_VALUE
Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com
What incantation do you need to do to make that behavior apparent? tritium@gesa:~$ python3.5 -W all Python 3.5.1 (default, Dec 18 2015, 02:15:10) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. Jedi is not installed, falling back to readline
assert True
On 2/8/2016 16:23, Victor Stinner wrote:
Le 8 févr. 2016 9:10 PM, "Alexander Walters" <tritium-list@sdamon.com <mailto:tritium-list@sdamon.com>> a écrit :
I am not keen on a SyntaxWarning. Either something is python
syntax, or it is not.
Oh I forgot to mention that Python already emits SyntaxWarning, on "assert True" for example.
Victor
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent?
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
Victor
On Tue, Feb 9, 2016 at 8:51 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent?
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
And pyflakes also has a check for this, but it is similarly tight. https://github.com/pyflakes/pyflakes/pull/51 It seems that the pyflakes maintainers tend to only accepts patches for scenarios that Python does emit a SyntaxWarning. So it is a bit of catch-22 there wrt unused constants. pylint of course reports these unused constants with its message id "pointless-statement". -- John Vandenberg
On 2/8/2016 4:51 PM, Victor Stinner wrote:
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent?
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
I think this should be left to linters also. -- Terry Jan Reedy
On 2016-02-08 5:19 PM, Terry Reedy wrote:
On 2/8/2016 4:51 PM, Victor Stinner wrote:
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent?
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
I think this should be left to linters also.
I agree. I'd remove that warning. Yury
On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote:
On 2016-02-08 5:19 PM, Terry Reedy wrote:
On 2/8/2016 4:51 PM, Victor Stinner wrote:
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent?
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
I think this should be left to linters also.
I agree. I'd remove that warning.
Please don't remove the warning, it is very useful. Compare an assertion written correctly: py> assert 1==2, "Error in arithmetic" Traceback (most recent call last): File "<stdin>", line 1, in <module> AssertionError: Error in arithmetic with the simple mistake of wrapping the "tuple" in parens: py> assert (1==2, "Error in arithmetic") <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses? py> This especially hurts people who think that assert is a function. In Python 2.5 and older, you get no warning, and can write wrong code: py> x = 2 py> assert(x==1, 'expected 1 but got %s' % x) py> Removing this warning would be a regression. -- Steve
On 2016-02-08 8:02 PM, Steven D'Aprano wrote:
On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote:
On 2016-02-08 5:19 PM, Terry Reedy wrote:
On 2/8/2016 4:51 PM, Victor Stinner wrote:
2016-02-08 22:28 GMT+01:00 Alexander Walters <tritium-list@sdamon.com>:
What incantation do you need to do to make that behavior apparent? I didn't know. I just checked. It's assert used with a non-empty tuple:
> assert ("tuple",) <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses? I think this should be left to linters also.
I agree. I'd remove that warning.
Please don't remove the warning, it is very useful.
Compare an assertion written correctly:
py> assert 1==2, "Error in arithmetic" Traceback (most recent call last): File "<stdin>", line 1, in <module> AssertionError: Error in arithmetic
with the simple mistake of wrapping the "tuple" in parens:
py> assert (1==2, "Error in arithmetic") <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses? py>
You're right! It's indeed a trap that we should warn about. Thanks! Yury
On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
I didn't know. I just checked. It's assert used with a non-empty tuple:
assert ("tuple",)
which is more interesting with a tuple without the parentheses: t = In [*4*]: t = True, In [*5*]: t Out[*5*]: (True,) works fine, but not if you use an assert: In [*7*]: assert True, File "<ipython-input-7-38940c80755c>", line 1 assert True, ^ SyntaxError: invalid syntax I actually like the Warning with the note about the problem better: <stdin>:1: SyntaxWarning: assertion is always true, perhaps remove
parentheses?
And, of course, more relevant with something Falsey in the tuple: In [*14*]: assert (False,) <ipython-input-14-05f425f558c4>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses? assert (False,) But I am curious why you get a different error without the parens? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 2016-02-08 23:21, Chris Barker wrote:
On Mon, Feb 8, 2016 at 1:51 PM, Victor Stinner <victor.stinner@gmail.com <mailto:victor.stinner@gmail.com>> wrote:
I didn't know. I just checked. It's assert used with a non-empty tuple:
>>> assert ("tuple",)
which is more interesting with a tuple without the parentheses:
t = In [*4*]: t = True,
In [*5*]: t
Out[*5*]: (True,)
works fine, but not if you use an assert:
In [*7*]: assert True,
File "<ipython-input-7-38940c80755c>", line 1
assert True,
^
SyntaxError:invalid syntax
I actually like the Warning with the note about the problem better:
<stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
And, of course, more relevant with something Falsey in the tuple:
In [*14*]: assert (False,)
<ipython-input-14-05f425f558c4>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
assert (False,)
But I am curious why you get a different error without the parens?
Try: help('assert') You'll see that in "assert (True,)", the tuple (an object) is the first condition (and probably a mistake), whereas in "assert True,", the True is the condition and the second expression (after the comma) is missing.
On Mon, Feb 8, 2016 at 3:48 PM, MRAB <python@mrabarnett.plus.com> wrote:
help('assert')
You'll see that in "assert (True,)", the tuple (an object) is the first condition (and probably a mistake), whereas in "assert True,", the True is the condition and the second expression (after the comma) is missing.
yes, of course, that explains it. -CHB
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing the warning. Compared to other "lint warnings" this one is much nastier -- it is also much more certain that it is a mistake. (Much more certain than e.g. an undefined variable, which could still be legitimate code due to dynamic updates to globals() or builtins.) -- --Guido van Rossum (python.org/~guido)
On 2016-02-09 00:53, Guido van Rossum wrote:
The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing the warning.
Compared to other "lint warnings" this one is much nastier -- it is also much more certain that it is a mistake. (Much more certain than e.g. an undefined variable, which could still be legitimate code due to dynamic updates to globals() or builtins.) Would there be less chance of confusion if there were some kind of syntax such as "assert cond with msg"?
On Mon, Feb 8, 2016 at 5:41 PM, MRAB <python@mrabarnett.plus.com> wrote:
On 2016-02-09 00:53, Guido van Rossum wrote:
The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing the warning.
Compared to other "lint warnings" this one is much nastier -- it is also much more certain that it is a mistake. (Much more certain than e.g. an undefined variable, which could still be legitimate code due to dynamic updates to globals() or builtins.)
Would there be less chance of confusion if there were some kind of syntax such as "assert cond with msg"?
Perhaps, but as long as the "with msg" isn't mandatory and the "assert x, y" syntax is still valid we'd still have to warn about "assert (x, y)". Note that in general "assert constant" is not a problem (assert True and assert False have their uses :-). It's only the literal tuple form. -- --Guido van Rossum (python.org/~guido)
On Tue, Feb 9, 2016 at 12:41 PM, MRAB <python@mrabarnett.plus.com> wrote:
On 2016-02-09 00:53, Guido van Rossum wrote:
The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing the warning.
Compared to other "lint warnings" this one is much nastier -- it is also much more certain that it is a mistake. (Much more certain than e.g. an undefined variable, which could still be legitimate code due to dynamic updates to globals() or builtins.)
Would there be less chance of confusion if there were some kind of syntax such as "assert cond with msg"?
Is assert the *only* statement that has a comma separating unrelated items? Every other statement that uses a comma is separating identical items (eg "import os, sys" - "os" and "sys" are equivalent), and tokens that have completely different meaning are separated by a word. The only other exception I can think of - pun intended - is the old "except BaseException, e:" syntax, which got dropped in Py3. Maybe it's time to introduce a new syntax with a view to deprecating the comma syntax ("use this old syntax if you need to support Python 2.7"). +1. ChrisA
Personally I don't think it's worth the churn. On Mon, Feb 8, 2016 at 5:49 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Feb 9, 2016 at 12:41 PM, MRAB <python@mrabarnett.plus.com> wrote:
On 2016-02-09 00:53, Guido van Rossum wrote:
The warning for 'assert (cond, msg)' was specifically put in because this is a nasty trap. It's *always* a mistaken attempt to write 'assert cond, msg' -- usually in an attempt to break a long line without using a backslash. I'd actually consider promoting it to a syntax error rather than removing the warning.
Compared to other "lint warnings" this one is much nastier -- it is also much more certain that it is a mistake. (Much more certain than e.g. an undefined variable, which could still be legitimate code due to dynamic updates to globals() or builtins.)
Would there be less chance of confusion if there were some kind of syntax such as "assert cond with msg"?
Is assert the *only* statement that has a comma separating unrelated items? Every other statement that uses a comma is separating identical items (eg "import os, sys" - "os" and "sys" are equivalent), and tokens that have completely different meaning are separated by a word. The only other exception I can think of - pun intended - is the old "except BaseException, e:" syntax, which got dropped in Py3. Maybe it's time to introduce a new syntax with a view to deprecating the comma syntax ("use this old syntax if you need to support Python 2.7").
+1.
ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Victor Stinner <victor.stinner <at> gmail.com> writes:
Hi,
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
The warning is *not* emited for strings, since triple quoted strings are a common syntax for multiline comments.
The warning is *not* emited neither for ellispis (...) since "f(): ..." is a legit syntax for abstract function.
I frequently use 1/0 as a quick break in a script or a program (it's even more useful with post-mortem debugging). Would it be considered as a constant and ignored instead of raising a ZeroDivisionError ? Joseph
2016-02-09 10:57 GMT+01:00 Joseph Martinot-Lagarde <contrebasse@gmail.com>:
I frequently use 1/0 as a quick break in a script or a program (it's even more useful with post-mortem debugging). Would it be considered as a constant and ignored instead of raising a ZeroDivisionError ?
"self.x - self.y" and "1/0" are not removed since they have side effects. Right now, "(1, 2, 3)" is not removed. But later we may remove it, since it has no side effect, it's a constant statement. Note: We are talking about statements. 1 is not removed in "lambda: 1" which is a valid expression ;-) Victor
On 02/09/2016 10:57 AM, Joseph Martinot-Lagarde wrote:
Victor Stinner <victor.stinner <at> gmail.com> writes:
Hi,
I changed the Python compiler to ignore any kind "constant expressions", whereas it only ignored strings and integers before: http://bugs.python.org/issue26204
The compiler now also emits a SyntaxWarning on such case. IMHO the warning can help to detect bugs for developers who just learnt Python.
The warning is *not* emited for strings, since triple quoted strings are a common syntax for multiline comments.
The warning is *not* emited neither for ellispis (...) since "f(): ..." is a legit syntax for abstract function.
I frequently use 1/0 as a quick break in a script or a program (it's even more useful with post-mortem debugging). Would it be considered as a constant and ignored instead of raising a ZeroDivisionError ?
At first, expressions involving operators are not seen as constant. But 1/2 would be removed, since the peepholer will evaluate it to 0.5 (or 0) and the constant-removal pass will recognize it as a constant (assuming this ordering of the passes). In the case of 1/0 the peepholer will try to evaluate it, but get an exception and therefore not touch the expression further. cheers, Georg
participants (18)
-
Alexander Walters -
Andrew Barnert -
Chris Angelico -
Chris Barker -
Ethan Furman -
francismb -
Georg Brandl -
Gregory P. Smith -
Guido van Rossum -
John Mark Vandenberg -
Joseph Martinot-Lagarde -
Michel Desmoulin -
MRAB -
Steven D'Aprano -
Terry Reedy -
Victor Stinner -
xiscu -
Yury Selivanov