8 ms·
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 v
by std_throwaway 9y ago
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.
- cma 9y agoMicropython does a much better job, using pointer alignment guarantees to pack in small integers: https://micropython.org/ https://micropython.org/ Apparently it is too hard to move python proper over to that method because of backwards compatibility issues with C extensions.
- zde 9y agoGuido 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.
- concede_pluto 9y agoIt'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.
- andars 9y agoCould 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
- mastax 9y agoI 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.
- andars 9y agoBy manually moving the constants from .const to .data, I got this program: program main integer m,n call corrupt(7) write (*,*), 7 stop end program main subroutine corrupt (a) integer a a = 4 return end to output 4. Thanks for pointing this out, 'concede_pluto. Pretty weird!
- alephnil 9y agoAll 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.
- emmelaich 9y agoYeah, a "fun" thing to do was to change the value of built-in constants such as pi.
- DonHopkins 9y agoThat feature was required by the Indiana General Assembly. https://en.wikipedia.org/wiki/Indiana_Pi_Bill https://en.wikipedia.org/wiki/Indiana_Pi_Bill
- 9y ago
- leipert 9y agoThe same is true for Java apparently: https://stackoverflow.com/a/2001861 https://stackoverflow.com/a/2001861
- chrisseaton 9y agoThat'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`.
- zeptomu 9y agoAlthough 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, symmetry and transivity), where a user can expect an actual value comparison - AFAIK one is advised to overwrite `equals` in e.g. Java, but I do not think this is good design. //edit: There is no obvious answer, as one could argue, that languages just use different names for the same concepts ('==' vs 'equals') and consider comparison by value or by reference more fundamental (and choose '==' for that).
- chrisseaton 9y agoWhy 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.
- zeptomu 9y agoI agree, that's why I revised my answer (see edit). Probably comparison by-value is more useful in higher-level and comparison by reference in lower-level languages.
- 9y ago
- joncrane 9y agoThe real ProTip is in the comments. :)
- eighthnate 9y agoI believe that's called "interning". It's done for strings as well.