121–130 of 169 posts
>>> a := "wtf_walrus" File " ", line 1 a := "wtf_walrus" ^ SyntaxError: invalid syntax Why doesn't this work? Isn't the walrus operator effectively just an alternative to the assignment operator which also returns the assigned value? Why specifically make it fail in this situation?
> This rule is included to simplify the choice for the user between an assignment statement and an assignment expression -- there is no syntactic position where both are valid.
>>> a := "wtf_walrus" File " ", line 1 a := "wtf_walrus" ^ SyntaxError: invalid syntax Why doesn't this work? Isn't the walrus operator effectively just an alternative to the assignment operator which also returns the assigned value? Why specifically make it fail in this situation?
From the PEP [1] > This rule is included to simplify the choice for the user between an assignment statement and an assignment expression -- there is no syntactic position where both are valid. 1: https://www.python.org/dev/peps/pep-0572/
But if there is no syntactic position where both are valid, then why not just add a return value to the existing assignment operator? Surely that wouldn't cause any compatibility issues since prior to its introduction any attempt to use an assignment as part of an expression would raise a syntax error.
The Python/NumPy gotcha that has caused me the most pain by far is def foo(x, y): return x+y where the intention is for x and y to be NumPy arrays, but the caller accidentally passes lists (or vice versa). This is especially common because a lot of NumPy functions are agnostic as to whether they operate on arrays or other iterables.
Convention of using + for joining sequences and addition is human language level abstraction. It breaks in programming.
In formal theory strings over an alphabet form a semiring, but (*) is used for concatenation and (+) for alternation. Not applicable anyway.
Last, no clear syntactical cue to distinguish operators acting on elements from those acting on objects.
Earlier quoted context omitted.
To take one of your complaints: > Why do my lines of code need to fit on a punched card invented decades before the language was invented? Keeping lines short helps keep information density high, allows you to fit more views of the code on screen without wrapping, and encourages use of intermediary variables to keep complexity per line low. This isn't a Python issue. Any decent style guide will have a maximum line le…
Line length isn't a python issue. A line length of 80, is. (Thus the punch card reference). My stint in python made me appreciate A line length more, but 80 got to be absurd.
My understanding is that 80 was originally chosen because that was the standard number of columns on a terminal. It has been continued to be used because it happens to be roughly just under half the width of a typical 16:9 or 16:10 monitor at normal font sizes, making it ideal for window snapping and side-by-side diffs.
I have to review code in other languages all the time which follow a style guide that defines a maximum line length of 120 or 160. It's a huge pain having to scroll left and right all the time. But I'm not about to replace my perfectly good 16:10 monitors with ultrawides.
Earlier quoted context omitted.
> I've been seeing a growing anti-python sentiment lately, and most of it seems to be based on these sorts of odd perceived language defects. I've seen the same, but to me it feels like the downslope of the hype-train that was brought on by the ML crowd. Early on there was python doing python things, and the (IMO overly smug) community was happy with that. Then the AI/ML hype train fired up and for historical #reason…
"Hard to scale" isn't really a coherent argument against any mainstream programming language. It's kind of like saying that AMD processors or Microsoft Word are hard to scale - it's not entirely meaningless as a criticism but it's close to it. Python is not a language for writing ultraperformant multi threaded code but, of course, that's not what it used for or was ever intended to do and is an entirely separate issu…
It is odd that you would say that, because it is a very common complaint about languages with dynamic typing. As the program grows larger static typechecking becomes more and more helpful.
Earlier quoted context omitted.
I think the reason not to write `== None` is that classes can override `==`: class C: def __eq__(self, other): return True C() == None # True C() is None # False
It is also marginally faster, I think.
el==None
el is None
None==el
I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…
> I've been seeing a growing anti-python sentiment lately Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I sti…
To be frank I think the python community lacks self-awareness. There's this ritual you have to do when learning python: blindly accept status-quo design choices as "universally good" (but call it "pythonic"), and crap on other languages. Never admit python or the ecosystem has issues or shortcomings, and if another language has something better than yours (eg, Yarn, or Composer is way better than anything in Python (…
To take one of your complaints: > Why do my lines of code need to fit on a punched card invented decades before the language was invented? Keeping lines short helps keep information density high, allows you to fit more views of the code on screen without wrapping, and encourages use of intermediary variables to keep complexity per line low. This isn't a Python issue. Any decent style guide will have a maximum line le…
Earlier quoted context omitted.
> I've been seeing a growing anti-python sentiment lately Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I sti…
> I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable I've only been following Python for a little over 20 years of it's ~30 year life, but I don't remember it ever being “untouchable”, or even just “untouched” by criticism.
Edit: the XKCD antigravity comic was December 2007, so pretty early on all things considered. PG’s Python Paradox was 2004.
Earlier quoted context omitted.
"Hard to scale" isn't really a coherent argument against any mainstream programming language. It's kind of like saying that AMD processors or Microsoft Word are hard to scale - it's not entirely meaningless as a criticism but it's close to it. Python is not a language for writing ultraperformant multi threaded code but, of course, that's not what it used for or was ever intended to do and is an entirely separate issu…
> "Hard to scale" isn't really a coherent argument against any mainstream programming language. It is odd that you would say that, because it is a very common complaint about languages with dynamic typing. As the program grows larger static typechecking becomes more and more helpful.
Regardless, python has tools to do that. Instagram and Dropbox in particular have written quite a lot about their internal usage and built and open sourced additional tooling (e.g. MonkeyType - that lets your code type annotate itself).