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

101–110 of 150 posts

Re: Weird Python Integers

#101

Post by lmm »

int_19h wrote: post #98
lmm wrote: post #97

Earlier quoted context omitted.

It's still confusing in Java because there are primitive types which == compares by value. Scala gets it right: == does the right thing and there's some operator I never use (I think it's "eq"?) if you really want reference comparison.

In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It'd be more obvious if Java required explicit dereferencing like C++ does, but it's still consistent. Just not convenient.

> In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references.

It's still confusing. Plenty of "reference types" behave like values in all obvious senses. Why should "foo" be a reference but 45L a value?

Re: Weird Python Integers

#102

Post by DonHopkins »

emmelaich wrote: post #90
alephnil wrote: post #74

Earlier quoted context omitted.

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.

That feature was required by the Indiana General Assembly.

https://en.wikipedia.org/wiki/Indiana_Pi_Bill

Re: Weird Python Integers

#104

Post by pjmlp »

lmm wrote: post #101
int_19h wrote: post #98

Earlier quoted context omitted.

In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It'd be more obvious if Java required explicit dereferencing like C++ does, but it's still consistent. Just not convenient.

> In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It's still confusing. Plenty of "reference types" behave like values in all obvious senses. Why should "foo" be a reference but 45L a value?

Because "foo" is an instance of String, aka subclass of Object, while 45L is a value for the primitive type long.

I fail to see the confusion, other than for newbies.

Re: Weird Python Integers

#105

Post by gvx »

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.

Except when that value is NaN.

Re: Weird Python Integers

#106

Post by DonHopkins »

"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", allowing "even the most ignorant to transform their opinions magically into god-like pronouncements on the nature of things".

Bourland and other advocates also suggest that use of E-Prime leads to a less dogmatic style of language that reduces the possibility of misunderstanding or conflict.

Alfred Korzybski justified the expression he coined — "the map is not the territory" — by saying that "the denial of identification (as in 'is not') has opposite neuro-linguistic effects on the brain from the assertion of identity (as in 'is')."

Re: Weird Python Integers

#107

Post by gvx »

yen223 wrote: post #44
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?

I'll take it one step further - I don't think I've ever used `is` for anything other than comparisons to `None`.

`is` is also useful for things like detecting cycles for walking object graphs.

But I'd estimate 99% of the times I've used `is` was for comparisons to `None`, and 90% of the rest of times for comparisons to other sentinel values.

Re: Weird Python Integers

#108

Post by simon_o »

pjmlp wrote: post #104
lmm wrote: post #101

Earlier quoted context omitted.

> In Java it's not confusing when you realize that == always compares values (i.e. things that can be stored in variables); it's just that for reference types, the values are references. It's still confusing. Plenty of "reference types" behave like values in all obvious senses. Why should "foo" be a reference but 45L a value?

Because "foo" is an instance of String, aka subclass of Object, while 45L is a value for the primitive type long. I fail to see the confusion, other than for newbies.

That's pretty much saying "it is the way it is", which

a) is not even true, see floating point numbers

and

b) will be obsolete with value types.

Needless to say, there is pointless confusion created by Java's design, and there are better approaches available.

All you have to do is to adapt the semantic model from reference equality vs. value equality to identity vs. equality.

Identity checks whether the "bits" are identical, irregardless of whether the bits are "references" or values, and equality is a user-defined operation.

    "Foo" equality "Foo" // True
    "Foo" identity "Foo" // Only true if they point to the same "object"
    123 equality 123 // True
    123 identity 123 // True
    Double.NaN equality Double.NaN // False
    Double.NaN identity Double.NaN // True
Which symbols you pick for "equality" and "identity" is largely arbitrary.

Re: Weird Python Integers

#109

Post by gvx »

throwaway613834 wrote: post #18
chrisseaton wrote: post #13

Earlier quoted context omitted.

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.

Yeah you might be right, it's hard to say. Generally I view writing as more expensive than reading so I don't know.

Note that it's not just write vs read, it's write vs read + branch.

Re: Weird Python Integers

#110

Post by logicchains »

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: a dependent pair of a type and a proof that a string 'name' field has some particular value, or that a list 'implements' field contains some particular string (the interface name).

Post reply on HN