3 ms·

I had to work with Python a few times in the past year and I really have to agree. The lack of proper lambdas, closures, its reliance on mutable data structures

I had to work with Python a few times in the past year and I really have to agree. The lack of proper lambdas, closures, its reliance on mutable data structures and imperative idioms, and the useless distinction between statements and expressions makes it feel like somebody was trying to write a modern language but for some reason stopped halfway. For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs. You can't have statements in lambdas, and map and filter are "unpythonic". Yet everybody feels like list comprehensions are the best thing after sliced bread, despite being the same thing. Closures are also clunky: you can define another named function inside a function and call it afterwards, and you can use functools.partials from the stdlib, but I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method. Ultimately, to me it feels like this all hurts the composability of the idioms of the language. List comprehensions can be nested, but they feel clunky and they're in a syntactical wall garden. You can compose expressions, but not statements.

Certhas 10y ago
I extensively use closures in Python, particularly jit compiled closures with numba. I don't really have any problems with that, why do you say it's unpythonic?
- steinuil 10y ago
  I'm not saying they are, I don't think I've used the language enough to be able to tell what's pythonic and what's not. It's just that I think the language support could be better: why defining a function and calling it right after? That's what lambdas are for.
  - StavrosK 10y ago
    > why defining a function and calling it right after? Documentation.
    - coldtea 10y ago
      You could have named closures, so that's hardly a valid reason.
      - xapata 10y ago
        We prefer to have only one obvious way to do it. The more good techniques in existence, the less there's a clear sense of "Pythonic". It's just a preference. Many tasks have more than one obvious way. But if you're asking to add a new feature, you should explain why it's worth the downside of adding yet another way to do it.
throwaway_374 10y ago
>For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs. Do you mean something like a ternary operator? You can certainly do: x='foo' if condition else 'bar'. In fact you can even do multiple assigments: (x,y) = ('foo1','foo2') if condition else ('foo3', 'foo4') where 'Foo' may also be a function call. >I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method. There's a few pycon talks on "a single method class should not be a class" but I'd say that's the single responsibility principle at its purest along with the community needing to move to more lightweight structures like namedtuples.
xapata 10y ago
Sparse is better than dense. Why do you need everything to be an expression? Sure, a variable lookup takes a nanosecond, but that's a small price to pay for readability. The fact that Python has an if expression and a lambda expression, but they were intentionally, not accidentally limited to one line should indicate there are some benefits to the trade-off.
moonshinefe 10y ago
Yeah, I don't think you know python very well at all given your criticisms. The very first thing you criticize is "its reliance on mutable data structures"--uhh no, most data structures and types in python are immutable. I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the language. And please. List comprehensions can be nested, just like every other language can be abused if you really want to try.
- FrederikNS 10y ago
  Most semi-primitive types in python is immutable, yes (int, float, char, str, and DateTime), but all of the collections are mutable (List, Dict, Set). I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked. I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
  - crdoconnor 10y ago
    I usually treat them as immutable by using copy(x) or deepcopy(x) unless I'm writing a chunk of code that is explicitly building it from scratch and pushing it somewhere.
camel_Snake 10y ago
I personally really dislike nested comprehensions and prefer to just chain with generators like so: classes = (student.current_classes() for student in students) good_grades = [c.grade for grade in classes if grade > 3.0]

Certhas 10y ago

I extensively use closures in Python, particularly jit compiled closures with numba. I don't really have any problems with that, why do you say it's unpythonic?

steinuil 10y ago
I'm not saying they are, I don't think I've used the language enough to be able to tell what's pythonic and what's not. It's just that I think the language support could be better: why defining a function and calling it right after? That's what lambdas are for.
- StavrosK 10y ago
  > why defining a function and calling it right after? Documentation.
  - coldtea 10y ago
    You could have named closures, so that's hardly a valid reason.
    - xapata 10y ago
      We prefer to have only one obvious way to do it. The more good techniques in existence, the less there's a clear sense of "Pythonic". It's just a preference. Many tasks have more than one obvious way. But if you're asking to add a new feature, you should explain why it's worth the downside of adding yet another way to do it.

throwaway_374 10y ago

>For example: you can't assign the result of an "if" statement. Why? Because it's a SyntaxError, no real reason. There is even an "ifExp" in the language grammar, but that's only for inline ifs. Do you mean something like a ternary operator? You can certainly do: x='foo' if condition else 'bar'. In fact you can even do multiple assigments: (x,y) = ('foo1','foo2') if condition else ('foo3', 'foo4') where 'Foo' may also be a function call. >I think people feel like it's unpythonic and instead pollute the namespace with singleton classes that only have one method. There's a few pycon talks on "a single method class should not be a class" but I'd say that's the single responsibility principle at its purest along with the community needing to move to more lightweight structures like namedtuples.

xapata 10y ago

Sparse is better than dense. Why do you need everything to be an expression? Sure, a variable lookup takes a nanosecond, but that's a small price to pay for readability. The fact that Python has an if expression and a lambda expression, but they were intentionally, not accidentally limited to one line should indicate there are some benefits to the trade-off.

moonshinefe 10y ago

Yeah, I don't think you know python very well at all given your criticisms. The very first thing you criticize is "its reliance on mutable data structures"--uhh no, most data structures and types in python are immutable. I'll at least agree I've met a lot of python snobs who say don't use the built in map/filter functions and things like that in favour of comprehensions, but that's hardly representative of the language. And please. List comprehensions can be nested, just like every other language can be abused if you really want to try.

FrederikNS 10y ago
Most semi-primitive types in python is immutable, yes (int, float, char, str, and DateTime), but all of the collections are mutable (List, Dict, Set). I'm sure there are immutable versions of those same data structures hidden somewhere in the standard library, but I haven't looked. I did stumble upon pyrsistent (https://github.com/tobgu/pyrsistent https://github.com/tobgu/pyrsistent) a while ago which does provide proper immutable (and persistent) data structures for python.
- crdoconnor 10y ago
  I usually treat them as immutable by using copy(x) or deepcopy(x) unless I'm writing a chunk of code that is explicitly building it from scratch and pushing it somewhere.

camel_Snake 10y ago

I personally really dislike nested comprehensions and prefer to just chain with generators like so: classes = (student.current_classes() for student in students) good_grades = [c.grade for grade in classes if grade > 3.0]