4 ms·

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 b

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.

rtpg 10y ago
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.
barrkel 10y ago
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.
- CuriouslyC 10y ago
  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.

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.

rtpg 10y ago

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.

barrkel 10y ago

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.

CuriouslyC 10y ago
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.