Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird Python Integers

kate.io

Post reply on HN
Print view View original

91–100 of 150 posts

Re: Weird Python Integers

#91

Post by zodiac »

zeptomu wrote: post #59
chrisseaton wrote: post #47

Earlier quoted context omitted.

That's only the case if you specifically treat them as full-blown objects. If you treat them as primitives they stay as primitives. Note that the type of these local variables is `Integer` rather than `int`.

Although you are technically correct (the best kind of correct), it is still a shortcoming of objects (or maybe just their implementation in Java). It is just a bad idea to implement the '==' operator using comparison on addresses instead of on values and I consider languages pretty low-level that do that. In a sane language == is always a function adhering the attributes of an equivalence relation (reflexivity, symm…

Just to point out, "equal by comparing addresses" is symmetric and transitive as well. (whether you call it reflexive is an uninteresting question, if you think about it)

Re: Weird Python Integers

#92

Post by katee »

kmill wrote: post #64
squeaky-clean wrote: post #60

I wrote a blog post about this in the past. It's really fun going through the oddities of the language like this. It caches small integers, but also literals used in the same interpreter context (I'm probably getting that last term wrong). You'll get different results if you run these in from the shell as opposed to executing a script, try it out! Here's a fun example >>> x = 256; x is 256 True >>> x = 257; x is 257…

The Python interpreter compiles programs into bytecode first, and the bytecode includes instructions that load a constant from the constant pool. As an example, >>> def f(): ... x = 2222; y=2222 ... return x is y ... >>> f() True >>> f.func_code.co_consts (None, 2222) This last line is showing the constant pool, which is just a standard Python tuple. I believe the REPL compiles each input in a new toplevel module con…

I'm glad you and squeaky-clean wrote these comments. When I was experimenting in the Python REPL, I was confused by the last line here:

    >>> 100 is 100
    True
    >>> (10 ** 2) is (10 ** 2)
    True
    >>> (10 ** 3) is (10 ** 3)
    False
    >>> 1000 is 1000
    True
I used the disassembler, but I completely missed that although `1000 is 1000` and `(10 3) is (10 3)` both get optimized to nearly identical bytecode they load different constants. I wrote it up in a new post and thanked you both. https://kate.io/blog/2017/08/24/python-constants-in-bytecode...

Re: Weird Python Integers

#93

Post by tahoemph999 »

This is not about comparing values. "is" compares address (memory location) and == compares value. While the same address implies the same value (for integers; see Naan for fun counterexample otherwise) the same value doesn't imply the same address.

Re: Weird Python Integers

#94

Post by thaumasiotes »

zeptomu wrote: post #78
thaumasiotes wrote: post #76

Earlier quoted context omitted.

There is an obvious answer to which of comparison by value vs "comparison by reference" (I would have called this "comparison by identity") is more fundamental. Comparison by reference is more fundamental than comparison by value.

Yeah, well you know, that's just like your opinion, man.

On the off-chance that you're serious, I'll point out that there is no way to compare equal by identity without also comparing equal by value.

Re: Weird Python Integers

#96

Post by chrisseaton »

hyperpape wrote: post #87
chrisseaton wrote: post #62

Earlier quoted context omitted.

Why is value-equality inherently more sane than identity-equality, in an object-orientated language? Value-equality takes an unbound amount of time to compute, as well.

What's the meaning of new Long(5) == new Long(5);? I know why the implementation lets me ask that question and I know why it's false, but I'd say that there's no reasonable question I'd ever want to ask using that expression.

You can think up an unreasonable example for anything though.

If I have a graph data structure then `node == node` with identity does make sense to me in lots of cases.

And what's the value equality of `(new Object()).equals(new Object())` - they have no value.

Re: Weird Python Integers

#97

Post by lmm »

int_19h wrote: post #33
wyldfire wrote: post #9

> That is suprising! It turns out that all “small integers” with the same value point to the same memory. We can use the Python built-in function id which returns a value you can think of as a memory address to investigate. Unfortunately this blog post seems to miss a great opportunity to show you how you should compare integers for equality -- using the equality operator `==` and not the identity comparison `is`. ED…

It never ceases to amaze me that Python seems to be the only one that got this right - namely, that == should have value comparison semantics, for all types, and that some other (preferably distinctive enough, rather than something like ===) operator should always compare references. Then you look at something like C#, where == compares values for value types and references for reference types, except that == is over…

It's still confusing in Java because there are primitive types which == compares by value. Scala gets it right: == does the right thing and there's some operator I never use (I think it's "eq"?) if you really want reference comparison.

Re: Weird Python Integers

#98

Post by int_19h »

lmm wrote: post #97
int_19h wrote: post #33

Earlier quoted context omitted.

It never ceases to amaze me that Python seems to be the only one that got this right - namely, that == should have value comparison semantics, for all types, and that some other (preferably distinctive enough, rather than something like ===) operator should always compare references. Then you look at something like C#, where == compares values for value types and references for reference types, except that == is over…

It's still confusing in Java because there are primitive types which == compares by value. Scala gets it right: == does the right thing and there's some operator I never use (I think it's "eq"?) if you really want reference comparison.

In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It'd be more obvious if Java required explicit dereferencing like C++ does, but it's still consistent. Just not convenient.

Re: Weird Python Integers

#99

Post by int_19h »

alphaalpha101 wrote: post #83
andrewjw wrote: post #46

Earlier quoted context omitted.

Correct me if I'm wrong, but doesn't C++ use == for value comparison?

C++ uses `==` for whatever you want. But generally in C++, user-defined types will be documented as either having 'reference semantics' or 'value semantics' and all aspects of the type will conform to that.

In C++, == pretty much always uses value semantics regardless, because reference semantics are pretty much always explicit (dereference with star etc).
Post reply on HN