4 ms·

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 langu

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.

llimllib 15y ago
It's a super neat hack; but if you use it in production you're completely crazy. I think it's intended that way.
- tome 15y ago
  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?
  - llimllib 15y ago
    The simple answer is, go look at @partial's __call__: https://github.com/markshroyer/pointfree/blob/master/pointfree.py#L468 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!
  - mattdeboard 15y ago
    Because it deviates entirely from Python's semantics. edit: In other words, "Don't fight the language" as another commenter said.
Niten 15y ago
(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!
- nakkiel 15y ago
  I'd really love to see an operator for this in Python as well. I feel it's lacking.
- mattdeboard 15y ago
  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.
- MostAwesomeDude 15y ago
  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!
  - sinope 15y ago
    Python is most certainly not a systems language and if you think a PEP for this would go anywhere, you clearly don't know the devs very well either. Guido would never, ever allow anything like this into Python. Not when he's been campaigning to get rid of itertools.
- neilk 15y ago
  > 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.
nemoniac 15y ago
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.
- mattdeboard 15y ago
  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.

llimllib 15y ago

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

tome 15y ago
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?
- llimllib 15y ago
  The simple answer is, go look at @partial's __call__: https://github.com/markshroyer/pointfree/blob/master/pointfree.py#L468 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!
- mattdeboard 15y ago
  Because it deviates entirely from Python's semantics. edit: In other words, "Don't fight the language" as another commenter said.

Niten 15y ago

(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!

nakkiel 15y ago
I'd really love to see an operator for this in Python as well. I feel it's lacking.
mattdeboard 15y ago
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.
MostAwesomeDude 15y ago
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!
- sinope 15y ago
  Python is most certainly not a systems language and if you think a PEP for this would go anywhere, you clearly don't know the devs very well either. Guido would never, ever allow anything like this into Python. Not when he's been campaigning to get rid of itertools.
neilk 15y ago
> 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.

nemoniac 15y ago

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.

mattdeboard 15y ago
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.