281–290 of 372 posts
Don’t know why python gets so much love. It’s a painful language as soon as more than one person is involved. What the author describes is just the tip of the iceberg
This line, though, seems like it's using the wrong tools for the job:
len(list(filter(lambda line: all([abs(x) >= 1 and abs(x) 0 for x in line]) or all([x sum(1 for line in diffs
if ((np.abs(line) >= 1) & (np.abs(line) 0).all() or (line Earlier quoted context omitted.
Failure to understand something is not a virtue. That it does get a lot of love strongly suggests that there are reasons for that. Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Create a comprehensive pro/con list and see how it fares. Then compare that to pro/con lists for other languages.
> That it does get a lot of love strongly suggests that there are reasons for that. Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether. Python has a really strong on-ramp and, these days, lots of network effects that make it a common default choice, like Java but for individual projects. The rub is that those same properties—ones that make a language or codeb…
Pros: easy to interact with different tools, included in many Unix OSs, battle tested.
Cons: complex stuff gets messy, with weird syntax, hard to do logic, hard to escape everything correctly
Earlier quoted context omitted.
I find myself writing a very simple style of python that avoids list comprehensions and so on when working in a shared code base. For a language where there is supposed to be only one way to do things, there are an awful lot of ways to do things. Don’t get me wrong, writing a list comprehension can be very satisfying and golf-y But if there should be one way to do things, they do not belong.
I find list and dict comprehensions are a lot less error prone and more robust than the “manual” alternatives. I would say unless you have a good reason to do so, features such as meta classes or monkey patching would be top of list to avoid in shared codebases.
I find them easier to understand and explain, too.
I had a similar thought a few years ago with an Advent of Code problem for which my solution in python might have been max(map(sum, input_list.split(None))) To decipher this the eye has to jump to the middle of the line, move rightwards, then to the left to see the "map" then move right again to see what we are mapping and then all the way to the beginning to find the "max". The author would probably suggest rust's s…
Honestly, I find using intermediate variables more readable than a long chain of function invocations where you have to keep track of intermediate results in your head: input_groups = input_list.split(None) group_sums = map(sum, input_groups) max_sum = max(group_sums) This also gives you a slightly higher-level view on how the algorithm proceeds just by reading the variable names on the LHS.
I prefer python comprehensions for the same reason. I can tell that they are about crating a list or a dict and I don't need to parse a bunch of operations in a loop to come to the same conclusion.
Earlier quoted context omitted.
I agree, it's not too bad if you enable strict Pyright checking in CI, and you use `uv` and you don't care remotely about performance. That's quite a lot of ifs though. Tbh I haven't found anything significantly better for scripting though. Deno is pretty nice but Typescript really has just as many warts as Python. At least it isn't so dog slow.
I've pretty much embraced PowerShell for scripting. The language is warty as hell and seems to be entirely made of sharp edges but I've gotten used to it and it does have a lot of excellent ideas.
But when I say "scripting" I don't mean shell scripting. I mean stuff like complex custom build systems or data processing pipelines. I would never do those in any shell language.
Earlier quoted context omitted.
This presupposes that the reader likes or even uses auto-complete. I do not, and there are many others like me.
And I'm sure there are people who program in Notepad or nano. If you want to develop software like it's the 80s again, go ahead, the rest of us appreciates at least basic IDE support.
> the Python code in the previous example is still readable Yes, I agree with the author, list comprehensions are readible, and I'd add, practical. > it gets worse as the complexity of the logic increases len(list(filter(lambda line: all([abs(x) >= 1 and abs(x) 0 for x in line]) or all([x Ok, well this is something that someone would be unlikely to write... unless they wanted to make a contrived example to prove a po…
Reading through this article only elicits a "WTF!?" from me. Your editor can’t help you out as you write it. You shouldn't need handholding when you're writing code. It seems like the whole premise of the author's argument is that you shouldn't learn anything about the language and programming should be reduced to choosing from an autocomplete menu and never thinking more than that. I've seen developers who (try to)…
If writing code is an automated process for you, you are also begging for AI to be replace you. Just a more advanced one than the code-monkey in the OP.
Another point to this is that we should switch to writing the numbers in the right order too: 123 should be three-hundred-twenty-one. This way, as soon as you type "1", it is truly one, you add a "2" and you know that's adding twenty... IIRC Arabic gets this right! /s
The idea is that we write `foo.bar`, where `foo` is in scope, exactly because `foo` is in scope. We don't write `bar from foo` or whatever, because it would be hard to reverse search the things that have `bar` in them.
But which is more likely: will `foo` be Liskov-substitutable for `bar`, or will other things that contain a `bar` have a `bar` of a Liskov-substitutable type?
Which is to say, the author is depending on a particularly idiosyncratic meaning of "valid".
That said, the problem the author describes at the beginning can be easily worked around, if you like this kind of workflow:
words_on_lines = [st # 'str' is a plausible autocompletion
words_on_lines = [str.sp # must be either 'split' or 'splitlines', unless 'str' is shadowed
words_on_lines = [str.split(line) for # 'line in' can be suggested
words_on_lines = [str.split(line) for line in text.splitlines()] # IDE can automatically check type and refactor the idiom