Hacker News Reader

Comment by mattdeboard | Hacker News Reader

I like the concept in principle (being a fan of Clojure and in particular its threading macros), but I'm not sure this is something I'd ever use. Breaking language idioms and creating challenges for code readability for future maintainers doesn't seem to be worth the gains in novelty.

However if these semantics were brought into the core language I'd be very happy.

View on HN

(I'm the author of this module.)

Yeah, I admit part of me felt dirty implementing this by commandeering operators. But my brief time with Haskell and F# has biased me enough toward this style of function composition that I preferred to deal with the ugliness of my hack, rather than the ugliness of not being able to express certain functions in this style in my other toy projects. :)

I agree though, hopefully the language itself will support this one day, and then my ugly hack can go away. (I swear, Python always seems to stop just shy of being a fantastic little dynamic fp language...)

Thanks for the feedback!

I'd really love to see an operator for this in Python as well. I feel it's lacking.

Trust me I am right there with you; Haskell does a lot of really beautiful things. Python lifted its list comprehension syntax from Haskell, as a matter of fact. It is only that I consider it a core responsibility of programmers to take into consideration the poor sap who has to maintain their code once the original author gets hit by a truck or eaten by a shark.

Python's an object-based, highly dynamic, systems language. It's got a big set of builtins, a relatively large standard library, and is based around iteration and composition. It's not what I would consider a "little" or "fp" language. Sure, you can write pure, referentially-transparent units in Python, but sometimes you have to write things that set! attributes, and that's just a part of life.

Overloading these operators on function objects really isn't the end of the world. It's not like these operators were being used for anything, and sometimes this kind of DSL-ish extension can be good. It's certainly more reasonable than the goto module, which uses horrid bytecode hax to get the job done.

If you want this in the language, write to the python-ideas mailing list, and then draft a PEP if you get any support. Good luck!

> hopefully the language itself will support this one day, and then my ugly hack can go away.

+1 here, but I'm not holding my breath. Python's BFDL has been hostile to making lambda more powerful; I'm not sure what he would think about this.

I think the syntax is fine. The star operator already is sensitive to the operands, so you're not impairing readability at all.

It's a super neat hack; but if you use it in production you're completely crazy. I think it's intended that way.

Why is it crazy to use it in production?

There's going to be a lot of overhead with this kind of thing, but did you have another reason?

The simple answer is, go look at @partial's __call__: https://github.com/markshroyer/pointfree/blob/master/pointfr...

All that code is executing on every partial call. So, a very brief list of reasons not to use this in production:

1. overhead

2. complexity

3. debugging

4. don't fight the language

edited to add: I just want to emphasize that I think it's a really, really neat hack!

Because it deviates entirely from Python's semantics.

edit: In other words, "Don't fight the language" as another commenter said.

Interesting comment. It made me think how Lisp programmers spend their time extending their core language every time they use a macro. Does it mean that Lisp programming is about creating challenges for code readability for future maintainers? To be honest, I think Lisp programmers are just a different breed entirely.

Lisps are unique in their lack of syntax. Not fit for comparison to any other type of language. When you use a lisp language you know exactly what you're buying into.

Reply on news.ycombinator.com