Moka - Minimalist functional python library
1–10 of 37 posts
Re: Moka - Minimalist functional python library
#2You're definitely going to run into resistance from more hardcore Python guys I think, as it's very "unpythonic" but who cares ? I'll be curious to see everyone's reaction after the presention on Monday.
Re: Moka - Minimalist functional python library
#3Re: Moka - Minimalist functional python library
#4Re: Moka - Minimalist functional python library
#5Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.
Re: Moka - Minimalist functional python library
#6Clickable link for the doc: http://phzbox.com/moka/index.html Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.
also, maybe .mutable() would be better as a flag in the constructor. it makes no sense to use it in a chain (in fact, that could be confusing) and is the kind of thing you should probably fix on construction rather than changing later.
ps. it's not clear to me that this is better than list comprehensions, which already do much of what you have.
Re: Moka - Minimalist functional python library
#7This is pretty interesting looking. I'm tempted to try using it on my next project...anyone else used it yet? Seem stable/bug free?
Re: Moka - Minimalist functional python library
#8Clickable link for the doc: http://phzbox.com/moka/index.html Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.
two small suggestions: change .saving() to .mutable() and .rem() to .remove() (or filter(), reversing the semantics, since that is already in python) (every other method is a full word). also, maybe .mutable() would be better as a flag in the constructor. it makes no sense to use it in a chain (in fact, that could be confusing) and is the kind of thing you should probably fix on construction rather than changing late…
List is-a list, and Dict is-a dict.. and thus, I'd like to make it possible to safely pass these objects to already existing code. If I rename .rem to .remove, I'd break that.
The reason for the chaining saving() is because it's useful to be able to toggle it. For instance:
self.x = Moka.List(range(1,10)).mutable()
return (self.x.map(lambda x: x*2)
.immutable()
.keep(gt=5))
So, basically, you change self.x with the map, but don't necessarily want to change it with the keep().(I'm not saying it is the right thing, just why it's done that way.)
Re: Moka - Minimalist functional python library
#9Clickable link for the doc: http://phzbox.com/moka/index.html Moka is still in an alpha stage; but that being said, I'd love to hear some feedback. Feel free to browse the code, it should be pretty straightforward to any python dev.
[1] http://ruby-doc.org/core-1.9.3/Enumerable.html
[2] http://www.scala-lang.org/api/current/scala/collection/immut...
Re: Moka - Minimalist functional python library
#10Earlier quoted context omitted.
two small suggestions: change .saving() to .mutable() and .rem() to .remove() (or filter(), reversing the semantics, since that is already in python) (every other method is a full word). also, maybe .mutable() would be better as a flag in the constructor. it makes no sense to use it in a chain (in fact, that could be confusing) and is the kind of thing you should probably fix on construction rather than changing late…
Thanks for the feedback; I agree with you. Here's the reasoning behind these odds choice.. List is-a list, and Dict is-a dict.. and thus, I'd like to make it possible to safely pass these objects to already existing code. If I rename .rem to .remove, I'd break that. The reason for the chaining saving() is because it's useful to be able to toggle it. For instance: self.x = Moka.List(range(1,10)).mutable() return (self…