On 3/31/2020 7:58 PM, Serhiy Storchaka wrote: > 31.03.20 20:21, Andrew Barnert via Python-ideas пише: >> Do you have code that you think actually _should_ be using is 1? Or >> code that you have to compile over and over (e.g., your deployment >> server doesn’t cache .pyc files, or you spawn new instances all the >> time without pre-built .pycs, or your app generates and compiles code >> on the fly, or …) and can’t change? If there are legitimate cases like >> those, I think that could definitely be a compelling argument against >> using SyntaxWarning here. But “the warning fired as intended and >> showed me a bug in my code” isn’t. And without more context, it’s hard >> to know which is the case here. So can you explain why this is a >> problem for you? > > Twice in the last month I have been creating a PR for CPython which > contains "is 1". I knew what I do. > > One of them was in C. I needed very fast and simple test for integers 0 > and 1, so I used the C equivalent of the "is" operator (compared > pointers) with objects representing Python integers 0 and 1. And more, I > used private CPython singletons _PyLong_Zero and _PyLong_One. There is > no guarantee that all integer 0 an 1 are represented as these singletons > (even in CPython), but it was only for optimization. In worst case I > would lose an optimization but still got a correct result. > > In second PR, I needed to determine if the optional argument with > default value 1 was passed, and use fast path if it was not passed. "== > 1" did not work, because 1.0 was error. It was first time when I > encountered a SyntaxWarning I added myself. The workaround was simple: > add a global `_ONE = 1` and use it as a default value and with the "is" > operator. It would work even if 1 was not interned. In any way, this PR > was rejected. > > Conclusion? If you know what do you do you can find a workaround. But if > you use this because you do not know difference between "is" and "==" > and it works for you now, the warning can save you from possible bugs > and teach you something.
I think that's good reasoning. "is <integer>" will almost always be a typo or misunderstanding of what "is" actually does. "is" should really only be used to determine whether some variable is pointing to a specific object. Using singletons for e.g. default values is a case where such a test can be put to good use - just beware of certain optimizations in CPython, e.g. the interning of small integers and (some) single character strings. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Mar 22 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QCDJLPRW5WQDKYFNEQRD5IXPBEXCM4KU/ Code of Conduct: http://python.org/psf/codeofconduct/
