91–100 of 209 posts
Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.
I suspect the interviewer would have likely been fine if they’d been able to explain chained comparisons and how they work. I would probably consider the interviewer using them without understanding them to be a negative signal.
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…
"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 evaluating and interviewing thinks - nay has the unshakable belief - that their way of evaluating developers is 100% spot on. However it's always something they just made up, justify with plain old words and never science.
Earlier quoted context omitted.
I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0. I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically. Also, most languages implicitly assume that any…
A lot of languages have no boolean primitive to begin with. Often in older languages, the values for `true` and `false` are aliases for `0` and `1` respectively. Perl and earlier versions of C, Python, and JavaScript are notable. Perl is probably the most awkward due to context-sensitive casting. e.g. the string `"0"` in a boolean context evaluates as an integer, and the boolean interpretation for `0` is false.
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.
I'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.
I remember when that went into Python. It seemed too cute. There was a lot of that around the Python 3.4, 3.5 era. The case where all items are the same type is reasonable, but if implicit type conversions are invoked, it gets really complicated. Whatever the types are, Python will probably do something. Just not necessarily what you want. I could see having this if there was a compile-time constraint that all variab…
> Whatever the types are, Python will probably do something. Just not necessarily what you want. Are you sure you are not confusing it with PHP? Python is not statically typed, but it is strongly typed. There is no implicit type conversion unless it's safe to do so (such as between a float and an int). For example, print(1 > "foo") will raise a TypeError, and print("1" == 1) will print False.
This can lead to some strange operator semantics in mixed-mode expressions. Whether chained expressions left-associate or right-associate matters.
numpy.array operations do a lot of implicit conversions. You can use Python arrays on many operations that expect a numpy.array. Mixing them works. Mostly.
python3
Python 3.10.12 (main, Sep 11 2024, 15:47:36) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> a1 = numpy.array([1,2,3])
>>> a2 = [1,2,3]
>>> a1 == a2
array([ True, True, True])
>>> a2 == a1
array([ True, True, True])
>>> a1 == a2 == a1
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
>>> a2 == a2 == a2
True
>>> a1 == a1 == a1
Traceback (most recent call last):
File "", line 1, in
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()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.
But then is the mathematical '=' really a binary operator that maps two numerical inputs to a boolean output? It feels then as an abuse of notation if (A=B)=C doesn't allow A=B to change type?
Because I don't really have much use for a symbol that is some times doing a binary mapping from numbers to booleans and some times becomes some sort of ternary operator which maps 3 inputs to one boolean.
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?
Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.