[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It cannot be suppressed by the code in the module caused a warning, because the 
warning is emitted at compile time. You need to silence it before compiling 
that module. Once you have compiled it, warning will no longer be emitted.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[thautwarm]

thautwarm  added the comment:

Thanks.
However, unfortunately, this warning seems impossible to suppress.

Use following example:

  import warnings
  warnings.filterwarnings('ignore')

  warnings.warn(SyntaxWarning("test"))

  def f(x):
return x is 5

  print(f(5))

I succeeded in suppressing my own  SyntaxWarning("test") , but the output is 
still:
  
  python a.py
  a.py:7: SyntaxWarning: "is" with a literal. Did you mean "=="?
return x is 5
  True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Bachsau]

Change by Bachsau :


--
nosy:  -Bachsau

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Ammar Askar]

Ammar Askar  added the comment:

That would potentially let an invalid usage slip through, since you know what 
you're doing, you can suppress the warning with:

  warnings.filterwarnings('ignore', category=SyntaxWarning, message='"is" with 
a literal')

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[thautwarm]

thautwarm  added the comment:

What if using identity equality on integer literals is intended?

I'm now trying to speed up the generated code via the integer interning 
mechanism told by https://docs.python.org/3/c-api/long.html#c.PyLong_FromLong .

I think it okay to not complain when the operand of `is` or `is not` is an 
integer between -5 and 256.

--
nosy: +thautwarm

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy:  -gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Should this also produce warnings for `list` / `dict` / `set` literals?

No, because these cases are useless expressions, but they are not hidden bugs. 
The result is always False and does not rely on the implementation.

> SyntaxWarnings should be raised on problems with the *syntax* not for 
> ProgrammerMightBeDumb errors. There are a whole lot of things a programmer 
> not knowing the language could do wrong. But these are syntactically valid 
> expressions and it is not the purpose of a compiler to teach.

SyntaxErrors should be raised on problems with the syntax. SyntaxWarnings *can* 
be raised for the syntax which is valid but is definitely a bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Bachsau,

to respond to the substance of your comments: it is not the *primary* 
purpose of a compiler to teach, but compiler warnings on potentially 
wrong behaviour is a long-standing tradition in many languages, 
including Python.

This is not the first such warning in Python: it has warned on incorrect 
assertions for a few releases now:

py> assert (flag, "error")
:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

Ideally a language should have no warts, gotchas or features which are 
easy to misuse, but in practice that's not the case. Identity testing in 
Python is, unfortunately, one of those features which are easy to 
misuse, and it has real consequences.

If you go back to the very first post in the discussion which launched 
this feature, Gregory points out that PyPy had to change their behaviour 
to work around so many bugs in Python code from people wrongly using 
identity tests over equality.

https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86

As the Zen says, "practicality beats purity" and this is a low-impact 
change with no runtime cost that we expect will nevertheless help catch 
many logical errors.

Apart from your aesthetic sense that the compiler shouldn't try to 
educate users into using correct code rather than wrong code that works 
by accident, do you have any objections to this feature?

Evidence of code that breaks because of this change is especially 
valuable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:

"This is bullshit." struck me as jarring and rude.  I will stop there.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy:  -terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> (message from a code of conduct violating troll deleted)

How did Bachsau violate the code of conduct, and what evidence do you 
have that they were anything but 100% sincere in their comments?

>From where I am sitting, the only person violating the CoC is you 
(Gregory) with your hair-trigger accusation of trolling and zero- 
tolerance removal of a critical message. Your behaviour fails the CoC on 
all three points: it is not open, considerate or respectful.

It is not open to criticism: in #msg333923 Gregory wrote "let's see if 
anyone complains during the betas" but the first complaint gets censored 
without one word acknowledging the substance of the complaint.

Think about the message that sends about our openess to criticism.

Its not considerate: Bachsau took the time to comment about something 
they clearly feel very strongly about, even if only 30 seconds, and your 
response was to delete their comments with only a vague hand-wavy claim 
of a CoC violation. You didn't bother to explain what the claimed 
violation was. Even if the violation was clear in your head, it is not 
considerate of others who may not have that clarity of thought you do. 
How is Bachsau supposed to learn what to avoid doing in the future?

Backsau attacked the feature. Instead of assuming good faith until 
proven otherwise, you (Gregory) assumed bad faith from the first post, 
and attacked the *person*, labelling them a troll on zero evidence.

Being called a troll is not a small thing: it is an accusation that the 
poster is an insincere, dishonest, lying troublemaker. That's not 
respectful.

Accusations of trolling should only be made on the basis of a pattern of 
behaviour, not because you don't like the poster's comment or disapprove 
of how they say it. Tone policing ("its not what you said, its how you 
said it") is an act of oppression and a derailing tactic. The stakes 
here may not be high (it's just a syntax warning!) but being passionate 
about Python is a good thing.

Vigourous and passionate disagreement with a feature is not trolling. It 
is not a violate the CoC to use strong language or to disagree with a 
feature. I don't believe anything in Bachsau's post violated the CoC. 
But I am sure that your heavy-handed act did.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

(message from a code of conduct violating troll deleted)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Change by Gregory P. Smith :


--
Removed message: https://bugs.python.org/msg345086

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Bachsau]

Bachsau  added the comment:

This is bullshit. SyntaxWarnings should be raised on problems with the *syntax* 
not for ProgrammerMightBeDumb errors. There are a whole lot of things a 
programmer not knowing the language could do wrong. But these are syntactically 
valid expressions and it is not the purpose of a compiler to teach.

--
nosy: +Bachsau

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Anthony Sottile]

Anthony Sottile  added the comment:

Should this also produce warnings for `list` / `dict` / `set` literals?

```
$ python3.8
Python 3.8.0a3 (default, Mar 27 2019, 03:46:44) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x is []
False
>>> x is {}
False
>>> x is {1, 2}
False
```

--
nosy: +Anthony Sottile

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[STINNER Victor]

STINNER Victor  added the comment:

The warning is emited twice, see: bpo-35798.

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thanks.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 3bcbedc9f1471d957a30a90f9d1251516b422416 by Serhiy Storchaka in 
branch 'master':
bpo-34850: Emit a warning for "is" and "is not" with a literal. (GH-9642)
https://github.com/python/cpython/commit/3bcbedc9f1471d957a30a90f9d1251516b422416


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Lets move forward with this as a SyntaxWarning in 3.8 and see if anyone 
complains during the betas.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If you are fine with this change Gregory, do you mind to withdraw your request 
and remove the DO-NOT-MERGE label on GitHub?

As for DeprecationWarning vs SyntaxWarning:

1. It looks as misuse of DeprecationWarning. We do not plan to remove this 
feature in future. Emitting it will send a false signal to users. And 
SyntaxWarning was added such kind of warning: syntactically valid code that for 
sure is an error.

2. Seems there is no differences between DeprecationWarning and SyntaxWarning 
if they are emitted at compile time. They will be shown by default in all 
cases, in the main script and in modules.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Oh neat, I didn't realize that Nathaniel.  That makes such warnings much more 
useful.

I'm fine if you go ahead with this change.  In the unlikely event it turns out 
to cause user annoyance problems in betas due to third party code that can't be 
updated, we can reconsider.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

> In my experience people are more likely to run code through a linter than 
> they are to ever run an interpreter with DeprecationWarning enabled.

This used to be true, and it was a disaster. So there's been a lot of work to 
fix it, and it's not true anymore.

Starting in 3.7, the built-in REPL has DeprecationWarning enabled by default, 
as do all standalone scripts (see PEP 565).

IPython/Jupyter has enabled DeprecationWarning by default for interactive code 
for about 3 years now: https://github.com/ipython/ipython/issues/8478

pytest started showing DeprecationWarnings by default a few months ago, and 
unittest has done so for ages.

I don't think I've ever met someone who skipped straight to linting, without 
ever having used a REPL, or written a script, or written a test :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm actually fine either way.  Consider me a solid ±0

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Looks like we have a stand-off between core devs, and no BDFL to make a ruling.

There is support for the feature from at least Barry and Raymond  (although I 
think Guido was cool on the idea, maybe?). Gregory, do you feel strongly enough 
about this that you would reverse the commit if Serhiy just went ahead and 
committed it? Nobody wants a revert war :-)

To me, this seems like a low-cost feature that will help some developers 
without inconveniencing anyone. As Serhiy points out, SyntaxWarning is only 
emitted when the code is compiled, so it is only going to be visible to the 
developer of the module, not the user of the module.

Let's not allow the perfect be the enemy of the good enough. I think this is a 
helpful feature for developers, and as Raymond says it will help teach 
beginners the difference between `is` and equality. The people who are most 
prone to making this mistake are the ones least likely to be using a linter. 
And we know it is helpful: Serhiy already used it to find a bug in IDLE.

Gregory, you wanted to close this as not a bug, but nobody says it is a bug, it 
is an enhancement. And I think there is consensus that this *is* an 
enhancement. Nobody has said that there are good use cases for using `is` on 
literals in production code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Given that linters like pylint can already detect the common case of this issue 
when using `is` and `is not` to compare to a literal where == or != seems more 
appropriate, I don't think a warning is very useful.

In my experience people are more likely to run code through a linter than they 
are to ever run an interpreter with DeprecationWarning enabled.

I do like the concept of using a not visible by default warning, but I don't 
think adding a LintWarning or misusing DeprecationWarning adds much value.

I suggest closing this issue as won't fix / not a bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Would it be more acceptable to use a DeprecationWarning? It's not really the 
right thing because we're not planning to ever actually remove the 
functionality. But, we've already gone to a lot of trouble to try to show 
DeprecationWarnings specifically to devs and not end users (hiding them by 
default, except if the source was the REPL or a test, getting patches into 
every test framework to handle this, etc.). And the issues here seem to be 
identical.

Or maybe LintWarning inherits from DeprecationWarning? Or the share a common 
superclass?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I like this proposal better than a separate test mode.  But users will see 
compiler warnings for main modules and for packages recompiled for a new 
version or for a maintenance releases with a byte code bump, and for 
unprecompiled packages on systems that do not allow .pyc caching.

The first will not matter for packages with minimal main modules.  Recompiles 
will be rare.  I suspect that the 3rd possibility is also rare.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Ping.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Gregory, do you still have objections against adding these warnings?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Turn the check on only when PYTHONDEVMODE is set?

This will reduce the value of this warning to zero. If the user doesn't know 
that using "is" with string or numerical literals is bad and doesn't use 
checkers, it is unlikely that he uses PYTHONDEVMODE.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Neil Schemenauer]

Neil Schemenauer  added the comment:

> The problem with a SyntaxWarning is that the wrong people will see it. It 
> gets in the way of users of applications that happen to be written in Python.

Turn the check on only when PYTHONDEVMODE is set?  Seems like it solves the 
issue with the wrong people seeing the warning.

--
nosy: +nascheme

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Raymond Hettinger]

Raymond Hettinger  added the comment:

> I like this solution of a syntax warning for `is ` 
> and I agree that `== None` should not be a warning.

+1 for me as well.  Besides catching potential bugs, it will be of instant 
benefit for teaching Python.

--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Please move the "chaos" discussion to #34867

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Guido van Rossum]

Guido van Rossum  added the comment:

Consider moving the chaos discussion to a new issue.

On Mon, Oct 1, 2018 at 6:33 AM Steven D'Aprano 
wrote:

>
> Steven D'Aprano  added the comment:
>
> On Sun, Sep 30, 2018 at 10:24:41PM +, Nathaniel Smith wrote:
> > Would it make sense to implement a "chaos" mode (that e.g. testing
> > tools could enable unconditionally), that disables the small integer
> > and small string caches?
>
> I'm not really sure that "chaos" is a good name for that. Contrast
> the rather restricted scope ("disable caches") with this example of
> chaos:
>
> https://en.wikipedia.org/wiki/Chaos_Monkey
>
> --
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Sun, Sep 30, 2018 at 10:24:41PM +, Nathaniel Smith wrote:
> Would it make sense to implement a "chaos" mode (that e.g. testing 
> tools could enable unconditionally), that disables the small integer 
> and small string caches?

I'm not really sure that "chaos" is a good name for that. Contrast 
the rather restricted scope ("disable caches") with this example of 
chaos:

https://en.wikipedia.org/wiki/Chaos_Monkey

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Jakub Wilk]

Change by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Yeah, something like that. Or sys.enable_chaos_mode(), that pytest or whoever 
could call before running tests.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

If we were to ship a "chaos" mode in the CPython interpreter itself, I assume 
you envision an interpreter flag and/or env var?  If it required someone 
compiling the interpreter a special way I don't think it would be widely 
adopted within continuous integration testing systems.

I was actually pondering doing a "chaos" mode of sorts at work because I have 
the power to cause everyone's tests to be run that way mode by default.  (I'd 
basically just disable interning and str/int singletons)  But while it's a nice 
idea, it's low on my work priorities.  While we had thousands of is literal 
comparisons that we're about to fix en-masse, they are only a tiny fraction of 
all literal comparisons in our codebase.  And pylint is now more widely used 
which should help prevent new ones.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Nathaniel Smith]

Nathaniel Smith  added the comment:

Would it make sense to implement a "chaos" mode (that e.g. testing tools could 
enable unconditionally), that disables the small integer and small string 
caches?

--
nosy: +njs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

miss-islington  added the comment:


New changeset cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d by Miss Islington (bot) 
in branch '3.6':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/cb0bec37dd8279555bc01fa03a259eaf7dbb6d5d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

miss-islington  added the comment:


New changeset 214c0b3d153c4bad14086888b9de0826a7abc083 by Miss Islington (bot) 
in branch '3.7':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/214c0b3d153c4bad14086888b9de0826a7abc083


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:

To me, this issue is about unnecessary dependence on implementation details, 
with the particular example being 'is' versus '=='.  Perhaps PEP8, Programming 
Recommendations, should have a new subsection 'Implementation Dependencies' to 
recommend against such dependency when not necessary.

Although IDLE depends on CPython's tkinter, I agree that it should follow this 
principle.  I extracted the idlelib change to PR9649 to be applied and 
backported regardless of the fate of Serhiy's main proposal.

At least on Windows, "assert (0, 'bad')" raises SyntaxWarning in freshly 
compiled 3.6.7+ but not in 3.7.1+ or 3.8.

[A separate issue (#34857): the warning is not displayed in IDLE and the 
warning in the Shell causes looping.]

--
assignee: terry.reedy -> serhiy.storchaka
components:  -IDLE

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

Change by miss-islington :


--
pull_requests: +9042

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[miss-islington]

Change by miss-islington :


--
pull_requests: +9041

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 5fa247d60d4f3f2b8c8ae8cb57363aca234344c2 by Terry Jan Reedy in 
branch 'master':
bpo-34850: Replace is with == in idlelib.iomenu (GH-9649)
https://github.com/python/cpython/commit/5fa247d60d4f3f2b8c8ae8cb57363aca234344c2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +9040

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Guido van Rossum]

Guido van Rossum  added the comment:

Yet, Greg’s point is that this only works if the developer tests their code
with the new Python version.

I’m not sure that his proposal is better though. I think static checkers
are the better remedy.

On Sun, Sep 30, 2018 at 10:02 AM Serhiy Storchaka 
wrote:

>
> Serhiy Storchaka  added the comment:
>
> There is a large difference with the DeprecationWarning in the md5 and sha
> modules.
>
> A SyntaxWarning is emitted when the compiler compiles Python sources to
> bytecode. Since bytecode is cached in pyc files, you will see it at most
> once at first run of the application. If the application compiles Python
> files at install time, warnings will be emitted at that time, and will be
> not emitted when run the application. If the application is distributed
> with precompiled pyc files, the user will not see warnings at all. If the
> developer installs dependencies that contain this error, his will see a
> warning only once, and can either ignore it (taking the current state), or
> report a bug. Warnings will not annoy him when he debug his code.
>
> In contrary, the DeprecationWarning was emitted every time when you import
> the md5 or sha modules.
>
> Professional applications likely already use checkers which caught this
> error. This warning will help non-professional applications distributed as
> a single script or handful of scripts. Users of such application often seat
> near its author. In many cases the only user is its author.
>
> --
>
> ___
> Python tracker 
> 
> ___
>
-- 
--Guido (mobile)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

This is a nice approach to the problem.  I completely agree that we cannot 
change `is` semantics.  I'm okay with leaving it to checkers to catch `== None`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is a large difference with the DeprecationWarning in the md5 and sha 
modules.

A SyntaxWarning is emitted when the compiler compiles Python sources to 
bytecode. Since bytecode is cached in pyc files, you will see it at most once 
at first run of the application. If the application compiles Python files at 
install time, warnings will be emitted at that time, and will be not emitted 
when run the application. If the application is distributed with precompiled 
pyc files, the user will not see warnings at all. If the developer installs 
dependencies that contain this error, his will see a warning only once, and can 
either ignore it (taking the current state), or report a bug. Warnings will not 
annoy him when he debug his code.

In contrary, the DeprecationWarning was emitted every time when you import the 
md5 or sha modules.

Professional applications likely already use checkers which caught this error. 
This warning will help non-professional applications distributed as a single 
script or handful of scripts. Users of such application often seat near its 
author. In many cases the only user is its author.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Gregory P. Smith]

Gregory P. Smith  added the comment:

The problem with a SyntaxWarning is that the wrong people will see it. It gets 
in the way of users of applications that happen to be written in Python.

scenarios:

(a) A Python interpreter gets upgraded, and suddenly the _users_ of an 
application start seeing nasty warnings when they invoke the tool that happens 
to be implemented in Python. Warnings that they have no power to do anything 
about.

(b) A developer installs the shiny new version of Python with the warning 
feature, then pip install's all of the dependencies for the application they 
are working on.  Some of those contain "is" problems so they're left in a 
situation where they either have to figure out how to fix code from N different 
transitive dependencies libraries that they are not the author of - or not use 
that Python version to ship their code.  Keep in mind that it is common for 
deps to be pinned to ranges of versions instead of "always the latest" so even 
when deps fix their code, many people won't see it for a long time.

These scenarios are real, this is exactly what happened with the 
DeprecationWarning added to the old md5.py and sha.py modules.

A warning raised at import time isn't even one that can be meaningfully caught 
in a well structured application.  Doing so requires importing the warnings 
module first thing and setting up warning filters before any other imports.  
This is ugly boilerplate for anyone to need to resort to.

As much as I want us to do something to ameliorate this anti-pattern in code, I 
don't think a SyntaxWarning is a great way to do it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Xiang Zhang]

Xiang Zhang  added the comment:

I have catched using `is` to do string equality check in our codebase by 
linters before. Not all my colleagues know what's not suitable here.

The only common and suitable case I can think of is programmers are exploring 
CPython internals, like what stackoverflow Q and some Python blogs.

--
nosy: +xiang.zhang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Suggestions about the wording of the warning message are welcome.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Steven D'Aprano]

Steven D'Aprano  added the comment:

I like this solution of a syntax warning for `is ` and I agree that 
`== None` should not be a warning.

(And for what its worth, I strongly disagree with making `is` a hybrid 
sometimes-check-identity-sometimes-check-equality operator.)

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

It also fixes an incorrect use of "is" with an empty string in IDLE.

--
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +9034
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34850] Emit a syntax warning for "is" with a literal

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Gregory have noticed that the "is" and "is not" operator sometimes is used with 
string and numerical literals. This code "works" on CPython by accident, 
because of caching on different levels (small integers and strings caches, 
interned strings, deduplicating constants at compile time). But it shouldn't 
work on other implementations, and can not work even on early or future CPython 
versions.

https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86

I think that the adequate solution of this issue is not demoting the "is" 
operator, but emitting a syntax warning. In general, this is a work for 
third-party checkers. But many people don't use checkers for their one-time 
scripts, using "is" with a literal is always a mistake, and it is easy to add a 
check for this in the compiler.

Currently the compiler emits SyntaxWarning only for parenthesis in assert: 
`assert(x, "msg")`. But in earlier versions there were more warnings (they are 
errors). In 3.8 yet one SyntaxWarning will be added instead of 
DeprecationWarning for unknown escape sequences in string literals.

The proposed PR makes the compiler emitting a SyntaxWarning when the "is" or 
"is not" operators are used with a constant (except singletons None, False, 
True and ...). A warning will be replaced with a SyntaxError if the warnings 
system is configured to raise errors. This is because SyntaxError contains more 
information and provides better traceback. The same change was made for 
"assert(...)". Added tests, including tests for "assert(...)".

Barry have noted that using the "==" operator with None can be also classified 
as an error. But I think that in this case there may be legal uses of this, and 
the compiler should not complain. It is a work for third-party checkers, which 
can provide configuration options for enabling and disabling particular kinds 
of checks.

--
components: Interpreter Core
messages: 326714
nosy: barry, gregory.p.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Emit a syntax warning for "is" with a literal
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com