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

111–120 of 150 posts

Re: Weird Python Integers

#111

Post by zeptomu »

thaumasiotes wrote: post #94
zeptomu wrote: post #78

Earlier quoted context omitted.

Yeah, well you know, that's just like your opinion, man.

On the off-chance that you're serious, I'll point out that there is no way to compare equal by identity without also comparing equal by value.

Can you elaborate on this?

  Integer a = new Integer(2);
  Integer b = a;
Here a == b and no comparison by value.

  Integer c = new Integer(2);
Then a != c but a.equals(c) (in Java). My point is that I do not agree with that and would like to have a == c, which would be the case if '==' was implemented using comparison by value.

Re: Weird Python Integers

#112

Post by DonHopkins »

logicchains wrote: post #110
DonHopkins wrote: post #106

"Is", "is." "is"—the idiocy of the word haunts me. If it were abolished, human thought might begin to make sense. I don't know what anything "is"; I only know how it seems to me at this moment. — Robert Anton Wilson, The Historical Illuminatus Chronicles, as spoken by Sigismundo Celine. https://en.wikipedia.org/wiki/E-Prime Kellogg and Bourland describe misuse of the verb to be as creating a "deity mode of speech", a…

This is part of the reason why I prefer structural types (like in Typescript, Go and OCaml) over nominal types (like in most languages), as any object with the required methods is automatically an instance of such a type, instead of having to explicitly declare that it "is"/"extends"/"implements" that type. I suspect that with dependent types, nominal types are actually a degenerate type of dependent structural type:…

Which is a great approach if you're slinging JSON between different languages and implementations.

Python is fine with duck typing.

Re: Weird Python Integers

#113

Post by Sean1708 »

thaumasiotes wrote: post #94
zeptomu wrote: post #78

Earlier quoted context omitted.

Yeah, well you know, that's just like your opinion, man.

On the off-chance that you're serious, I'll point out that there is no way to compare equal by identity without also comparing equal by value.

I don't know Java so I may have missed something, but isn't this[0] a counter-example?

[0]: https://ideone.com/w8NhmR

Re: Weird Python Integers

#114

Post by logicchains »

DonHopkins wrote: post #112
logicchains wrote: post #110

Earlier quoted context omitted.

This is part of the reason why I prefer structural types (like in Typescript, Go and OCaml) over nominal types (like in most languages), as any object with the required methods is automatically an instance of such a type, instead of having to explicitly declare that it "is"/"extends"/"implements" that type. I suspect that with dependent types, nominal types are actually a degenerate type of dependent structural type:…

Which is a great approach if you're slinging JSON between different languages and implementations. Python is fine with duck typing.

It's also really good for testing: if you want to mock some opaque third-party object, you can just create an interface with the same methods as that object and use it in your code. Nominal types often don't allow this, such as how in Java you can't make a class to which you don't have the source implement your own interface, or make it painful, like orphan instance restrictions in Rust and Haskell.

Re: Weird Python Integers

#115

Post by LgWoodenBadger »

zeptomu wrote: post #111
thaumasiotes wrote: post #94

Earlier quoted context omitted.

On the off-chance that you're serious, I'll point out that there is no way to compare equal by identity without also comparing equal by value.

Can you elaborate on this? Integer a = new Integer(2); Integer b = a; Here a == b and no comparison by value. Integer c = new Integer(2); Then a != c but a.equals(c) (in Java). My point is that I do not agree with that and would like to have a == c, which would be the case if '==' was implemented using comparison by value.

It's a technical/pedantic point, but

a == b is an value-comparison of the identity "value" (in Java it's the memory reference).

Or in other words, how do I know two references are equal (identity equal) without comparing the values of the references?

Logical equality devolves to the same thing at the end.

Re: Weird Python Integers

#116

Post by pythonaut_16 »

chrisseaton wrote: post #13
throwaway613834 wrote: post #11

Does anyone know why Python refcounts everything -- even small integers, True, False, None...? Why not avoid it?

I don't know the internals of Python, but maybe checking if you need to refcount something is basically takes as long as actually just going ahead and doing it all the time anyway.

That's also the same thought behind the Python practice of "it's better to ask forgiveness than permission".

If you're going to have a conditional that will evaluate to True most of the time, sometimes (in Python) it's considered better to just go ahead and try the logic that the conditional is guarding, and then catch the exception and handle it if it happens.

Re: Weird Python Integers

#117

Post by dsfyu404ed »

jwilk wrote: post #38
dsfyu404ed wrote: post #22

Yup, 0day hunters have fun with this behavior from time to time.

Why is it interesting for "0day hunters" in particular?

If you can write to memory in a way that overwrites integer values the whole logic of a program falls apart. Imagine if an adversary could affect the result of everything you do with integers.

It's not necessarily a common thing. Most people aren't running python directly on the internet but being able to screw around with stuff like this is just another important tool in the toolbox when you're attacking something.

Re: Weird Python Integers

#118

Post by ygra »

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.

That's the basic idea behind mutation testing which can turn the aim of 100 % code coverage up to 11. You introduce random mutations into the code and if a mutation does not cause at least one test to fail then either your tests aren't covering enough, or that expression/statement was unnecessary for correct program behaviour. Never got a chance to actually try it out, though.

Re: Weird Python Integers

#119

Post by audiometry »

squeaky-clean wrote: post #79
audiometry wrote: post #75

Earlier quoted context omitted.

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…

thanks. that makes good sense.

Re: Weird Python Integers

#120

Post by Dylan16807 »

nneonneo wrote: post #53
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 would be due to string interning , which automatically caches small strings, which are very common because attribute names are just strings.

To be clear the question of which strings to intern is up to an implementation of string interning. Only small strings, all strings, or even only large strings are all options that are good for different reasons.
Post reply on HN