Hacker News Reader

> the symbol it is using is overloaded with binary comparison operator, so the people will be confused

I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.

Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.

> should that math equivalence hold for programming though?

It's not a hard rule that overrides all other considerations, but I do think Python's choice to follow math is the right decision here.

I'd claim if you teach someone `<` then show them `5 < x < 10` for the first time, they're far more likely to go with the math interpretation than the C one. That is, beyond the fact that someone's familiarity with math reinforces this intepretation, the reason for math using this interpretation in the first place is because it aligns with intuition.

It's also just pretty useful. It's common to want to check if a number is between some bounds, like `0 <= i < len`, or that multiple things are equal. In cases where you really do want the C behavior, I'd say you should already write that as `(x == y) == z` for clarity anyway, regardless of whether the language lacks chaining and thus lets you omit the parentheses.

Maybe = should actually be := which it is in some languages?

x = x + 1 sounds wrong if you are in math mode

x := x + 1 is uncommon in math and you can take it to mean "set x to whatever is currently x, plus one"

But it's also true that you need to be able to accept certain conventions when changing fields.

> it's not clear how short circuiting works

It is clear if you read the docs.

https://docs.python.org/3/reference/expressions.html#compari...

https://docs.python.org/3/reference/expressions.html#boolean...

It's a completely useless question - it's language trivia. It's like asking "what happens if you do X in database Y version Z and up". Who cares? It's something you figure out when you get there. There are tons of examples of something like this where it's language-dependent, so don't even bother memorizing this stuff.

I once passed an interview where it was all just Spring documentation questions. I had never built a Spring app in my life, I just "read the docs" five times.

Is “let me check the docs” an appropriate thing to say in an interview setting?

It’s what you’d do on the job, right? A place which dings you for checking your work is broken.

I’d expect a raised eyebrow if it was some very basic question about something you’ve claimed to be an expert in but given how many, many bugs over the years stem back to confusion about order of evaluation I would consider it a minor plus if someone said “I think I know but I want be certain”, and a major one if they paired that with mention of defensive coding practices like adding tests covering cases where it’d matter and structuring the code so there are no side effects hidden in the test (e.g. the code as written is fine but if it was f1() == f2() == f3() I’d probably write it as a clearer multi-line if block when there are side effects to those calls to make obvious when I’m intentionally not doing them in every case).

I'd prefer a candidate to check the docs or look something up if they were unsure, because that would also provide useful information to me as an interviewer.

Although I'd also want that benefit of the doubt for myself. I'm quite familiar with how Ruby handles collections, for example, but if I tried to use `slices.Collect` in Go the same way as `Enumerable#collect` in Ruby I'd end up stuck and would need clarification.

Yes.

Extra points if you are familiar enough with the documentation to find the answer quickly.

yes.

It absolutely is.

Agree, also by reasoning from basic principles adding extra brackets ( ) should not change the output result - at least this is what our brain is programmed to believe, but in the case of chained operations it will.

Example

(a==b)==c would be different from a==b==c

>> but there are heavy downsides. For example, it's not clear how short circuiting works.

Opinion: Code that depends on side effects like that in a conditional is BAD. It is not an optimization, it's an obfuscation.