201–209 of 209 posts
If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.
Earlier quoted context omitted.
Interviewer made a mistake and confused/sidetracked a candidate in a short interview.
If the interviewer is a good interviewer - they inadvertently gave the candidate an oportunity to demonstrate a range of skills. An outstanding candidate when questioned would mention that in most languages this evalates to that, but in python it evaluates to this, and offer an alternate method chaining and's on the spot in response to the confustion. If they are a bad interviewer - they would allow their ego to dera…
With my last job, I fumbled an easy question for me that I usually wouldn't, but it was a 10pm interview after I got up at 4am that morning and have almost fallen asleep when putting my kids to sleep at 9pm. I got the job (and then got promoted twice in 18 months), but if interviewer "inadvertently" confused me on top of my mental state, it might have been game over for me (and them, since I turned out to be an "outstanding" candidate).
Earlier quoted context omitted.
Interviewer made a mistake, stop rationalizing.
But is it "wrong" to make a mistake?
> The interviewer made no mistake though
So is it wrong to admit that you made a mistake? :)
And no, it's ok to make mistakes, but it is even better if we admit to them and learn from them (and the faster we do that, the better it is).
I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?
There are degrees of conciseness. I've seen real code that looks like if(bool_var == false) { other_bool_field = true; } else if(bool_var == true) { other_bool_field = false; } Which I suppose could be called anti-concise.
Earlier quoted context omitted.
on my phone and a bit discombobulated today, so we’ll see how i go with this > That still looks like something that a novice might trip over when reading this. my experience with “juniors” who start with python is that they think in lists and dictionaries. they don’t think in terms of set theory. that’s just the way python is taught. i would definitely set interview questions where a “decent” solution involves using…
".intersection()" takes any iterable, it can be: if set(args).intersection(["-h", "--help"]): Also python has had a special syntax for sets since 2.7 (I think), though I haven't seen it used very often: if {"-h", "--help"}.intersection(args):
Earlier quoted context omitted.
I don't see how you could interpret "a != b != c" as equivalent to "not (a == b == c)" in the first place. In the first expression a doesn't equal b and b doesn't equal c (no restriction on a and c). In the second expression you could have a == b, but b != c (and vice versa), clearly that's not equivalent to the first expression.
"a == b" is the same as "not (a != b)" Maybe I'm simple minded though.
Earlier quoted context omitted.
Unfortunately, it's more permissive than mathematical notation: `3 > 1 < 2` evaluates to True.
I can think of some more interesting examples when it violates intuition gained from mathematical notation. When looking at `a == b == c` we naturally assume that not only `a == b` and `b == c` but also `a == c` because equality is assumed to be transitive. The problem is that in Python we can make `==` operator to do literally whatever we want, so in Python `==` doesn't have to be transitive. You may argue that no r…
If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.
I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is over…
Example
(a==b)==c would be different from a==b==c