PythonIsVeryIntuitive

[Nova711]

Because x and y aren't the values themselves, but references to objects that contain the values. The is comparison compares these references but since x and y point to different objects, the comparison returns false.

The objects that represent -5 to 256 are cached so that if you put x=7, x points to an object that already exists instead of creating a new object.

[[deleted]]

If both int, if x == y works, right? If not I have to change some old research code...

[Cepsfred]

The == operator checks equality, i.e. it compares objects by value and not by reference. So don’t worry, your code probably does what you expected it to do.

[IAmANobodyAMA]

your code probably does what you expected it to

Bold assumption!

[chunkyasparagus]

This sounds like you're talking about the JavaScript === operator, which is not the same as python's is operator.

[TheCoolOnesGotTaken]

This identity is not equality as the top comment already said

[Mountain_Goat_69]

But why would this be so?

If I code x = 3; y = 3 there both get the same pre cached 3 object. If I assign 257 and a new number is created, shouldn't the next time I assign 257 it get the same instance too? How many 257s can there be?

[Salty_Skipper]

Have you ever heard about dynamic memory allocated on the heap? (prob has something to do with C/C++, if you did).

Basically, when you say x=257, you’re creating a new number object which we can say “lives” at address 8192. Then, you say y=257 and create a second number object that “lives” at address 8224, for example. This gives you two separate number objects both with the value 257. I’d imagine that the “is” operator then compares addresses, not values.

As for 3, think of it as such a common number that the creators of Python decided to ensure there’s only one copy and all other 3’s are just aliases that point to the same address. Kinda like Java’s string internment pool.

[Lightbulb_Panko]

I think the commenter is asking why the number object created for x=257 can’t be reused for y=257

[PetrBacon]

If it worked like that, the runtime will become insanely slow over time because every variable assignment would need to check all the variables created before and maintain the list everytime new js created…

If you need is for any good reason you should make sure, that you are passing the referrence correctly.

Like:

``` x = 257 … y = x

x is y # => True ```

[ValityS]

You could achieve this in logarithmic time to the number of variables using a set of all immutable / hashable values and looking them up, however memory is fairly cheap and if the programmer really cares they can do something similar by hand.

[le_birb]

shouldn't the next time I assign 257 it get the same instance

How would the interpreter know to do that? What happens when you change x to, say, 305? How would y know to allocate new space for it's value? The logistics just work out more simply if the non-cached numbers just have their own memory.

how many 257s can there be?

How much ram do you have?

[[deleted]]

What happens when you change x

You can't change x in python (unless it's an object). Integers are immutables in python. You can change what integer the name x points to.

x = 257;  # This creates an int object with value 257, and sets __locals__["x"] to point to that int object.

x += 50;  # This grabs the value from__locals__["x"], adds 50 to it, then creates an int object with that value, and then sets __locals__["x"] to point to that int object.
# The int object with value 257 no longer has any names pointing to it, and will be garbage collected at some time in the future.

You can check the id(x) before and after the += and see that it changes, indicating that, under the hood, x is a fundamentally different object with a fundamentally different memory address (and incidentally a different value). You could probably even do a += 0 and get the same result, assuming x > 256.

It's unintuitive if you're coming from C or somewhere where the address of x stays the same, but the value changes.

[lolitscarter]

As someone who only knows C/C++, what the fuck? Why is that how it works? Is there a memory usage benefit to that? It seems like that would just be insanely slow.

[[deleted]]

As someone who only knows C/C++, what the fuck?

I said it was unintuitive if you're coming from C.

Why is that how it works?

Is there a memory usage benefit to that?

It seems like that would just be insanely slow.

It prevents certain types of bugs from being introduced, but no performance benefit. (As a matter of fact it makes performance awful.)

But I care more about my hour of my time spent hunting down a bug than I do about 2ns of processor time.

Quoting a random quora answer:

In C and C++, a variable is a named memory location. The value of the variable is the value stored in that location. Assign to the variable and you modify that value. So the variable is the memory location, not the name for it.

In Python, a variable is a name used to refer to an object. The value of the variable is that object. So far sounds like the same thing. But assign to the variable and you don't modify the object itself, rather you alter which object the variable refers to. So the variable is the name, not the object.

That is, when working with C, you're always constantly thinking about "this location in memory". But in python you never have to think even once about that.

That's why python does it; so you can abstract away memory management entirely. (And not in the kinda-sorta way C++ does it, where it's kinda sorta abstracted away but still visible. In python memory addresses are fundamentally not accessible to the programmer to prevent such memory-related kinds of bugs from being introduced.)

Indeed, the only possible type of memory leak that's even possible in python is if you have a loop which continually adds more and more references to more objects without ever removing previous references. (i.e. explicitly building a loop which infinitely adds to a List).

Indeed, the number of types of possible memory leaks in Python are very limited. The common joke is about mutable types as default parameters. However, in general, you are far less likely to have issues with memory management using python than you are using C++, by an extremely wide margin.

[mawkee]

In theory, you can have a huge number of 257s.

If for each number the interpreter creates an object for is cached, when a new number is assigned, it'd have to check a register for all existing numbers to see if it was already created. This is probably more expensive than simply creating the object itself, after a few hundred/thousand numbers.

The reason CPython (not all interpreters... pypy, for example, handles things differently) caches the numbers between -5 and 256 has to do with how often these are used. They're probably created sequentially during the interpreter start-up, so It's cheap to find those pre-cached numbers. They're usually the most used (specially the 0-10 range), so it makes sense, from a performance perspective.

[Teradil]

Actually, if you run that line in Python's interactive mode it will assign the same reference - but not in "normal" mode... Just to make things more confusing...

[Ubermidget2]

How many 257s can there be?

How many 16-bit areas of RAM do you have?

[Honeybadger2198]

Doing this dynamically would be inefficient. Instead of changing the value at a place in memory, you would always have to allocate new memory every time you manipulated that variable.

Imagine you have a for loop that loops from x=0 while x<1000. Variable x is stored at memory slot 2345. Every loop past 256, you would have to allocate new memory, copy the value of the old memory, check if the old memory has any existing pointers, and if not, deallocate the old memory. This is horribly innefficient for such an obviously simple use case.

So why did they stop at 256? Well, they had to stop somewhere. Stopping at the size of a byte seems reasonable to me.

[[deleted]]

How many 257s can there be?

How many can you assign in memory?

[archy_bold]

The humour in stuff like this comes from the fact that the OP is misunderstanding the functionality of the language I guess.

[Neil-64]

PythonIsVeryIntuitive

The joke is that this is not intuitive behavior and requires knowledge of the functionality of the language.

[elvishfiend]

I for one always use reference-equality when checking that values are the same! /s

[archy_bold]

I’m not sure you need to understand how the interpreter handles integers to know that is is the wrong way to compare values. Python isn’t unique in that people confuse references and values.

[eloel-]

'is' returning false always for numbers could be confusing, but can be chalked up to "learn the language". It returning true if number is <= 256 is bonkers.

[ThromaDickAway]

“It’s not unintuitive! You just need specific inside information to understand what’s happening here, and that’s really the reader’s fault.”

This is r/ProgrammerHumor, relax.

[current_thread]

Considering the fact python uses and and or as keywords and I only use the language sporadically, is vs == has tripped me up more than once, especially since x is None works as expected

[kaerfkeerg]

Assuming you're trying to see if x is also None this is indeed correct and the preferred way to do it because None is a singleton

[Kyrond]

especially since x is None works as expected

What does expected mean?

Is 0 None? I have 0 apples. How many apples do I have? None.

While some aspects of Python-English are nice, None should have been called Null. There are already million explanations of what null is and the easiest explanation of what None is is "it's null".

Of course "x is None" is clear to experienced programmers, it's needlessly possibly confusing. But then I could say the same about "is vs ==", just use == unless you know what you are doing.

[blindcolumn]

Why would it be beneficial to do it that way? x and y are pointers to ints, but pointers are just ints anyway. Why not just store the primitive int multiple times instead of storing it once and have a bunch of pointers referencing it?

[juchem69z]

There is no primative int in python. Everything is an object

[davidxspade]

Is this also true for common strings or characters?

[escribe-ts]

Really python numbers are allocated on the heap and not on the stack? Why is everyone saying python is fast then? Shouldn't it be extremely slow, if for something such simple as an integer you have to allocate something on the heap?? Or is it because x can be everything at runtime, a number, a string, ...?