6 ms·

Aggressive type coercions in js frequently comes up 16 == [16] true in js false in python

egeozcan 5y ago
>>> 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).
- adsharma 5y ago
  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.
  - h8hawk 5y ago
    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.
- el_oni 5y ago
  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
  - amitport 5y ago
    Of course there is some internal logic. The point was that both languages have pitfalls.
    - h8hawk 5y ago
      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.
      - amitport 5y ago
        "-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)
        h8hawk 5y ago
        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.
        deleted 5y ago
        [deleted]
        amitport 5y ago
        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.
  - egeozcan 5y ago
    jsc >> 16 === [16] false
iaml 5y ago
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 https://eslint.org/docs/rules/eqeqeq

>>> 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).

adsharma 5y ago
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.
- h8hawk 5y ago
  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.
el_oni 5y ago
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
- amitport 5y ago
  Of course there is some internal logic. The point was that both languages have pitfalls.
  - h8hawk 5y ago
    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.
    - amitport 5y ago
      "-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)
      - h8hawk 5y ago
        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.
        deleted 5y ago
        [deleted]
        amitport 5y ago
        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.
- egeozcan 5y ago
  jsc >> 16 === [16] false

iaml 5y ago

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 https://eslint.org/docs/rules/eqeqeq