16 ms·
And it'd be unfair to that new language too. Basically all of the WTFs in the OP are things you don't run into, unless you're writing deeply deeply weird code,
by Doxin 6y ago
And it'd be unfair to that new language too. Basically all of the WTFs in the OP are things you don't run into, unless you're writing deeply deeply weird code, at which point it's hardly the languages fault that it does weird things.
- sorokod 6y agoNot a python dev, but what is deeply weird about the examples in "Strings can be tricky..." section?
- olau 6y agoBoth "id()" and its companion "is" are almost never used in practice - I don't think the tutorial mentions them. At least when it comes to id(), you'd have to find that in the reference where it will explain how it works. If you're familiar with C, id() returns the memory address of the thing given to it, and "x is y" is like "id(x) == id(y)". So "x" is "x" is asking whether the Python runtime happened to put the two strings in the same place in memory, not whether the two strings are equal. ("is" is commonly used for one thing - testing against None. So you might write "a is None". I think that's just because someone once got bitten by a badly overloaded == operator. Just like some people will write === in all their Javascript, in case an incorrect type sneaks in.)