I don't find that so bad. They look complicated but behave as expected, and would only be a problem if you inherit a code base from a lone wolf without common sense.<p>Python has plenty of warts[1], but I don't think the syntax is one of them (yet). Some of the more concerning warts:<p><pre><code> # Mutable defaults in function parameters.
def fn(arg=[]):
arg.append(1)
print(arg)
fn() # [1]
fn() # [1, 1]
fn() # [1, 1, 1]
# Loop variables are shared across executions.
lambda_list = [lambda: print(i) for i in range(5)]
for fn in lambda_list: fn()
# 4
# 4
# 4
# 4
# 4
# Iterating over an exhausted generator yields an empty list.
numbers = (i for i in range(5))
assert 1 in numbers
print(list(numbers))
# []
# I hate this one because it could have easily been an error, it's
# hard to track down, and lots of stdlib functions return generators.
# Chained operators can sometimes be very unintuitive.
should_be_ascending = True
assert 1 < 2 == should_be_ascending
# AssertionError because it was interpreted as
# `(1 < 2) and (2 == should_be_ascending)`
</code></pre>
[1]: <a href="https://github.com/satwikkansal/wtfpython">https://github.com/satwikkansal/wtfpython</a>
Strange article. I thought it was going to show that these features interact in some unexpected way that causes weird bugs, but it all seems to work as expected.<p>So the conclusion, I guess, is that code doesn't make a whole lot of sense when it uses every available feature for no particular reason and foreign languages for variables names?
I learned about Python dev mode in this, thanks!<p>For anyone else:<p><a href="https://docs.python.org/3/library/devmode.html" rel="nofollow noreferrer">https://docs.python.org/3/library/devmode.html</a>
> While not as powerful as destructuring in other languages (I still wish we could unpack dicts as JS does with objects)<p>Like this?<p><pre><code> In [1]: a = {1: 10, 2: 20}
In [2]: b = {3: 30, **a}
In [4]: b
Out[4]: {3: 30, 1: 10, 2: 20}
</code></pre>
Or pattern matching?<p><pre><code> In [6]: match b:
...: case {3: somethingelse, 1: foo}:
...: print(somethingelse, foo)
30 10</code></pre>
> <i>if you use "_" in hex, and interpolate it with a 2 decimal precision</i><p>...or if you don't. The '_' doesn't change anything or add anything, here.
That example with the Chinese characters brings up a point that seems to have gotten lost or actively suppressed, likely by those with other motives: what may look "unreadable" to you may in fact be something that is perfectly normal to billions of others. Yet why are people constantly told to emphasise "readability" in the code they write, which really refers to a lowest-common-denominator dumbing down approach? Shouldn't the onus be on the reader to educate oneself sufficiently in the language to understand code that one thinks is "unreadable"? Moreover, unlike natural languages, programming languages are defined exactly and systematically, so there is no ambiguity whether a piece of code is valid or what it does.<p>What is "unreadable" to some could be perfectly readable to others; and what is readable to some could still be readable but unnecessarily verbose and tedious to read to others. We shouldn't let how we write code be dictated by those who barely know the language and want to drag us down to their level.
Lol, and they say Perl is bad.<p><a href="https://www.perl.com/pub/2000/01/10PerlMyths.html/#Perl_looks_like_line_noise" rel="nofollow noreferrer">https://www.perl.com/pub/2000/01/10PerlMyths.html/#Perl_look...</a><p>This isn't meant as flamebait, I'm just pointing out you can write obfuscated code in any language.
> a, b = b, a<p>> (don't know why this is so famous, I never, ever used that in prod)<p>This allows you to sort an array in place. It's heavily used in Go:<p><a href="https://godocs.io/sort#example-package" rel="nofollow noreferrer">https://godocs.io/sort#example-package</a>
We had a dev in our team who would love to use these one liner cryptic expressions and challenge the minds of code reviewers.<p>It was all fun until he left and others had to refactor bunch of code. One liners like that often have very little benefits IMHO.
This is neat!<p><pre><code> img = ["r", "g", "b"] * 10_000_000
iterator= iter(img)
groups= zip(iterator, iterator, iterator)
</code></pre>
I've been writing Python for 15 years and it had never occurred to me that I could do it like that. Honestly I think I'd have reached for more_itertools.chunked.<p>(FWIW In R I think I used to set an array dimension on the vector and process rows.)
Unpacking used to be more powerful. I was mostly oblivious to the Python community when I started working on a project and discovered that you could unpack tuples in function heads, like Erlang, and started using that frequently.<p>Then I discovered I was using Python 2 and it was EOL, and that Python 3 had dropped support for that “because no one uses it.”<p>Maddening.
> Inverting variables:<p>Non-native speaker here and even after 20+years every once in a while it bites, but I know that as 'swapping variables'. Where does the inverting come from? Related to the 'inverting a tree'?
most of these are loooong time there. list[:] replacement is since ever. (used for reversing a list, when there wasnt .reverse method)<p>But my beloved one, is the sequence of these changes, in time:<p>ver.134: x = ('a', 2)<p>some change in requirements made 2nd value unneeded, so it became:<p>v167: x = ('a',)<p>which is one day, "optimized" to:<p>v193: x = ('a')<p>Funny thing is, and x[0] will still deliver 'a' as it was before. Now if that 'a' is not constant but some parameter, and it's not 1 character long string..
Fun syntax gotcha that I saw recently was a YAML MAC address that were all numbers like 11:22:33:11 which Python was parsing as a sexagesimal number so some libraries were throwing type errors
Lol, your definition of “valid syntax” is wayyy different from mine. I wouldn’t ever use crap like that, it’s too unreadable to be “valid syntax” even if the interpreter can handle it. Can we all collectively agree to include our own brains in the definition of “valid code?”