4 ms·
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(u
by phzbOx 15y ago
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(string.join, '').last_value
Or, you can still use:
''.join(moka.List(['a', 'b']))
However, about the #1, I have to agree. I've added the saving() recently and had a bad taste about it. The right way to do it might be to make it mutable by default and only toggle it off in certain circumstances.
Please note that everything done by the community is still perfectly usable; in fact, it's even easier to use useful high-level functions.
I.e. map(str, range(1,10)) or List(range(1,10)).map(str); is syntactically different but does the same job.
- ScottBurson 15y agoYeah, get rid of saving(). Not only are the semantics dangerous and confusing, but the name suggests the opposite of what it actually does.
- 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 agoif 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 agoI'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 agoI'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 agoIt'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 agoyou 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.