What the Fuck Python
colab.research.google.com
colab.research.google.com
I don't feel strongly about Python, but I do think CPython is a great way for people to learn a bit about how interpreted languages work. The code is quite easy to understand, and you can easily play with these interesting aspects of how languages and runtimes work. Does every Python programmer need to know the difference between `a = 256` and `a = 257`? No. Is it interesting? Yes. Should someone on your team know? Probably.
There's a lot of interesting stuff here. Understanding the difference between the conceptual idea of each line of code and what actually happens is fun, and, in some cases, important.
It's these quirky little things where the code doesn't exactly represent the way execution happens in most straightforward mental models of how execution works. Again, it's not bad and it's not unique to Python. It's just the nitty gritty of how some things work.
I will say that calling it "What The Fuck Python" is certainly more attention-grabbing than "Some Interesting Bits About Python Internals You Probably Don't Need To Know". What're you gonna do. :)
Bugs in understanding. Bugs in good taste.
A roach in your soup is a bug, even if the recipe says it should be there.
Similarly, as long as the mental model of a Python programmer is in line with the results of executing some computation with Python, all is well.
"You can cook them in numerous ways, from boiling to toasting. An especially delicious cockroach delicacy is said to exist on Madagascar." https://bucketlistjourney.net/edible-bugs-and-insects/
(a roach itself is a bug, different sense of the word bug, but presumably that's not what you are saying)
You're finding bugs because you're using the language like a QA tester instead of the way its intended. If I saw string_var is "some_string" in a PR, I would reject it. Even the triple boolean comparison example should just be separated with an "and".
Read PEP20 and PEP8. A goal of Python is to be as readable as possible, not to conform to some spec. You may not agree with that design decision, but all these examples have an obviously more readable alternative which would work.
Jeez. It's like me complaining that Rust looks ugly (it does). The language was designed with a different set of priorities.
What do you think this means? Are the bugs there or not?
the spirit in which that page is presented is different from what you seem to have taken it to mean
The goal of every programming language should be to conform to a spec that is as logical and consistent as possible. This prevents bugs by saving tons of mental effort having to worry about and look up edge cases, and not always catching them all.
I don't mind so much if end-user applications have bugs when they're used differently from intended, because their use cases are narrow. If Word crashes when I put 10,000 images on a single page, well obviously it's not built for that.
But I mind very much when programming languages have bugs, because they are the layer on top of which we build so many other things! The use cases for a programming language are almost infinitely wide.
For a language as widely used as Python, we should be testing it out like QA testers. All these inconsistencies add up to tons of bugs when you expect something to follow a consistent pattern and it doesn't.
It's not to give "best practices" but to unveil gotchas and peculiarities in the language implementation and internals.
>A goal of Python is to be as readable as possible, not to conform to some spec.
This doesn't even make sense.
People learning the language or learning programming, something Python is supposed to be good for and is widely used for. Also, casual and intermittent users of Python, who might not hold all the details in their head because they work in multiple different languages. These categories would encapsulate the majority of Python users in practice, and all of them end up "QA testing" the language unintentionally and wasting time and effort figuring out inscrutable problems.
A better designed language could prevent a lot of these abuses, give informative error messages, or at the least warnings. These are not inevitable results of language flexibility, but in many cases just the result of poor design that got patched up imperfectly over time - which is understandable given Python's history, but doesn't make the problems go away.
No one, obviously. This is about understanding how the python interpreter functions.
>Python has a rich library of string methods, maybe use them?
How are you able to get the impression that any of this is a prescription on how python programming should be done? Nowhere does it claim to be, in fact if you read the actual content you would understand why these examples aren't the way to accomplish your goals.
Why are you so incredibly defensive when someone points out that a programming language contains weird behavior most people do not understand? This is true for every language. And almost always these examples are given so that people can refine their understanding of the language.
>Jeez. It's like me complaining that Rust looks ugly (it does). The language was designed with a different set of priorities.
The only person complaining is you.
It would not be a positive change to sacrifice Python performance in order to make the output of id() more intuitive. I've spent many hundreds of hours coding Python and I don't believe I ever used that function or saw someone else use it.
[1]: https://docs.python.org/3/library/functions.html#id
[2]: see e.g. https://stackoverflow.com/questions/52096582
Both aren't perfect languages, and both are far from "the best" but it is maddening that Python get often picked as a darling when its implementation, ecosystem and tooling are fundamentally at odds with correctness and productivity.
This is not idiomatic Python code. It's code designed to demonstrate Python performance optimizations, through use of relatively obscure Python functionality which exposes details of the internals in situations where you need that.
"its implementation, ecosystem and tooling are fundamentally at odds with correctness and productivity"
You'll need a lot more than just this notebook to argue for that position.
Do you think there should be different results for bool("no"), bool("false"), bool("heckno!"), bool("heckyes!")?
Edit: should have included internationalization: bool("nein!")
But it's entirely reasonable to think it would. I honestly don't understand why it wouldn't, because:
>>> int("35")
35
>>> float("3.5")
3.5
>>> bool("False")
True
And of course it doesn't need to work for "no" or "heckno!", that's silly. But it sure seems like it ought to work on whatever the official string representation is. And not produce:
>>> bool(str(False))
True
prefer bool() threw an exception on receiving a string, rather than act the way it does now.
a = 1 # or [], (), "yo", "false", 3.2, MyFooClass(), (1,), False
if a:
fire_ze_missles()
else:
declare_peace()
It can short-circuit the brain upon reading a word that you know means false, but the Python rules are consistent. "Empty" is False, everything else is True.
> I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now.
They serve fundamentally different purposes. bool() is a truthiness check and not a type cast like int() and float(). It seems like a lot of people take issue with the name, because it was called something like istruthy() the discussion about it wouldn't be happening.
Right, the bug is in the inconsistent naming.
It's roughly as bad as having arithmetic operators named +, -, *, / that perform arithmetic as usually understood, except that + actually performs XOR and is documented to do so.
The comment I responded to didn't seem to realize that because they asked why it behaves the way it does, so I explained.
`bool` would have no value if it threw an error in this case because if strings can't be passed to it, then no other type would sensibly work either. It would basically just become `bool(False) -> False` and `bool(True) -> True`.
It's pretty standard to convert integers to bools, where 0 becomes False and everything else becomes True. That is absolutely sensible and useful current behavior.
Not consistent at all.
There's nothing consistent about bool(str(False)) == True.
It's standard in computing for zero integers to represent False. Heck, bool is a subclass of int. Extending that to the length of strings is where things start to go off the rails in terms of consistency... and why you would ever even want that is beyond me.
Which becomes a different issue - what do you think str(True) and str(False) should produce. Integer representations? That then makes other things unintuitive with changing the form of a boolean.
print(0, 1, False, True)
# today: 0 1 False True
# as ints: 0 1 0 1
# new str: 0 1 "True" ""str(False) == 'False' is entirely logical.
So therefore bool('False') == False would be consistent.
And bool('foo') would produce an exception the exact same way int('foo') and float('foo') already do.
Who on earth thought it was a good idea that 'foo' could or should be interpreted as a boolean...?? The entire concept of 'truthiness' outside of ints is unhelpful. It's just asking for bugs. That the length of a string, rather than its content, should determine a boolean value is one of the more bizarre things I've come across in programming languages. Use len() if you want that. It's only 5 extra characters.
There's no type casting in Python. int(), float() and bool() just create objects of their respective types, passing the arguments to the initializer. They are not fundamentally different from, say, PostgresqlDriver() in this regard.
Different classes will provide different ways to construct objects depending on what is most useful. For int and float, the most useful thing to do when receiving a string is to parse it; for bool, the most useful thing to do is to check its truthiness; for PostgresqlDriver, the most useful thing to do is to interpret it as a database URL and connect to it.
If you search "type casting in Python" you will find lots of articles explaining how to use int(), str(), etc. to cast. This is a common and well-documented concept, even if it's different under the hood from e.g. C.
The idea that you'd name a function bool() and have it act differently is a deeply confusing design decision that it's understandable people would get misled by and frustrated with. This is a function named after a fundamental type. It's not a random user-defined constructor.
if "False":
# What do you expect? True or False?
print("True")
else:
print("False")
if bool("False"):
print("True")
else:
print("False") # This would be different if we landed here.
Honestly it's not that hard to write something that looks like this:
def str_to_bool(val: str) -> bool:
return val.lower() in ["yes", "true", "1"]https://docs.python.org/3/library/functions.html#bool
A good tutorial will reflect this fact and use appropriate language.
Both the idea that you can "cast", and the idea that bool is a function, are misunderstandings rooted in the idea that Python should be like C in all ways.
int() and float() behave like type casting, bool() does not. It's a truthiness check that would be more aptly named istruthy(). In python non-empty strings are truthy, so providing any string except for "" to bool() will return True, including "False".
(char*)21 != "21"
What you're reaching for is type conversion. Some languages have "implicit conversion" when casting, but the word itself doesn't require it.
A cast of insert a conversion that wouldn't take place:
1/2 vs 1/(double)2
bar *b = 0;
foo *f = (foo *) b;
Because I'm tired, and this is a very basic topic, I'm afraid I'm just going to rip from Wikipedia:
> In most ALGOL-like languages, such as Pascal, Modula-2, Ada and Delphi, conversion and casting are distinctly different concepts. In these languages, conversion refers to either implicitly or explicitly changing a value from one data type storage format to another, e.g. a 16-bit integer to a 32-bit integer. The storage needs may change as a result of the conversion, including a possible loss of precision or truncation. The word cast, on the other hand, refers to explicitly changing the interpretation of the bit pattern representing a value from one type to another. For example, 32 contiguous bits may be treated as an array of 32 Booleans, a 4-byte string, an unsigned 32-bit integer or an IEEE single precision floating point value. Because the stored bits are never changed, the programmer must know low level details such as representation format, byte order, and alignment needs, to meaningfully cast.
> In the C family of languages and ALGOL 68, the word cast typically refers to an explicit type conversion (as opposed to an implicit conversion), causing some ambiguity about whether this is a re-interpretation of a bit-pattern or a real data representation conversion. More important is the multitude of ways and rules that apply to what data type (or class) is located by a pointer and how a pointer may be adjusted by the compiler in cases like object (class) inheritance.
Implicit conversion can be seen as the compiler deciding among several possible conversions (or possibly just one) and inserting the coercion/casting operator into the intermediate code to make it happen.
(Of course, this can be a run-time decision based on dynamic types also, but the reasoning is the same. E.g. the run-time sees that a plus operation is adding an integer and float, and can either signal an error (requiring the program to be repaired by inserting a conversion operation into the expression), or just do that conversion, like the integer operand to float.
Otherwise types are just sugar. Indicies are just sugar. Lists are just sugar.
That said, I think you're correct about the casting versus conversion distinction. Languages frequently overload established terminology with slightly modified variants and it's incredibly confusing.
in raku, i checked
say False.so; #False say "False".Bool
say "False".so
Leaving out the quotes means you're testing something else entirely.
Note that the Python example is converting (via `bool`) a string with the text "false" (which would make more sense as "False" which is the actual name of `False` in Python) into a boolean value. It's consistent with how Python behaves, in that the empty string (like in Raku from what I can tell) is false-y and non-empty strings are truth-y. It would be weird to have this use the else branch:
if bool("False"):
...
else:
...
if "False":
...
else:
...Generally python is much better than some other dynamic languages in avoiding stringly typed confusion, but the convenience of the int from string constructor set expectations that the rest of the language can't sanely meet.
String to type construction should have been relegated to a dedicated syntax in all cases.
Python's file system support across platforms is notoriously problematic or even outright broken. Wasn't this enough reason to put it lower in the quality bar than JavaScript?
But, if you have any suspicion that JavaScript has been treated unfairly: it hasn't. It is literally being replaced by TypeScript as we speak. The fact you have to invite people to come up with more Python slander is itself a testimony, JavaScript has never needed an invitation. Having lot more issues than others is what being exception means, and JavaScript is one.
That's a fair critique. It's a little weird that `is` and friends have dedicated, short, nice syntax.
On the other hand, most compiled languages are compatible with an implementation which admits the following optimization:
const a: u32 = 42;
const b: u32 = 42;
assert(&a == &b);
That's the same class of error we're seeing here, and even among popular interpreted languages Python is by no means unique. I might get to the bottom 2/3 of the doc later, but the rest was off-putting enough that I don't know I'll bother.
>>> a = b = (1, 2) >>> a = b = (1, 2)
>>> a = a + (3, 4) >>> a += (3, 4)
>>> b >>> b
(1, 2) (1, 2)
>>> a = b = [1, 2] >>> a = b = [1, 2]
>>> a = a + [3, 4] >>> a += [3, 4]
>>> b >>> b
[1, 2] [1, 2, 3, 4]
>>> a = ([1, 2], ['one', 'two'])
>>> a[0] += [3, 4]
TypeError: 'tuple' object does not support item assignment
>>> a
([1, 2, 3, 4], ['one', 'two'])
I think the whole thing does a misservice to novice or unwary programmers. It's supposed to be easier to use because you "don't have to worry about it" - but you really, really do. If you're not familiar with most of these details, it's way too easy to wander into code that behaves incorrectly.
My mental model for Python is that everything is '"copied" by reference', but that some things are immutable and others are mutable.
I believe that's equivalent to immutable objects being 'copied by value' and mutable ones being '"copied" by reference', but "everything is by reference" more accurately reflects the language's implementation.
I think “everything is by reference” is a better model for programming than “you need to learn which objects are by reference and which are by value”. As you say, the latter is the case in Go, and it’s one of the few ways the language is more complex than Python.
You could argue that in Python you still have to learn which objects are mutable and which are immutable - but if it weren’t for bad design like `+=` that wouldn’t be necessary. A object would be mutable if-and-only-if it supported mutating methods.
The model is: everything is a reference (more accurately, has reference semantics); and is passed by assignment ("value", in older, cruder terms).
> but if it weren’t for bad design like `+=` that wouldn’t be necessary. A object would be mutable if-and-only-if it supported mutating methods.
`+=` is implemented by `__iadd__` where available (which is expected to be mutating) and by `__add__` as a fallback (https://stackoverflow.com/questions/2347265). The re-assignment of the result is necessary to make the fallback work. Reference for your "major wtf" is https://stackoverflow.com/questions/9172263.
Python is "pass by value", according to the original, pedantic sense of the term, but the values themselves have reference semantics (something that was apparently not contemplated by the people coming up with such terminology — even though Lisp also works that way). Every kind of object in Python is passed the same way. But a better term is "pass by assignment": passing a parameter to an argument works the same way as assigning a value to a variable. And the semantic distinctions you describe as nonexistent are in fact easy to demonstrate.
The model is easy to explain, and common in modern programming languages. It is the same as non-primitive types in Java (Java arrays also have these reference semantics, even for primitive element types, but they also have other oddities that arguably put them in a third category), or class instances (as opposed to struct instances, which have value semantics) in C# (although C# also allows both of these things to be passed by reference).
The pre-allocated integer objects are a performance optimization, nothing to do with semantics.
The model is useful for programming, because it's correct. We know that Python does not pass by reference because you cannot affect a caller's local variable, and thus cannot write a "swap" function. We know that Python copies the references around, rather than cloning objects, because you still can modify the object named by a caller's local variable. We know that no copy-on-write occurs because we can trivially set up examples that share objects (including common gotchas like https://stackoverflow.com/questions/240178).
> This is a special case of an even larger (IMO) misfeature, which is that the language tries very, very hard to hide the concept of a pointer from you.
With that said, a = b = [1,2] itself is a bit of a code smell, but I don't take issue with it here because it can arise in more subtle ways sometimes.
I think the first one probably arises more frequently, but at least there's a fairly straightforward explanation: "`x += y` acts in-place if-and-only-if `x` is mutable".
The second example is more niche but it's much harder to explain what's going on - it can only be understood by first understanding the first example, and what it implies about the implementation of `+=`.
This is the explanation. By definition it is only possible when the left-hand side is mutable; and in these cases, it's also typically convenient.
This was apparently seen as "although practicality beats purity" rather than "special cases aren't special enough to break the rules".
That was PHP. Though Python was a close second
The existence of Pypy and CPython and separate but compatible entities shows that there is
Pypy was developed by reverse engineering CPython and their automated tests feature explicit comparisons with CPyton.
You made the opposite point you thought you were making.
any compiler that can pass ROAST is valid
As a relatively recent example, here's the language reference documentation for the match statement https://docs.python.org/3/reference/compound_stmts.html#the-...
Documentation is not a specification. Specifications cover all behavior that should be expected, and specify which behavior is implementation-defined or undefined. If something isn't defined them this is a failure in the specification that requires fixing. The point of a specification is to allow independent parties to do clean room implementations that can be used interchangeably.
Modern Python documentation is absolutely horrible - there's a shitload of irrelevant rambling while absolutely crucial details are omitted.
stealing this
It is curated with something-for-everyone approach, I expect people to learn a thing or two about Python / CS after going through the snippets. I haven't updated it in a while in a major way, but looking at the feedback I'll try to organise them better, and add new snippets (I have a long personal list that I maintain) in a future release!
Java as contrast has interning wtfs because == between java objects does essentioally what python's `is` does. Python actually made a good choice here and made == do what you'd expect.
Is anyone surprised by `(1 > 0) < 1`? There are languages where it will be rejected because of types, but what else would you expect it do than compare a boolean true to 1?
Is there anything of value later on?
It's pretty sensible because i wouldn't expect that operator to call a method - since Java does not have operator overloading.
This is presumably meant as a setup for the fact that the result of `1 > 0 < 1` differs from the result with parentheses set up either way (because this is a chained comparison), and furthermore that such chained comparisons are legal even when they don't have the operators all "pointing" the same way (like in mathematical notation). And that operators like `in` and `is` are allowed to participate in this system on equal footing.
The "interactive notebook" link goes to the colab page.
There are many earlier threads associated with the markdown version, for example:
https://news.ycombinator.com/item?id=21862073 (2019-12-23, 185 comments)
https://news.ycombinator.com/item?id=26097732 (2021-02-11, 163 comments)
https://news.ycombinator.com/item?id=31566031 (2022-05-31, 143 comments)
https://news.ycombinator.com/item?id=37281692 (2023-08-27, 82 comments)
>>> a=3
>>> b=3
>>> a is b
True
>>> a=1e20
>>> b=1e20
>>> a is b
False
[4]> (setq b 1E20)
1.0E20
[5]> (setq a 1E20)
1.0E20
[6]> (eq a b)
TNo, that's not true.
>> numbers with the same value need not be eq,
http://clhs.lisp.se/Body/f_eq.htm#eq
It's not guaranteed that eq will return true for two numbers of the same value in Common Lisp. It happens to work much of the time, but it is never guaranteed to work. For a given implementation it could even be true all the time (as it's not disallowed), but for portability it should not be relied upon.
Why your Lisp implementation produces true for (eq a b) is probably because of the following.
Firstly, in Common Lisp there are single and double precision floats. Floating point tokens written with E or e are single. An implementation is allowed to map that to a 32 bit float. If the implementation has 64 bit values, it can easily arrange for single precision floats to be unboxed without any special tricks; they need only half the word. Try evaluating with 1D+20 to see what that does.
But even 64 bit values can be unboxed with a trick called NAN tagging.
I implemented NAN tagging in TXR Lisp (which has only double-precision floats), enabled on 64 bit targets:
64 bit machine:
1> (eq 1E20 1E20)
t
2> (sizeof val)
8
1> (eq 1E20 1E20)
nil
2> (sizeof val)
4
It's pretty important to have unboxed floats for intense numerical work.
I have never had a successful experience writing or running programs in notebooks like this--although I have not, arguably, tried with high stakes.
As soon as the stakes rise that far, however, I reach for a whole-ass Unix environment with a shell, a filesystem, and a stateful process model.
Is this a crutch? Is it too much overhead? It's arguably absurd that I even ask. (Edit: It's actually killing me how ambiguous I'm being, right now. There's no winning.)
I don't understand what you mean by "reach for". Don't, for example, Linux desktop users have all these things at hand all the time? For me it would take much more effort to set up a "notebook" than a virtual environment.
To start the application, you would typically use the start menu on Windows or the Dock on MacOS. Alternatively on MacOS you could point the Finder at the /Applications folder, then start the application from the Finder window.
(This is not meant as an endorsement of notebooks.)
Making a html document so someone can easily run some JavaScript, seems like the closest parallel to making a jupiter notebook so someone can easily run some python.
Seems like an odd way to say, "Notebooks don't fit my workflow/usecase."
The more one-liners there are in the code base, the more impenetrable and harder to debug the code is. Unrolling nested functions and switching comprehensions to lists and if statements often make it cleaner and easier to write unit tests for.
If you rely upon code coverage for unit tests, a complex list comprehension won't help you see if you have hit the branch cases.
Static types + IDE features make it much easier to understand any codebase.
Python 3.5, which is what the WTFs use by default, is relatively ancient.
These are not wtfs, please.
These examples read like someone who is learning to program and who is confused.
x is not y
x is (not y)
Otherwise, prepare for the horror of realizing that `{0.3: 'test'}[0.1 * 3]` (or the syntactic equivalent) fails — in every programming language that lets you try.
Probably better to represent them using some kind of infinite precision decimal
edit: to be more clear, I have run into a lot of JS wtf's trying to write code for work. you just run into bugs all the time where JS doesn't do anything like what would be the obvious thing to do, or the thing that works 99.99% of the time fails depending on the value of the string being 'magic'. with Python I rarely if ever learn some bizarre arcane thing accidentally because it almost always behaves as expected. If you think there's an equivalence here you are just a JS fanboy, JS was a language that evolved largely because of hacks vendors put in and those insane hacks got standardized because it was too late, despite being insane. Python was specifically and carefully designed to minimize unexpected behavior.
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.
The fact that you could have separate string objects both representing that text, is entirely orthogonal to that.
char* s1 = "wtf!";
char* s2 = "wtf!";
if (s1 == s2) { ... }
> "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.
F'ing JS equality isn't transitive for builtin types.
Allowing out of bound array indexing and operations using “undefined” seems pretty crazy to me.
False == False in [False]
# Outputs True
False == False # True
True in [False] # False
False in [False] # True
False == True # FalseSo 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.
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.)
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
I'll add:
>>> False == False in [True]
False
>>> True == True in [True]
True
>>> 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())]))])
False == False in [True]
=>
(False == False) and (False in [True])
def foo(): return False == False in [True]
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
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 return False == False in [False]
a = False
b = False
c = [False]
(a == b) and (b in c)
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 TrueIt 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".
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.
Builds so messy that you need to resort to venv, every second DOM API being someFunc(thirdMostImportantArgument, { mostImportantArgument: val }), these are the real wtfs.
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.