21–30 of 37 posts
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.
Earlier quoted context omitted.
You've invented your own incompatible dialect of python. You've broken composition, objects and the general design choices of python. 1. You break Composition Your magic flag within a list changes all the semantics of the methods between immutable and mutable lists. > x = List([1,2,3]).saving() So now, if you're passed a list you have no idea if the operations you do will mutate the list. This breaks composition enti…
What is with all the hate lately on anyone who dares to write Python with different semantics than employed by the stdlib builtins? 'You've invented your own incompatible dialect of python. ' It isn't a "dialect." You don't need a different parser. There are no macros. It is simply a container with slightly different semantics than the stdlib ones. "You've broken composition, objects and the general design choices of…
Earlier quoted context omitted.
You've invented your own incompatible dialect of python. You've broken composition, objects and the general design choices of python. 1. You break Composition Your magic flag within a list changes all the semantics of the methods between immutable and mutable lists. > x = List([1,2,3]).saving() So now, if you're passed a list you have no idea if the operations you do will mutate the list. This breaks composition enti…
What is with all the hate lately on anyone who dares to write Python with different semantics than employed by the stdlib builtins? 'You've invented your own incompatible dialect of python. ' It isn't a "dialect." You don't need a different parser. There are no macros. It is simply a container with slightly different semantics than the stdlib ones. "You've broken composition, objects and the general design choices of…
'people are allowed to write Python however they want.'
people are encouraged to write python other people understand.
Earlier quoted context omitted.
#1 the correct way to do it is to have the methods perform the same action on mutable and immutable objects. this is the only way to guarantee composition. you do not change the semantics of shared methods. #2 for both of these examples you give 'to use whatever you want' "".join(['a','b']) is how everyone else does it in python code. it isn't about things in the community being usable within your library, it is abou…
you seem to go a long way to reinvent python builtins like reverse() any() all() enumerate(), itertools and functors. another python style you violate is that mutable methods return None in general. from the outset you haven't made any attempt to learn python style. go and read the zen of python. I only picked on a handful of examples, but wait! theres more - almost every example on your page has a way to do it in py…
As you clearly showed, Python doesn't have an uniform syntax to deal with this paradigm. I.e. there are lots of different constructs and, as you said, common idioms or patterns. Have you already argued with a Java programmer saying that these 'Design Pattern' are just a limitation of the language.. whereas in Python you'd probably just use a simple Dict (or whatever)? I'm sure you did. I feel the same with the idioms and patterns.
See, in Clojure (And Arc, and even Ruby), there is an uniform syntax.. whereas in Python we've got itertools, list comprehension, builtins map/filter, random builtins functino such as sorted().
I have to agree with you that Moka is not Pythonic in the There's only one way to solve a problem as we add a new way. However, Moka was created because there was so much inconsistent alternatives..
However, Moka is Pythonic in how it behaves. God knows I could have use all nifty hacks to make it behaves magically.. but I chose to take the explicit route by overriding list/dict. I could have used string interpolation for function (See http://osteele.com/sources/javascript/functional/); but instead went the Pythonic way with standard lambda functions. Maybe you are right about the operator keywords shortcut (i.e. using List().keep(operator.eg) instead of List().keep(eg=); However, I still feel it was a way to make it even easier to integrate with existing tools from the stdlib.
Lastly, you said:
zen: flat is better than nested
> Dict(a=1, b=2).update(c=3).rem(lambda x, y: x=='a')
This, however, is nested: # Taken directly from the itertools stdlib page. next(islice(iterable, n, None, default)
# Here, this is not nested.. this is chained:
def logged_user(self):
return (self.users
.keep(User.is_logged)
.keep(lambda u: u.is_active)
.map(lambda x: User.objects.get(id=x)))Earlier quoted context omitted.
#1 the correct way to do it is to have the methods perform the same action on mutable and immutable objects. this is the only way to guarantee composition. you do not change the semantics of shared methods. #2 for both of these examples you give 'to use whatever you want' "".join(['a','b']) is how everyone else does it in python code. it isn't about things in the community being usable within your library, it is abou…
if you are inventing a new way to do existing things outside the idioms of the language there is no conceivable way you can claim to be pythonic. you are replacing the pythonic style with your own taste. don't confuse the two.
The idioms it introduces do clash with Python ones, but on the other hand, I've been learning Clojure lately and my Python code has more comprehensions than previously. I'm not sure what to think.
Earlier quoted context omitted.
Thanks for the feedback, these are interesting points. I'd like to clarify a couple of things about your #2 and #3. def user_logged(users): > return List(users).all(User.is_logged) # If you want per instance: def user_logged(users): > return List(users).all(lambda x: x.is_logged()) And, about the "".join; you are right. However, Moka's construct allow you to use whatever you want, i.e.: moka.List(['a', 'b']).do(strin…
#1 the correct way to do it is to have the methods perform the same action on mutable and immutable objects. this is the only way to guarantee composition. you do not change the semantics of shared methods. #2 for both of these examples you give 'to use whatever you want' "".join(['a','b']) is how everyone else does it in python code. it isn't about things in the community being usable within your library, it is abou…
you made some good points (particularly the fact that you lose dispatch by instance), but you don't need to keep jabbering away about the same points.
Earlier quoted context omitted.
you seem to go a long way to reinvent python builtins like reverse() any() all() enumerate(), itertools and functors. another python style you violate is that mutable methods return None in general. from the outset you haven't made any attempt to learn python style. go and read the zen of python. I only picked on a handful of examples, but wait! theres more - almost every example on your page has a way to do it in py…
Thanks for all the good points. To be honest, I'm not sure what you're trying to say. I've been coding in python for years and Moka was built from my annoyance using functional paradigms with the stdlib. As you clearly showed, Python doesn't have an uniform syntax to deal with this paradigm. I.e. there are lots of different constructs and, as you said, common idioms or patterns . Have you already argued with a Java p…
that was my point. if you think it is worthwhile, well - enjoy :-)
if you want to write in something with a uniform syntax, use scheme or clojure. python things look different for a reason.
Earlier quoted context omitted.
if you are inventing a new way to do existing things outside the idioms of the language there is no conceivable way you can claim to be pythonic. you are replacing the pythonic style with your own taste. don't confuse the two.
I'm not sure why you created a fake account to answer this but thanks again for your time. You're right that it was built for my own taste using simultaneously other languages (clojure, arc and js for instance). At the end of the day, what's important is that it increases the quality of the code and this is my goal with Moka. This is still in an alpha stage, but I'll definitely tweak it based on good feedback (Like y…
Re-inventing a uniform syntax for python is the least pythonic thing you can do.
Earlier quoted context omitted.
#1 the correct way to do it is to have the methods perform the same action on mutable and immutable objects. this is the only way to guarantee composition. you do not change the semantics of shared methods. #2 for both of these examples you give 'to use whatever you want' "".join(['a','b']) is how everyone else does it in python code. it isn't about things in the community being usable within your library, it is abou…
give it a break. sure, we should be pythonic when we're programming at work and our code is likely to be maintained by others. but there's absolutely nothing wrong with pushing boundaries and learning by exploring and even - shock - getting things wrong. you made some good points (particularly the fact that you lose dispatch by instance), but you don't need to keep jabbering away about the same points.
I am banging on about a lot of the points because it seems very hard to explain to him that using clojure/arc/jquery styles is very very unpythonic.