Hacker News Reader

Comment by barrkel | Hacker News Reader

I find chained enumerator / block style code much easier to write and understand than list / dict comprehensions too. It's probably the single biggest thing that I don't like about Python; lambdas are simply too awkward, but lambdas + monadic transformations are probably my primary mental abstractions for writing software these days.

View on HN

With itertools and functools you should be able to program in that style just fine. You'll likely want to give your lambdas names with a "def", but you should be doing that anyway.

As a fellow FPer who does the monadic stuff in other languages, I think it's usually more trouble than it's worth in Python. Instead, trying to use more of the python-specific language constructs can help you get what you want.

Python is pretty imperative, and the language design ethos is pretty against designing around functional programming. But if you try to absorb some of the python-specific stuff like list comprehensions, generators, and context managers, you can write some tooling to help you get a DSL a little closer to what you're used to.

Giving my lambdas names is exactly what I don't want to do - the syntactic overhead is what kills the style, makes it an exercise in boilerplate. It's like Java closures before Java 1.8 - anonymous inner classes implementing interfaces are technically just about enough, but in practice entirely deficient, because the style is entirely unidiomatic.

The way my brain works (at this point in my career, 25 years of programming) is just against the Python grain. I think in terms of data flow graphs. Python wants me to think in terms of procedures and loops.

There are very good reason for naming functions (and ideally dangling them from the class rather than making them inner functions) - this encourages you to separate the 'what' from the 'how' and tends to result in code that is self-documenting. When you inline all your functions the person reading the code is forced to build and maintain multiple abstractions at one time to follow execution flow. Additionally, you are conflating the 'what' and the 'how' which forces the reader to context shift. If you replace the function with a well-thought-out name, code becomes much easier to read.

Could you give an example of that?

Think: bash shell pipes. Transforming input to output through successive filters and projections, applied in a concatenated fashion and developed interactively in a REPL. Model algorithms as transformations or compositions of the same, where possible, applied to lazy or eager iterators or consumers (the dual of an iterator, that acts as a sink for output) as required. Model data sources and sinks (like databases and network streams) as iterators and consumers. Program by building a data flow graph out of increasingly sophisticated (by composition) stateless widgets, rather than imperative loops etc.

Imagine you have a list of products with prices and you want to calculate the cost of all products that are of a certain type. In ruby you can write this as

products.select { |product| product.type == 'x' }.map(&:price).reduce(:+)

And in Python you can write something like:

    sum([p.price for p in products if p.type == "x"])

Excuse untested code from phone, but I like it better than the ruby version.

I guess it's a personal style choice, the Python code is more performant(less iterations over the data set), but I like the ruby version better.

It's only one iteration if you throw a .lazy in there:

products.lazy.select { |product| product.type == 'x' }.map(&:price).reduce(:+)

I find the order of iteration in Python for comprehensions totally confusing every time. If you want to convert:

    for a in x: pass

into a comprehension, you write:

    [pass for a in x]

Simple, right? So to convert

    for a in x: for b in y: pass

I obviously write:

    [pass for b in y for a in x]

Bzzt. Nope, you have to write it in middle-endian order to get the same behaviour.

FYI, you can leave off the square brackets for a small performance boost. That turns it from a list comprehension into a generator expression, which is lazily evaluated and doesn't create a list container (which would immediately be thrown out anyway). It's like the difference between range(n) and xrange(n).

Nice, thanks for the tip.

Reply on news.ycombinator.com