5 ms·

Haha these aren't even wtfs! the id changes or not? oh noooo, people use the id() function so much, I've literally seen it 0 times ever in production code. T

Haha these aren't even wtfs! the id changes or not? oh noooo, people use the id() function so much, I've literally seen it 0 times ever in production code. This is nothing like the JS wtfs where there is no way to predict what it will do, and it violates it's own patterns. edit: to be more clear, I have run into a lot of JS wtf's trying to write code for work. you just run into bugs all the time where JS doesn't do anything like what would be the obvious thing to do, or the thing that works 99.99% of the time fails depending on the value of the string being 'magic'. with Python I rarely if ever learn some bizarre arcane thing accidentally because it almost always behaves as expected. If you think there's an equivalence here you are just a JS fanboy, JS was a language that evolved largely because of hacks vendors put in and those insane hacks got standardized because it was too late, despite being insane. Python was specifically and carefully designed to minimize unexpected behavior.

andy_ppp 1y ago
I think they are pretty bad tbh apart from the ID one. Everyone knows about the JS quirks so I think it’s good to know sometimes equality in Python strings can behave extremely strangely and the other issues mentioned. Why does it have to be defended “my language is better than your language”? However I’d like to say Elixir is near perfect, thanks :-)
- ltbarcly3 1y ago
  No you misread it, equality for python strings works exactly the way you expect. the id() value (which is basically the memory address) might not change if you concatenate strings, but literally nobody ever uses id for anything ever. You would use hash() which does change appropriately. edit: 'wtf!' is always equal to itself. Maybe you are thinking of `is`, which just compares the value of id(). `is` can't be used for comparisons, saying it's a WTF is just being unfamiliar with basics. `is` is not used for equality comparisons. This is how more or less every language works, comparing pointers is not the same as comparing strings in C/rust/etc. Comparing object identity is not the same as testing equality in Java.
  - andy_ppp 1y ago
    I think honestly it is you who misread my comment... I was saying the id() issue isn't a real problem, the weirdness around "wtf!" not being equal to itself under some circumstances is very confusing. Seems Google Colab isn't loading here.
    - ziml77 1y ago
      But "is" doesn't check equality. It checks reference equality. Maybe the real wtf here is they made that check a temptingly short infix operator rather than a function named reference_equals().
    - zahlman 1y ago
      "wtf!" is consistently equal to itself in Python. The fact that you could have separate string objects both representing that text, is entirely orthogonal to that.
    - Jtsummers 1y ago
      `is` is more like doing this in C: char* s1 = "wtf!"; char* s2 = "wtf!"; if (s1 == s2) { ... } They may or may not be stored in the same place depending on your compiler (clang and gcc yes, msvc no, at least with just a quick default build). If you actually want to do an equality check, you need to use `==` (in Python) which would be like using `strcmp` in C. > "wtf!" not being equal to itself It is equal to itself, but multiple variables referencing that string may not hold references to the same (literal, in memory) string.
mvanbaak 1y ago
I totally agree with you. I have seen a lot of code, but the id() function has never been used in production code
deleted 1y ago
[deleted]
w4yai 1y ago
And now you're using pretty much the same rhetoric than JS guys when facing to wtfjs.
- ltbarcly3 1y ago
  No, I don't think so. The JS wtf's actually make you gasp. These are so obscure and boring. F'ing JS equality isn't transitive for builtin types.
- BobbyTables2 1y ago
  Even normal JS is WTF-worthy… Allowing out of bound array indexing and operations using “undefined” seems pretty crazy to me.
  - jacquesm 1y ago
    For the former: technically they are about as undefined as they could be on read. On write, it's a different matter (you could decide to resize the array under the hood). Even so, I think arrays with a particular size always were simply an illustration that there is a point where you have to allocate a physical resource to something entirely imaginary and that's where infinite bounds are no longer acceptable. In the 80's that was '256', in the 90's '65535', nowadays it is more like '4G' but no matter how far we advance there are still hard limits. And on the wire it gets even more constrained.
craftkiller 1y ago
I think this one is good: False == False in [False] # Outputs True It doesn't make sense no matter which way you evaluate it. Equality first: False == False # True True in [False] # False or `in` first: False in [False] # True False == True # False
- ltbarcly3 1y ago
  Ok I'll admit this is a real WTF
  - Upvoter33 1y ago
    chained comparisons are weird and counter-intuitive, sometimes
    - quuxplusone 1y ago
      Python is my second language (after C++) and for me the surprising thing here is not "chained comparisons are weird" but rather "`in` is a comparison operator." So for example `1 in [1,2] in [[1,2],[3,4]]` is True... but off the top of my head I don't see any legitimate use-case for that facility. Intuitively, I'd think a "comparison operator" should be homogeneous — should take the same type on LHS and RHS. So, like, "is-subset-of" could sanely be a comparison operator, but `in` can't be.
      - zahlman 1y ago
        >and for me the surprising thing here is not "chained comparisons are weird" but rather "`in` is a comparison operator." Python documentation calls it a "comparison operator" (https://docs.python.org/3/reference/expressions.html#comparisons https://docs.python.org/3/reference/expressions.html#compari...) but a broader, better term is "relational operator". It expresses a possible relationship between two arguments, and evaluates whether those arguments have that relationship. In this case, "containment" (which intuitively encompasses set membership and substrings). A finer distinction could have been made, arguably, but it's far too late to change now. (And everyone is traumatized by the 2->3 transition.)
kgm 1y ago
I have used id() in production code, but the circumstances were extremely specific: It was in some monitoring-related code that was trying to dig down into the guts of the interpreter for the purposes of tracking memory usage on the level of individual pages. It was a whole thing. Which is to say: Users of Python almost certainly don't want to call id(), unless they are mucking around with something related to the functioning of the interpreter itself. The only other circumstance in which I've used it in anything like real code was in a quick hack where what I really wanted was to put a bunch of dicts in a set, but you can't do that, so I made a set of their IDs instead (but this wasn't in what I would call "production code"). In general, most of the "wtfs" listed here are pretty banal. If you're using `is` on immutable objects, you're basically just asking for trouble. The functioning of string and integer interning and constant folding are implementation curiosities, and if you ever write code in which such differences matter, then you have made an error.
jtolmar 1y ago
I don't think either reach the real wtfs of their language. id() does some weird things with string interring, javascript coerces cross-type arithmetic into weird nonsense instead of throwing a type error. Whatever, neither of these come up in the real world. Builds so messy that you need to resort to venv, every second DOM API being someFunc(thirdMostImportantArgument, { mostImportantArgument: val }), these are the real wtfs.
- zahlman 1y ago
  Yes, but those are definitionally library and ecosystem wtfs, rather than language ones.
zahlman 1y ago
Like I've been saying in other recent submissions, since there seems to be a trend for similar discussion: in Python you find WTFs by trying to probe how Python works, pushing deliberately over-flexibly customization hooks to their limits, etc. In JS you find them by merely trying to call builtins with dodgy inputs.
Shacklz 1y ago
> I have run into a lot of JS wtf's trying to write code for work JS certainly does have plenty of wtfs but honestly, when sticking to somewhat modern JS, it's not so bad anymore these days. Function-scoping-shenanigans can mostly be circumvented by simply sticking to const/let, use a 3rd-party-library like date-fns instead of the dumpsterfire that is native Date and you're almost there - throw typescript into the mix and I have a very hard time imagining running into the meme-worthy JS-warts on a daily basis.

andy_ppp 1y ago

I think they are pretty bad tbh apart from the ID one. Everyone knows about the JS quirks so I think it’s good to know sometimes equality in Python strings can behave extremely strangely and the other issues mentioned. Why does it have to be defended “my language is better than your language”? However I’d like to say Elixir is near perfect, thanks :-)

ltbarcly3 1y ago
No you misread it, equality for python strings works exactly the way you expect. the id() value (which is basically the memory address) might not change if you concatenate strings, but literally nobody ever uses id for anything ever. You would use hash() which does change appropriately. edit: 'wtf!' is always equal to itself. Maybe you are thinking of `is`, which just compares the value of id(). `is` can't be used for comparisons, saying it's a WTF is just being unfamiliar with basics. `is` is not used for equality comparisons. This is how more or less every language works, comparing pointers is not the same as comparing strings in C/rust/etc. Comparing object identity is not the same as testing equality in Java.
- andy_ppp 1y ago
  I think honestly it is you who misread my comment... I was saying the id() issue isn't a real problem, the weirdness around "wtf!" not being equal to itself under some circumstances is very confusing. Seems Google Colab isn't loading here.
  - ziml77 1y ago
    But "is" doesn't check equality. It checks reference equality. Maybe the real wtf here is they made that check a temptingly short infix operator rather than a function named reference_equals().
  - zahlman 1y ago
    "wtf!" is consistently equal to itself in Python. The fact that you could have separate string objects both representing that text, is entirely orthogonal to that.
  - Jtsummers 1y ago
    `is` is more like doing this in C: char* s1 = "wtf!"; char* s2 = "wtf!"; if (s1 == s2) { ... } They may or may not be stored in the same place depending on your compiler (clang and gcc yes, msvc no, at least with just a quick default build). If you actually want to do an equality check, you need to use `==` (in Python) which would be like using `strcmp` in C. > "wtf!" not being equal to itself It is equal to itself, but multiple variables referencing that string may not hold references to the same (literal, in memory) string.

mvanbaak 1y ago

I totally agree with you. I have seen a lot of code, but the id() function has never been used in production code

deleted 1y ago

[deleted]

w4yai 1y ago

And now you're using pretty much the same rhetoric than JS guys when facing to wtfjs.

ltbarcly3 1y ago
No, I don't think so. The JS wtf's actually make you gasp. These are so obscure and boring. F'ing JS equality isn't transitive for builtin types.
BobbyTables2 1y ago
Even normal JS is WTF-worthy… Allowing out of bound array indexing and operations using “undefined” seems pretty crazy to me.
- jacquesm 1y ago
  For the former: technically they are about as undefined as they could be on read. On write, it's a different matter (you could decide to resize the array under the hood). Even so, I think arrays with a particular size always were simply an illustration that there is a point where you have to allocate a physical resource to something entirely imaginary and that's where infinite bounds are no longer acceptable. In the 80's that was '256', in the 90's '65535', nowadays it is more like '4G' but no matter how far we advance there are still hard limits. And on the wire it gets even more constrained.

craftkiller 1y ago

I think this one is good: False == False in [False] # Outputs True It doesn't make sense no matter which way you evaluate it. Equality first: False == False # True True in [False] # False or `in` first: False in [False] # True False == True # False

ltbarcly3 1y ago
Ok I'll admit this is a real WTF
- Upvoter33 1y ago
  chained comparisons are weird and counter-intuitive, sometimes
  - quuxplusone 1y ago
    Python is my second language (after C++) and for me the surprising thing here is not "chained comparisons are weird" but rather "`in` is a comparison operator." So for example `1 in [1,2] in [[1,2],[3,4]]` is True... but off the top of my head I don't see any legitimate use-case for that facility. Intuitively, I'd think a "comparison operator" should be homogeneous — should take the same type on LHS and RHS. So, like, "is-subset-of" could sanely be a comparison operator, but `in` can't be.
    - zahlman 1y ago
      >and for me the surprising thing here is not "chained comparisons are weird" but rather "`in` is a comparison operator." Python documentation calls it a "comparison operator" (https://docs.python.org/3/reference/expressions.html#comparisons https://docs.python.org/3/reference/expressions.html#compari...) but a broader, better term is "relational operator". It expresses a possible relationship between two arguments, and evaluates whether those arguments have that relationship. In this case, "containment" (which intuitively encompasses set membership and substrings). A finer distinction could have been made, arguably, but it's far too late to change now. (And everyone is traumatized by the 2->3 transition.)

kgm 1y ago

I have used id() in production code, but the circumstances were extremely specific: It was in some monitoring-related code that was trying to dig down into the guts of the interpreter for the purposes of tracking memory usage on the level of individual pages. It was a whole thing. Which is to say: Users of Python almost certainly don't want to call id(), unless they are mucking around with something related to the functioning of the interpreter itself. The only other circumstance in which I've used it in anything like real code was in a quick hack where what I really wanted was to put a bunch of dicts in a set, but you can't do that, so I made a set of their IDs instead (but this wasn't in what I would call "production code"). In general, most of the "wtfs" listed here are pretty banal. If you're using `is` on immutable objects, you're basically just asking for trouble. The functioning of string and integer interning and constant folding are implementation curiosities, and if you ever write code in which such differences matter, then you have made an error.

jtolmar 1y ago

I don't think either reach the real wtfs of their language. id() does some weird things with string interring, javascript coerces cross-type arithmetic into weird nonsense instead of throwing a type error. Whatever, neither of these come up in the real world. Builds so messy that you need to resort to venv, every second DOM API being someFunc(thirdMostImportantArgument, { mostImportantArgument: val }), these are the real wtfs.

zahlman 1y ago
Yes, but those are definitionally library and ecosystem wtfs, rather than language ones.

zahlman 1y ago

Like I've been saying in other recent submissions, since there seems to be a trend for similar discussion: in Python you find WTFs by trying to probe how Python works, pushing deliberately over-flexibly customization hooks to their limits, etc. In JS you find them by merely trying to call builtins with dodgy inputs.

Shacklz 1y ago

> I have run into a lot of JS wtf's trying to write code for work JS certainly does have plenty of wtfs but honestly, when sticking to somewhat modern JS, it's not so bad anymore these days. Function-scoping-shenanigans can mostly be circumvented by simply sticking to const/let, use a 3rd-party-library like date-fns instead of the dumpsterfire that is native Date and you're almost there - throw typescript into the mix and I have a very hard time imagining running into the meme-worthy JS-warts on a daily basis.