Live data from Hacker News

Moka - Minimalist functional python library

github.com

1–10 of 37 posts

Re: Moka - Minimalist functional python library

#6
post #5

Clickable 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 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

#7
post #3

This is pretty interesting looking. I'm tempted to try using it on my next project...anyone else used it yet? Seem stable/bug free?

It's fairly new but feel free to browse the code; it should be pretty straightforward to you. I've tried to provide good examples to make it easy to learn/use on phzbox.com/moka/.

Re: Moka - Minimalist functional python library

#8
post #5

Clickable 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…

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.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

#9
post #5

Clickable 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.

A good source of inspiration: Ruby's Enumerable[1] and Scala's Iterable[2]. Toguether, they have one of the most complete functional collection methods library.

[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

#10
post #8

Earlier 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…

What if your mutation functions accepted a flag that set the saving behavior, and you used a sensible default?
Post reply on HN