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

41–50 of 150 posts

Re: Weird Python Integers

#41

Post by concede_pluto »

std_throwaway wrote: post #2

Summary: Integers in python are full blown objects. Small numbers are stored in a central preallocated table where each entry represents one number. Setting a variable to a small integer makes it point to an entry in that table. Multiple variables may point to the same small integer objects in that table. Fooling around with the table leads to funny results.

It's just like Fortran, where everything including a constant is passed by reference, so if you assign to your arguments you might corrupt your program's only copy of 7 unless the linker put it in a read-only page.

Re: Weird Python Integers

#44

Post by yen223 »

rcthompson wrote: post #39

Is there any practical reason to use "is" to compare two ints (other than demonstrating integer interning)? Should doing so produce a warning?

I'll take it one step further - I don't think I've ever used `is` for anything other than comparisons to `None`.

Re: Weird Python Integers

#45

Post by leipert »

std_throwaway wrote: post #2

Summary: Integers in python are full blown objects. Small numbers are stored in a central preallocated table where each entry represents one number. Setting a variable to a small integer makes it point to an entry in that table. Multiple variables may point to the same small integer objects in that table. Fooling around with the table leads to funny results.

The same is true for Java apparently: https://stackoverflow.com/a/2001861

Re: Weird Python Integers

#46

Post by andrewjw »

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…

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

Re: Weird Python Integers

#47

Post by chrisseaton »

leipert wrote: post #45
std_throwaway wrote: post #2

Summary: Integers in python are full blown objects. Small numbers are stored in a central preallocated table where each entry represents one number. Setting a variable to a small integer makes it point to an entry in that table. Multiple variables may point to the same small integer objects in that table. Fooling around with the table leads to funny results.

The same is true for Java apparently: https://stackoverflow.com/a/2001861

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`.

Re: Weird Python Integers

#48

Post by santiagobasulto »

sevensor wrote: post #29
santiagobasulto wrote: post #14

Nice article. I wrote a similar piece some time ago related to booleans, in case anybody is interested: https://blog.rmotr.com/those-tricky-python-booleans-2100d5df... And to avoid issues with is/==, we recommend our students to always use == (except for `is None`). Also related piece: https://blog.rmotr.com/avoiding-being-bitten-by-python-161b0...

That's unnecesarily restrictive -- I've gotten great use out of "is". You wouldn't want to use it on an integer, but I've been using namedtuples a lot lately, and "LastKnownConfiguration is CurrentConfiguration" works great to to check whether anything has changed without checking all of the fields for equality.

You're very much right and it's a great suggestion. We just suggest that to our students when they're starting in order to help them avoid issues. But there are exceptions.

Re: Weird Python Integers

#49

Post by zde »

cma wrote: post #40
std_throwaway wrote: post #2

Summary: Integers in python are full blown objects. Small numbers are stored in a central preallocated table where each entry represents one number. Setting a variable to a small integer makes it point to an entry in that table. Multiple variables may point to the same small integer objects in that table. Fooling around with the table leads to funny results.

Micropython does a much better job, using pointer alignment guarantees to pack in small integers: https://micropython.org/ Apparently it is too hard to move python proper over to that method because of backwards compatibility issues with C extensions.

Guido said in some interview they used tagged pointers in some project before Python, and it didn't work well. Apparently there is some benefit in "value is always a reference" (less code paths?) that outweights somewhat larger heap pressure.

Re: Weird Python Integers

#50

Post by cortesoft »

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…

Ruby does it, too (== is for value comparison, while .equal? is for reference comparison)
Post reply on HN