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

71–80 of 150 posts

Re: Weird Python Integers

#71

Post by cpsempek »

jedberg wrote: post #36

In [7]: a = "foo" In [8]: b = "foo" In [9]: a is b Out[9]: True In [10]: b = "foobaljlajdfsklfjds l;kjsl;dfj ls;dfj l;skdj flsdjluejsklnm " In [11]: a = "foobaljlajdfsklfjds l;kjsl;dfj ls;dfj l;skdj flsdjluejsklnm " In [12]: a is b Out[12]: False Seems to work with small and big strings too.

This comment is great, points out why the article is bad. Python integers are not weird simply because a well-defined operator gives a result which goes against an intuition based on the semantics of English.

Re: Weird Python Integers

#72

Post by jonbarker »

Cool examples, but I'm not super concerned about the problems arising from the ability to 'use ctypes to directly edit memory'. It's actually pointers to memory blocks, not the memory contents itself: https://docs.python.org/3/library/ctypes.html If you're advanced enough to need to handle pointers to memory blocks in your python program, you are probably good enough to know not to create problems with the behavior of iterators on ranges.

Re: Weird Python Integers

#73

Post by Phrodo_00 »

boramalper wrote: post #21

> We can use the Python built-in function id which returns a value you can think of as a memory address to investigate. > [...] > It looks like there is a table of tiny integers and each integer is takes up 32 bytes. It is the memory address but it's a "CPython implementation detail: This [return value of the id() function] is the address of the object in memory."[1] Though you cannot use this to determine the size o…

I wouldn't say it's necessarily neither. While the concept of binding used in [3] is consistent, you can also simply say that functions are call-by-value and all values are references. Pretty much the same way C uses pointers when passed to a function.

BTW, I didn't like the way the difference between mutable and immutable objects was pointed out, it sounded like the language recognized and supported those two types, when in fact the difference is just in the methods exposed by the objects. Even immutable objects can be modified if you don't respect the contracts (like in the case of this article).

Re: Weird Python Integers

#74

Post by alephnil »

mastax wrote: post #66
andars wrote: post #56

Earlier quoted context omitted.

Could you be more specific? Fortran passes arguments by reference, but writing to an argument won't mess up the "program's only copy of 7". For example, the first output of the following program is 4, but the second is still 7. program main integer m,n m = 7 call corrupt(m) write (*,*) m n = 7 write (*,*) n stop end program main subroutine corrupt (a) integer a a = 4 return end

I think he means something like call corrupt(7) which causes a segfault for me. I suppose if you were using a compiler/platform that didn't store constants in read only memory, this might actually work.

All newer versions of Fortran will segfault, but back in the days they would not. Back in the ninties I fixed a bug we found when porting a Fortran 77 program from HPUX to Linux. The program would segfault on Linux, but worked on HPUX.

The reason was that in one subroutine, a parameter value was stored in a local variable, then used for computation and restored at the end. Since constants was stored in read only memory when using g77 on Linux, but not on the f77 compiler on HPUX, the Linux port would crash, but not the original HPUX version. In that the code you had above would have worked.

Re: Weird Python Integers

#75

Post by audiometry »

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…

So why is this happening? The blog post also shows it, but doesn't explain why (first example)

Re: Weird Python Integers

#76

Post by thaumasiotes »

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…

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.

Re: Weird Python Integers

#77

Post by [deleted] »

andars wrote: post #56
concede_pluto wrote: post #41

Earlier quoted context omitted.

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.

Could you be more specific? Fortran passes arguments by reference, but writing to an argument won't mess up the "program's only copy of 7". For example, the first output of the following program is 4, but the second is still 7. program main integer m,n m = 7 call corrupt(m) write (*,*) m n = 7 write (*,*) n stop end program main subroutine corrupt (a) integer a a = 4 return end

[deleted]

Re: Weird Python Integers

#78

Post by zeptomu »

thaumasiotes wrote: post #76
zeptomu wrote: post #59

Earlier quoted context omitted.

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…

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.

Re: Weird Python Integers

#79

Post by squeaky-clean »

audiometry wrote: post #75
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…

So why is this happening? The blog post also shows it, but doesn't explain why (first example)

std_throwaway got the reasoning right in higher comment. You're actually doing a comparison if the object references are identical, not if the values are identical.

The tricky bit is that everything is an object in Python, even "primitives" like integers, which can be surprising coming from some other languages. Then the trickier bit is that CPython (the most popular and standard implementation) on startup creates an object for every int from -5 to 256 and will re-use those instead of creating a new PyLongObject. This means that `256 is 256` works, because under the hood, it's short-circuting it to the same object. But `257 is 257` creates 2 different PyLongObjects, which have the same value, 257, but aren't technically the same object.

And in my above example, the reason `x = 257; x is 257` is True when on the same line, but False when on separate lines (in the REPL) is because of the reasons kmill says, the constants pool that the interpreter creates. If they're interpreted together, it will create and use the same constant.

Here is my entry on my company's blog about this. I won't guarantee you it's well written, but it does show bytecode and has links to the relevant C source lines at the very end.

https://www.everymundo.com/literals-other-number-oddities-py...

Post reply on HN