Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Aggressive type coercions in js frequently comes up

  16 == [16]
true in js false in python


    >>> a = 5
    >>> b = 5
    >>> a is b
    True
    
    >>> a = -4
    >>> b = -4
    >>> a is b  
    True
    
    >>> a = 300
    >>> b = 300
    >>> a is b
    False
Every language has these, JS a bit more (because mostly impossible to fix thanks to backward compatibility). I don't understand why you would do that anyway.

Most linters would display errors even if you did (in both languages).


a==b would be true. The is operator is not the same as the equality operator

The is operator checks to see if both point to the same area in memory. Small numbers are preallocated in python so they point to the same memory.

>>>a=300

>>>b=a

>>>a is b

True


Of course there is some internal logic.

The point was that both languages have pitfalls.


In python it completely makes sense because it's an object oriented language and threat everything as object. In fact it's very consistent about that. Even classes are object and instance of metaclass. Difference between '==' and 'is' is came from that. This is not the case with Javascript. It's sad many peoples who are dealing with python don't understand that.


"-In python- it completely makes"

It is a pitfall. It's not about what python developers think about it. It is about what people from other languages experience when they learn the language.

(Though it's not my main point, I want to add as (also) a python developer, that I think this is a terrible design choice, which could easily be avoided. In this case python doesn't "threat everything as object" it treats small int literals differently than bigger int literals)


Small integeres are object in python. They are cached in some implemention. If you only care about shallow syntax, yes it's confusing. But if you care more about semantics, it's completely consistent and doesn't make especial case.


Many programmers do care about the "shallow" syntax.

Regardless, if, as you said, the operational semantics of the language is inconsistent among implementations and depends on internal caching, it only makes it worse.


jsc >> 16 === [16]

false


Great. Thank you. I'll remove the "is" operator from the supported subset and perhaps rewrite the commonly used "a is None" to idiomatic code in the target language.


You should always use 'is' with None. == Is operator that can be overloaded and 'is' is object identity comparison. It make sense when you understand object system. You will be terribly messed up when use some numpy array == None.


I really wish it didn't though. I started working with js ~5 years ago and haven't used == a single time, there are eslint rules that error on it[0] and you can reject push to repo if you have them, which many companies do. It's not a problem.

[0] https://eslint.org/docs/rules/eqeqeq




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: