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

81–90 of 150 posts

Re: Weird Python Integers

#81

Post by rcthompson »

bobbyi_settv wrote: post #54
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?

A lot of code relies on the fact that "is" is very fast because it just compares memory addresses. In order for it to give a warning when it is used on integers, it would need to also look at the types of the objects which would have have some performance impact. No, it is not good practice to rely on the interning of ints and short strings. It's implementation-specific behavior and relying on it can cause your code…

I guess with MyPy type annotations, you could issue a warning when types are checked if the code is using "is" on types where doing so is implementation-defined and unlikely to produce a useful result.

Re: Weird Python Integers

#82

Post by bobbyi_settv »

rcthompson wrote: post #81
bobbyi_settv wrote: post #54

Earlier quoted context omitted.

A lot of code relies on the fact that "is" is very fast because it just compares memory addresses. In order for it to give a warning when it is used on integers, it would need to also look at the types of the objects which would have have some performance impact. No, it is not good practice to rely on the interning of ints and short strings. It's implementation-specific behavior and relying on it can cause your code…

I guess with MyPy type annotations, you could issue a warning when types are checked if the code is using "is" on types where doing so is implementation-defined and unlikely to produce a useful result.

I hadn't thought of that sort of static analysis. I would guess that the most common variation of using "is" on integers is comparing to a literal ("if x is 3"), so conceivably the bytecode compiler could warn about that without even needing annotations.

Re: Weird Python Integers

#83

Post by alphaalpha101 »

andrewjw wrote: post #46
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…

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.

Re: Weird Python Integers

#84

Post by deathanatos »

chrisseaton wrote: post #62
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…

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.

Comparison by value tends to be more useful, and more often what a user expects "==" to mean. In some ways, "==" mirrors the mathematical =. (Not exactly, of course, since mathematics is usually making statements of fact: x = 2 means x is equal to 2, not x is assigned the value 2.)

I think Python is a good example here, where referential comparison is the `is` operator: `a is b`.

Re: Weird Python Integers

#86

Post by hobolord »

rosstex wrote: post #32
adtac wrote: post #24

https://github.com/adtac/exterminate Plugging my near useless Python library that does this and a lot of other subtle, annoying things to break programs. The library is essentially a display of how much Python actually exposes to the user and how modifiable it is.

Why does my inner self find it immensely fun to modify programs in subtle ways to watch how they break? Considering there's infinite ways to write junk code, and far fewer ways to make it work.

It's probably what got me interested in programming in the first place. Writing C code and learning about pointers to memory, and playing around with memory locations to see undefined behavior could be invoked

Re: Weird Python Integers

#87

Post by hyperpape »

chrisseaton wrote: post #62
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…

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.

Re: Weird Python Integers

#88

Post by sevensor »

santiagobasulto wrote: post #48
sevensor wrote: post #29

Earlier quoted context omitted.

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.

Fair point -- == versus "is" is a pretty subtle distinction and best avoided by novices.

Re: Weird Python Integers

#89

Post by exikyut »

KekDemaga wrote: post #58
vog wrote: post #35

Earlier quoted context omitted.

Wow, the alternative print is extra evil ... >>> from exterminate import AltPrint >>> print("Hey! How are you?") Yo dawwwwg! Wuz crackalackin' yo? ... because that string is not calculated locally, but retrieved via HTTP from an API call. So everything you print is sent to an external server. AltPrint calls Gizoogle.translate(): https://github.com/adtac/exterminate/blob/f18862ed5b2e143e18... And Gizoogle.translate()…

print("'; drop table users")

http://imgur.com/a/no9eB

Re: Weird Python Integers

#90

Post by emmelaich »

alephnil wrote: post #74
mastax wrote: post #66

Earlier quoted context omitted.

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 memo…

Yeah, a "fun" thing to do was to change the value of built-in constants such as pi.
Post reply on HN