4 ms·

I've been writing python for about a year and change now (~7 years of engineering generally) and I never want to use it again. It feels to me like javascript i

• andybak 7y ago
  > Whitespace sensitivity is a terrible choice 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.
  • aib 7y ago
    > > Whitespace sensitivity is a terrible choice > 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.
  • pansa2 7y ago
    > 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/ https://www.reddit.com/r/ProgrammerHumor/comments/2wrxyt/
• pansa2 7y ago
  > 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 ]` How would you rather write that code? Is it lack of multi-line lambdas that stops you from writing it as you would like?
  • deleted 7y ago
    [deleted]
  • ulucs 7y ago
    items .select(&:is_the_best) .flat_map { |i| i.sub_item.map(&:value) } Not having functional constructs really hurts readability, and I don't want to think about what would happen to the list comprehension with more complicated logic
• Ragib_Zaman 7y ago
  Not allowing multi-line lambdas is beneficial for code readability. If your lambda needs multiple lines, you should write a function.
  • Too 7y ago
    Chained promises are much easier to read when the steps are inlined as multi-line lambdas rather than having to read the code backwards for every function definition. And as much as i love list comprehensions, map() and filter() with 2-3 line lambdas also make a lot of sense. 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.
• ben509 7y ago
  > It means no multi-line lambdas so you end up with these unreadable list comprehensions You can have multi-line lambdas, just use parens: (lambda: look.ma.im .on_two_lines) And, yeah, if it's complex enough that it should have control flow, you just write a nested function. 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) I don't like the comprehension syntax. The correct comprehension is: [item for item in items for sub_item in item.sub_items if item.is_the_best] Hopefully that makes plain what they were going for, but in practice, list comprehensions are often a contradiction in terms. > 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.