5 ms·

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

by tef____ 15y ago

#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 about your library being /unusable/ within the community. You re-invent new and awkward ways to do standard things without standard idioms. 'i've just invented a whole bunch of new semantics for things so it will be readable' readability is about /convention/. readable to whom? pushing your own love of jquery method chaining only serves to ostracise those already somewhat knowledgable within python. it is not pythonic in any way shape of form.

tef____ 15y ago
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.
- phzbOx 15y ago
  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 yours) Feel free to drop me a line: phzbox at gmail if you want to continue this discussion.
  - tef____ 15y ago
    I'm not sure why you accuse me of having a fake account? Re-inventing a uniform syntax for python is the least pythonic thing you can do.
  - sashahart 15y ago
    It's totally legitimate for you to write this according to your own taste and use it. I don't think it's bad for Python, or anything like that. You are not an idiot and I am sure you can write interesting and useful programs in Python. But I do agree that it is not 'Pythonic' - except maybe in the trivial sense that it's written in Python. I would be happy to go into more detail if you really want it.
tef____ 15y ago
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 python. that other python developers use and understand. #chaining example: you say 'we believe chaining constructs are easier to read and maintain than deeply nested expressions.' zen: flat is better than nested > Dict(a=1, b=2).update(c=3).rem(lambda x, y: x=='a') becomes > d = dict(a=1, b=2) > d['c'] = 3 > del d['a'] #'partial application' example > List([1,2,3]).map(string.zfill, 8, _) becomes > [str(i).zfill(8) for i in [1,2,3]) # magic argument names zen: 'explcit is better than implicit' different methods have different magic attached: it isn't obvious from the outset why update takes named args but keep takes args are named operators > List([1,2,3]).keep(gt=1) becomes > [x for x in [1,2,3] if x > 1] # you reinvent all > List(range(1,10)).all(lambda x: x < 100)) becomes > all(x < 100 for x in range(1,10)) # 'compact' example > List([None, 0, 2, []]).compact() becomes > [x for x in [None, 0 , 2, []] if x] # 'list is empty' example > List([]).empty() becomes > bool([]) # 'sort' > List([5,3,1]).sort() becomes > sorted([5,3,1]) 'uniq' > List([1,1,2,3,2,1]).uniq().sort() becomes > collections.Counter([1,1,2,3,2,1]) for every example you give, there is an equivalent piece of python code to do it, designed in mind with the rest of python. the built in operations give you flexible control over the evaluation too - you can have generator expressions and list expressions. many iterable versions of the standard operators exist in itertools. really, this is the least pythonic thing since ruby came out. it seems I can only spell this out to you by elaborating through your jquery library and presenting you with python code python developers understand. please stop re-inventing python without trying to understand why it looks that way first.
- phzbOx 15y ago
  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 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/ 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 is not nested, this is chained. 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)))
andrewcooke 15y ago
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.
- tef____ 15y ago
  writing your own dialect of the language can be fun, but he is presenting his own style as 'pythonic' as opposed to the actual pythonic style built from functional composition - rather than method chaining. 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.

by tef____ 15y ago

tef____ 15y ago

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.

phzbOx 15y ago
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 yours) Feel free to drop me a line: phzbox at gmail if you want to continue this discussion.
- tef____ 15y ago
  I'm not sure why you accuse me of having a fake account? Re-inventing a uniform syntax for python is the least pythonic thing you can do.
- sashahart 15y ago
  It's totally legitimate for you to write this according to your own taste and use it. I don't think it's bad for Python, or anything like that. You are not an idiot and I am sure you can write interesting and useful programs in Python. But I do agree that it is not 'Pythonic' - except maybe in the trivial sense that it's written in Python. I would be happy to go into more detail if you really want it.

tef____ 15y ago

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 python. that other python developers use and understand. #chaining example: you say 'we believe chaining constructs are easier to read and maintain than deeply nested expressions.' zen: flat is better than nested > Dict(a=1, b=2).update(c=3).rem(lambda x, y: x=='a') becomes > d = dict(a=1, b=2) > d['c'] = 3 > del d['a'] #'partial application' example > List([1,2,3]).map(string.zfill, 8, _) becomes > [str(i).zfill(8) for i in [1,2,3]) # magic argument names zen: 'explcit is better than implicit' different methods have different magic attached: it isn't obvious from the outset why update takes named args but keep takes args are named operators > List([1,2,3]).keep(gt=1) becomes > [x for x in [1,2,3] if x > 1] # you reinvent all > List(range(1,10)).all(lambda x: x < 100)) becomes > all(x < 100 for x in range(1,10)) # 'compact' example > List([None, 0, 2, []]).compact() becomes > [x for x in [None, 0 , 2, []] if x] # 'list is empty' example > List([]).empty() becomes > bool([]) # 'sort' > List([5,3,1]).sort() becomes > sorted([5,3,1]) 'uniq' > List([1,1,2,3,2,1]).uniq().sort() becomes > collections.Counter([1,1,2,3,2,1]) for every example you give, there is an equivalent piece of python code to do it, designed in mind with the rest of python. the built in operations give you flexible control over the evaluation too - you can have generator expressions and list expressions. many iterable versions of the standard operators exist in itertools. really, this is the least pythonic thing since ruby came out. it seems I can only spell this out to you by elaborating through your jquery library and presenting you with python code python developers understand. please stop re-inventing python without trying to understand why it looks that way first.

phzbOx 15y ago
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 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/ 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 is not nested, this is chained. 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)))

andrewcooke 15y ago

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.

tef____ 15y ago
writing your own dialect of the language can be fun, but he is presenting his own style as 'pythonic' as opposed to the actual pythonic style built from functional composition - rather than method chaining. 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.