Hacker News Reader

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.

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) a while ago which does provide proper immutable (and persistent) data structures for python.

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.

>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.

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?

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.

> why defining a function and calling it right after?

Documentation.

You could have named closures, so that's hardly a valid reason.

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.

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]

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.