(a) I don't know Python as well as I thought I did. (b) I suddenly never want to use it again.
All these edge cases! All these behaviors, which I'm sure were added with the noble intention of increasing developer convenience, but which I'm equally sure have cost a larger amount of developer sanity!
It feels to me like javascript in that it's "popular" because people already use/know it. So that huge existing codebase is the equivalent to the web; if you want to build on it, you're stuck with this.
But my lord. Whitespace sensitivity is a terrible choice and there are piles of kludges trying to work around that.
It means no multi-line lambdas so you end up with these unreadable list comprehensions `[ sub_item.value for sub_item in item.sub_items in items if item.is_the_best ]`. Lines copied into the console care about indentation which is definitely not a fun DX.
Not to mention these random global functions everywhere. Whew.
Mistakes were made.
It's my favourite feature of Python and I actively seek out other languages that make this terrible choice.
I regularly use Python and a couple of curly brace languages and coming back to Python always feels like a breath of fresh air.
That’s a good way to put it. Significant indentation makes the syntax so much more lightweight.
This image [0] is supposed to be a joke, but to me it clearly demonstrates how braces and semicolons are both ugly and redundant.
[0] https://www.reddit.com/r/ProgrammerHumor/comments/2wrxyt/
> It's my favourite feature of Python
It's like the speed bump: It's for people who can't follow simple rules. It inconveniences you, but is rationalized with that it ultimately makes the world a little safer for everyone, including you.
Me, I unindent temporary code like debug-print statements and literals overriding actual data. This makes it impossible to commit by accident.
But my argument against whitespace sensitivity would be that bad and unreadable code is bad and unreadable regardless of its whitespace. In fact, force-formatting it just hides the evidence.
How would you rather write that code? Is it lack of multi-line lambdas that stops you from writing it as you would like?
items
.select(&:is_the_best)
.flat_map { |i| i.sub_item.map(&:value) }
You can have multi-line lambdas, just use parens:
(lambda: look.ma.im
.on_two_lines)
And your example is more clearly expressed as a plain loop:
new_list = []
for item in items:
for sub_item in item.sub_items:
if item.is_the_best:
new_list.append(item)
[item
for item in items
for sub_item in item.sub_items
if item.is_the_best]
> Not to mention these random global functions everywhere.
We ought to be able to have it both ways, it should be possible to lift a closure and treat the variables it closes over as arguments, but I wind up doing that manually just so I can test them directly.
> Lines copied into the console care about indentation which is definitely not a fun DX.
I think the issue with breaking copy and paste is the real valid complaint against indentation-sensitive languages. The tooling just isn't there, and this continues to be the case after 20 years.
Sure, you "should" use asyncio instead of promises but honestly it has its own problems, mostly in that it requires the rest of your legacy code base to also be async.
Prelude> [1, 3 .. 10] :: [Float]
[1.0,3.0,5.0,7.0,9.0,11.0]