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.
Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd p…
Interview gone wrong
101–110 of 209 posts
Re: Interview gone wrong
#102>> I have a very basic question which I usually ask in a interview which is to implement a tic tac toe game. I like this because the logic is straightforward and it helps to judge things like code quality / speed / conciseness etc. "I like this because the logic is straightforward and it helps to judge things like code quality / speed / conciseness etc." No, it doesn't. Everyone who comes up with their own pet way of…
Interviewing is inherently messy, imprecise and unscientific. The process involves a lot of guesswork and feeling, rather than accurate measurements of any kind. It creates a fictional work environment that is often stressful for candidates, so any signal you may get out if it is also inaccurate.
It's natural for interviewers to have a preference for certain questions, topics or ways of conducting an interview. You're free to disagree, of course, but claiming that your way is superior is silly.
Re: Interview gone wrong
#103D solved the problem with what happens with (a == b == c) in an unusual way. It gives an error message. Both the C way and the Python way are considered wrong. You're going to have to add ( ) to clarify.
Rust also gives a custom error message [0] that explicitly explains that "comparison operators cannot be chained" and shows you how to rewrite the expression using `&&`. Which makes me wonder whether they came up with this idea themselves or if they borrowed it from D. In any case, I think that this is the only reasonable solution for new languages. Because if you go with C way it will be surprising for people who ex…
When I implemented it, I had seen many knock-down drag-out debates about which was the best way to deal with it, and none of them mentioned simply making it illegal.
It was another one of those features that were based on my experience designing aircraft systems.
Another one adopted by pretty much all languages since D is the _ in numeric literals (although C++ used a backtick). It was just something that was obviously right once you saw it. But I didn't originate it, I cribbed it from Ada. I've always had a soft spot for Ada.
Re: Interview gone wrong
#104In this respect, Python makes a lot more sense since that is how you'd normally write such an equality in math, and generally how people chain them: A=B=C means A=B and B=C. Part of the problem here is that we treat true/false as "just another value" in programming, and thus the usual operators are used to compare them. In math notation, if you wanted to compare the result of comparison A=B to a Boolean value C, you'…
I cannot see it for !=
"a != b != c" is not equal to "not (a == b == c)" which is a bit strange imo
Re: Interview gone wrong
#105I 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?
if any([a in ["-h", "--help"] for a in args]):
display_help()
Would be one of those. Generally I learned that it can be beneficial to treat things as lists early on, e.g. if you have a program that takes one input file it costs you next to nothing to allow the input to be mutiple files as well.Re: Interview gone wrong
#106Did he get the job?
The interviewer also lost his job, since he didn't spot it nor does he know basic python syntax.
Re: Interview gone wrong
#107I am idiot but I would, and have in the past, have wasted the whole interview time argue in that I am right and he is wrong. Yes, John, some switches do start sending the packet before finish receiving it. It’s called cut-though switching. Hope you googled it. And yes it was worth losing the job offer over it.
Re: Interview gone wrong
#108If 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.
Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd p…
Hard disagree here. I write code for people who can read the language. This includes operator precedence.
Re: Interview gone wrong
#109WalterBright mentioned that D will give you an error. When designing Starlark (a derivative of Python), I also decided to give an error for this, by making the comparison operators non associative.
https://github.com/bazelbuild/starlark/blob/master/design.md...
I agree this Python feature can look cute, but I've found it's rarely useful and can easily be avoided.
Re: Interview gone wrong
#110I'd be more confused about the curly brackets, I only know python and have never seen them used like that? My brain goes like: Here comes a set or dict. Also, why not do `all(cell[0][0],cell[1][1]),cell[2][2])` if you want to have True when all 3 are True? Perhaps I'm missing something, I don't exactly consider myself a 1337 coder.
Yeah, that’s C/C++/JavaScript/… syntax, it’s not valid Python.
> why not do `all(cell[0][0],cell[1][1]),cell[2][2])` if you want to have True when all 3 are True?
We want to test whether all three are the same, not whether they’re all True.