On Mar 31, 2020, at 05:59, Philip Kahn <tigerhawkvok@gmail.com> wrote:
I understand it locks in that particular implementation detail, but it also seems unlikely that that particular optimization (int 0 and int 1 as specific memory objects) would ever make sense to NOT be including in a shipping implementation (future proof by practicality).
Why? As far as I know, that optimization has never been included in any release of Jython, Iron, PyPy, Brython, or Skulpt. That particular test is true in some of these implementations anyway—in Brython because of a completely different optimization (ints up to 2**53 are usually smuggled around as doubles rather than as references to objects), in PyPy because of a pessimization they added to be more bug-compatible with CPython. And in some implementations it’s true sometimes and false other times (e.g., if they merge compile-time constants but don’t intern small ints, “is 1” will be true for a value that the compiler could reduce to a constant, but false for one that had to be computed at runtime). If you’re writing code like this because you expect that all Python interpreters will always have this optimization, your code is wrong and just happens to work in some situations. 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?