Hacker News Reader

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

Ok I'll admit this is a real WTF

chained comparisons are weird and counter-intuitive, sometimes

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.

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

Ah, `in` for strings satisfies my intuition re homogeneity. So I guess that makes sense enough (although if I ran the zoo I wouldn't have done it!). Thanks!

Yeah, having the expansion rule operate on operators that are clearly not transitive serves no purpose (1 < 2 < 3 is at least a math notation)

Its apparently trying to allow x < y < z be a legal statement, meaning that we get:

False == False and False in [False] is a expansion of that statement, just like x < y and y < z is the expansion of x < y < z

Oh yeah, that's a great one, there must be a compounded boolean expression logic escaping us

I'll add:

    >>> False == False in [True]
    False
    >>> True == True in [True]
    True

ps: some ast poking

    >>> ast.show(ast.parse("False == False in [False]"))
    Module(
      body=[
 Expr(
   value=Compare(
     left=Constant(value=False),
     ops=[
       Eq(),
       In()],
     comparators=[
       Constant(value=False),
       List(
  elts=[
    Constant(value=False)],
  ctx=Load())]))])

    >>> ast.show(ast.parse("(False == False) in [False]"))
    Module(
      body=[
 Expr(
   value=Compare(
     left=Compare(
       left=Constant(value=False),
       ops=[
  Eq()],
       comparators=[
  Constant(value=False)]),
     ops=[
       In()],
     comparators=[
       List(
  elts=[
    Constant(value=False)],
  ctx=Load())]))])

note the first tree as one Comparator node with multiple ops, time to read the spec to know how these are evaluated

The document explains it. When dealing with these comparators, when chained they get separated and you have the equivalent of this:

  False == False in [True]
  =>
  (False == False) and (False in [True])

If you put it into a function like this:

  def foo(): return False == False in [True]

And then disassemble it you'll get this byte code (3.13, may vary by version):

  RESUME                   0
     LOAD_CONST               1 (False)
     LOAD_CONST               1 (False)
     SWAP                     2
     COPY                     2
     COMPARE_OP              72 (==)
     COPY                     1
     TO_BOOL
     POP_JUMP_IF_FALSE        5 (to L1)
     POP_TOP
     LOAD_CONST               2 ((True,))
     CONTAINS_OP              0
     RETURN_VALUE
  L1:     SWAP                     2
     POP_TOP
     RETURN_VALUE

There is no literal `and` operation occurring here, instead it first does the `False == False`, then jumps if false or continues to the second comparison.

For the literals we've given it, it'll go on to the second comparison which will result in false since `False` is not in `(True,)`.

EDIT: And here's the non-chained version disassembled:

  def bar(): return (False == False) in [True]

     RESUME                   0
     LOAD_CONST               1 (False)
     LOAD_CONST               1 (False)
     COMPARE_OP              72 (==)
     LOAD_CONST               2 ((False,))
     CONTAINS_OP              0
     RETURN_VALUE

Thanks a lot, brilliant

    return False == False in [False]

is roughly

    a = False
    b = False
    c = [False]
    (a == b) and (b in c)

is less roughly

    a = False
    b = False
    if not (a == b):
       # short circuits https://news.ycombinator.com/item?id=44619401
       return False 

    c = [False]
    if not (b in c):
       return False

    return True

> It doesn't make sense no matter which way you evaluate it

It makes sense when you evaluate it the way it's intended to be understood (https://stackoverflow.com/questions/6074018). There are other languages that do this, and it was consciously designed to work this way. The idea that you should have to evaluate one of the operators "first" may make sense to someone trying to implement a parser with techniques from the 70s, but for languages like Python, the design is clearly more about what makes sense for the code author.

Arguably it's surprising that `in` is treated as on par with `==`. But on the other hand, even someone trying to implement a parser with techniques from the 70s would have to admit that both are "relational operators".

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.

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

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.

Yes, but those are definitionally library and ecosystem wtfs, rather than language ones.

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

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

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.

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.

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

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

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

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.

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

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.

Even normal JS is WTF-worthy…

Allowing out of bound array indexing and operations using “undefined” seems pretty crazy to me.

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.