Re: about sort and dictionary
[EMAIL PROTECTED] wrote: do things right is my fundamental beef with Python. Dispite claims, I don't believe Python's designers have a monopoly on the definition of right. This hammer is stupid. It's very uncomfortable, and it's not hard and heavy enough to get the nails into the wall. It will work better if you hold it in the other end. Don't tell me how to hold my hammer. It's just built wrong. This cold and hard thing should be in the other end! ;^) Seriously, it's not a matter of right or wrong. It's a matter of trying to understand how a tool is intended to be used, and to adjust to that. I'm not saying that all Python programmers should be some kind of Guido clones, there's plenty of room for variation, but it usually pays to be adaptable. Python fits my brain. I felt that from the start. YMMV. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Alex Martelli wrote: I think you mean volatile or mutable rather than transient? transient is not a keyword in C++, while both volatile and mutable are, with different semantics. Anyway, C++'s 'const' is a mess both theoretical AND practical. I'm told Ruby's object-freezing works better (but I have no practical experience). Right, volatile it is. It's really great that I can program so much Python now that I forget my C++! :) Thanks Alex (both for reminding me of forgotten C++ syntax and for making Python better). Perhaps we need a.reverse? for just-mutating-a-little reverse as well? ;^) I don't see the alleged humor in this ill-defined concept. I've run into a lot of cases where things are conceptually non-mutating, but in implementation, there are lots of internal state changes. For instance, we can imagine lazy get methods (or why not attributes) for database access. From the users perspective, it might not matter when things are actually fetched from the database if the Python code looks like this: p = myDB.getPerson(person_id) # Perhaps fetch here. ... print p.name # Or fetch here. It's pretty common that we avoid fetching stuff from a database until we really need it, so accessing p.name, might well be the event that triggers fetching all the relevant columns in the person-table for key value person_id. That technically mutates p, but does the user of p need to be aware of that? Maybe, maybe not. I guess it depends. How are transactions and multi user issues handled? Will p.name lock a database row? While simple warning signs might be useful at times, I find that the devil is in the details, and most programming problems are too subtle to be described with an exclamation mark. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka [EMAIL PROTECTED] wrote: ... I think you mean volatile or mutable rather than transient? transient ... Right, volatile it is. It's really great that I can program so much Python now that I forget my C++! :) Thanks Alex (both for reminding me of forgotten C++ syntax and for making Python better). Heh, you're welcome. Hadn't done anything much with C++ for almost five years, but found out (to my surprise, wouldn't have predicted it!) that it all comes back to me effortlessly (I might put it down to working with Matt Austern, but what we did together at Google wasn't C++...;-). My _perl_, OTOH, *has* gone all fuzzy... go figure! (Guess I have a C++-shaped mind rather than a perl-shaped one, FWIW:-). I've run into a lot of cases where things are conceptually non-mutating, but in implementation, there are lots of internal state changes. For Sure, caching and just in time computation are common. That is basically the difference between interface and implementation, and the distinction in C++ between logically const and physically const (but that doesn't really work right, either, for different reasons). While simple warning signs might be useful at times, I find that the devil is in the details, and most programming problems are too subtle to be described with an exclamation mark. Problems, yes; method names, not necessarily. Being able to assert that X==X' (using the X' notation to mean X before the call) does have expressive power; this leaves all the needed leeway to change implementation as long as it touches hidden state only. Thread safety and atomicity are really quite different issues, just like for any class invariant. If there's a class invariant P(), that means that P(X') [before the call] and P(X) [after it] both hold, but the word invariant does *NOT* mean that P holds invariably DURING the execution of X's methods, so class invariants cannot be used to infer threadsafety, much less atomicity -- that would constrain the implementation of the method WAY too much in the general case. (_Callbacks_ from a method to generic callables passed from the outside can be a headache -- there's no general theory as to what should hold while an external callback executes... though I'm in the camp claiming that invariants SHOULD hold at that time, I understand the debate). I don't think these headaches and difficulties justify dumping the whole field of reasoning about programs, nor the subfield of PbC. The concept of immutable is really just a tiny corner of these fields, and it's a long way from being the hardest or most problematic one in them;-). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka [EMAIL PROTECTED] writes: As I understand it, Ruby's ! isn't quite like procedure in Pascal, or not const in C/C++, but rather a marker for surprising behaviour, In my experience, ! is used in Ruby much the same way as it is in Scheme, signifying that a method/function is called only for side effects. (Similar to a void function in C.) -- Björn Lindström [EMAIL PROTECTED] Student of computational linguistics, Uppsala University, Sweden -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Alex Martelli wrote: I don't think these headaches and difficulties justify dumping the whole field of reasoning about programs, nor the subfield of PbC. The concept of immutable is really just a tiny corner of these fields, and it's a long way from being the hardest or most problematic one in them;-). Agreed. I also think that it's good practice to make methods do *one* thing, so when methods grow into both changing state and returning some substantial value, I usually split them. While the distinction between functions and procedures to speak Pascalese is a useful guidline at times, it's still a generalization though, and I doubt that it's very useful to have a syntactic marker for this distinction such as e.g. Pascal has. As I understand it, Ruby's ! isn't quite like procedure in Pascal, or not const in C/C++, but rather a marker for surprising behaviour, and while it might be wise to acknowledge that not all APIs are perfect, it seems difficult to know where mutating behaviour will surprise users. It seems to me that different programmers have different expectations on such things, and stumble over completely different things... -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka [EMAIL PROTECTED] wrote: Alex Martelli wrote: I don't think these headaches and difficulties justify dumping the whole field of reasoning about programs, nor the subfield of PbC. The concept of immutable is really just a tiny corner of these fields, and it's a long way from being the hardest or most problematic one in them;-). Agreed. I also think that it's good practice to make methods do *one* thing, so when methods grow into both changing state and returning some substantial value, I usually split them. While the distinction between functions and procedures to speak Pascalese is a useful guidline at times, it's still a generalization though, and I doubt that it's very useful to have a syntactic marker for this distinction such as e.g. Pascal has. The distinction is theoretically nice, but pragmatically it can get in your way when a result is a natural side effect of the state change. As a (perhaps overly) simple example, heapq.heapreplace is very natural for some use cases of heaps as priority queues, and frequent enough that having to replace it throughout with result = heapq.heappop... heapq.heappush... return result would be mildly annoying. At the other extreme, if Queue.Queue.get couldn't BOTH alter queue state (remove one item) AND return the removed item, within one threadsafe (atomic) operation, that would be way more than just annoying... it would just about destroy the usefulness of Queue.Queue! Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: OKB (not okblacke) wrote: Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: [ ... ] so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? Yes. The unintuitive thing is that the list is sorted in place at all. intuitive seems to be a very subjective matter, depends on once background etc :-) A quick straw-poll of some non-Pythonistas (two sysadmins, two programmers) suggests that reversing in place is unintuitive -- all four expected: 3 2 1 3 2 1 as suggested by Fredrik. It was less clear-cut, talking through it, whether they found sorting inplace was intuitive or not, but it was agreed that it would be odd if sort() and reverse() behaved differently. All of which is to say I'm convinced by the current behaviour: 1. sort() in place makes sense in terms of space, and is not completely unintuitive. 2. reverse() should do what sort() does. 3. The inexperienced user is most likely to expect the above code to print 3 2 1 3 2 1, and is more likely to have difficulty tracking down the problem if reverse() returns self and they get unexpected results than if it returns None and they get a TypeError: iteration over non-sequence. -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | Frankly I have no feelings towards penguins one way or the other \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Sion Arrowsmith wrote: 1. sort() in place makes sense in terms of space, and is not completely unintuitive. 2. reverse() should do what sort() does. 3. The inexperienced user is most likely to expect the above code to print 3 2 1 3 2 1, and is more likely to have difficulty tracking down the problem if reverse() returns self and they get unexpected results than if it returns None and they get a TypeError: iteration over non-sequence. In other words, the None is used as a you are guranteed to get error when you loop it, assuming you don't read the documentation and don't do the simple trial and error in the interactive shell before doing real thing and would read the manual afterwards then found out sort()/reverse() is in place. That as a way to teach, never thought about that kind of intend. But isn't develop by test the general preference ? If that is the case, a unit test would definitely catch the error and I doubt tracking down the error is that hard. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: a reminder that the change is inplace. How arrogant! While I'm sure the designers had kindly intentions. my memory, though bad, is not that bad, and I object to being forced to write code that is more clunky than need be, because the designers thought they needed to help me with my memory. Such as being arm-twisted into writing horrible things like x = sorted(l) instead of x = l.sort()? It sounds a bit as if someone locked you into a cellar and forced you to program Python, just to torture you. I guess the next step will be the comfy armchair! ;) Python has its roots in ABC, a language intended for teaching programming to beginners, and it goes to great lengths to make it easy to do things right. In my opinion, it also avoids the mistake of introducing hurdles in a vain attempts to prevent programmer mistakes. Such hurdles typically lead to ugly workarounds. There are a few cases when things don't work as some people would expect them to work, but I think there are good resons for that. I'm surprised that you don't complain about not being able to do while x = f(): ... while you're at it. That's also a restriction of the kind you seem to rebel against. I'm pretty sure Guido didn't think a bit about *your* memory capacity when he designed Python, but rather wanted to avoid spending his and other programmers' time on helping people with yet another set of silly bugs. There is much about Perl's rich functionality that is very worthy. Unfortunately, as you know, it's syntax leaves a lot to be desired. Which is mainly a consequence of TMTOWTDI... If you want something more perlish, but with somewhat more sane syntax, you might want to try Ruby. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: Alex Martelli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... intuitive seems to be a very subjective matter, depends on once background etc :-) That's a strong point of Ruby, actually -- allowing an exclamation mark at the end of a method name, which conventionally is always used to indicate that the method is a mutator. So, you can have a.reverse [NOT mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much of a change even for Python 3000, alas... but, it DOES make it obvious when an object's getting mutated, and when not... Except when it isn't obvious. What constitutes mutation of an object? C++ handles this with 'const', and lets the programmer cheat by using transient member variables, since there are cases when you actually want to mutate objects a little, but claim that you don't... Perhaps we need a.reverse? for just-mutating-a-little reverse as well? ;^) -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka [EMAIL PROTECTED] wrote: ... indicate that the method is a mutator. So, you can have a.reverse [NOT mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much of a change even for Python 3000, alas... but, it DOES make it obvious when an object's getting mutated, and when not... Except when it isn't obvious. What constitutes mutation of an object? Potential alteration of the object's state. [2,2,2] -- a list with three identical items -- may be subject to any permutation in-place, including sorting and reversing, without _actual_ alteration of state, just as, say, L[2]=2 MAY happen not to alter state if L[2] was already 2 before the assignment. However, such corner cases do not constitute any deep conceptual blockage to the notion of mutation, any more than, say, the possibility of state being empty (e.g in an empty tuple) constitues any to the notion of state. I classify list and dict methods as mutating and non-mutating in the Nutshell, for example, and nobody's quibbled about their usefulness. If you want to get more formal, you can focus on the post-condition (either in programming-by-contract terms, or the more formal Hoare and Djikstra ideas that preceded Pbc) using X' to mean X as it was on entry: for any type T, a method M of T is said to be non-mutating iff, for any instance t of T, the strongest postcondition of calling M on t includes t == t' a method M is said to be mutating if it is not non-mutating Note how cleanly this deals (by delegating to ==, if you will;-) with the issue of whether 'non-observable state' (e.g. a cache) counts as state (answer: if it cannot influence the result of == it does not matter regarding this definition). Objects which cannot be compared for equality with their peers, or for which it is conceptually absurd to talk of as it was, are always going to be problematic for any system of formal reasoning about programming, but the problem is with the formalization under such conditions (it's hard to do most any formal reasoning without equality, for example) and not with the pragmatics of the situation. C++ handles this with 'const', and lets the programmer cheat by using transient member variables, since there are cases when you actually want to mutate objects a little, but claim that you don't... I think you mean volatile or mutable rather than transient? transient is not a keyword in C++, while both volatile and mutable are, with different semantics. Anyway, C++'s 'const' is a mess both theoretical AND practical. I'm told Ruby's object-freezing works better (but I have no practical experience). Perhaps we need a.reverse? for just-mutating-a-little reverse as well? ;^) I don't see the alleged humor in this ill-defined concept. Anyway, a trailing question mark is used in Ruby to indicate a predicate (a non mutator which returns a boolean result); a convention similar to that of exclamation for mutators, though not quite as important IMHO. I do see some nice symmetry, supposing for example that S is a mutable string, in being able to name some of S's methods as: upper return an uppercased copy of S, not mutating S upper! mutate S in-place to be uppercased upper? return True iff S is already uppercased, not mutating S but (maybe because I have no extensive Ruby real-life experience) the predicate case, while nice, doesn't seem compelling to me (having to name it, say, isupper, doesn't appear to cause practical problems). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka: Except when it isn't obvious. What constitutes mutation of an object? C++ handles this with 'const', and lets the programmer cheat by using transient member variables, since there are cases when you actually want to mutate objects a little, but claim that you don't... Ruby uses '!' not for mutation but to indicate surprising or destructive mutation. If it was placed on all mutators, code would be full of '!'s. '!' is less common on methods that modify the receiver than on methods that mutate other arguments. There was a recent thread on this in c.l.ruby Array#insert, starting 8 posts down. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka wrote: [EMAIL PROTECTED] wrote: a reminder that the change is inplace. How arrogant! While I'm sure the designers had kindly intentions. my memory, though bad, is not that bad, and I object to being forced to write code that is more clunky than need be, because the designers thought they needed to help me with my memory. Such as being arm-twisted into writing horrible things like x = sorted(l) instead of x = l.sort()? The first statement is not the same as the second. It sounds a bit as if someone locked you into a cellar and forced you to program Python, just to torture you. I guess the next step will be the comfy armchair! ;) Python has its roots in ABC, a language intended for teaching programming to beginners, and it goes to great lengths to make it easy to do things right. In my opinion, do things right is my fundamental beef with Python. Dispite claims, I don't believe Python's designers have a monopoly on the definition of right. it also avoids the mistake of introducing hurdles in a vain attempts to prevent programmer mistakes. Such hurdles typically lead to ugly workarounds. There are a few cases when things don't work as some people would expect them to work, but I think there are good resons for that. I'm surprised that you don't complain about not being able to do while x = f(): ... while you're at it. That's also a restriction of the kind you seem to rebel against. I would have but fortunately the introduction of iterators spared you from having to read about that :-) I'm pretty sure Guido didn't think a bit about *your* memory capacity when he designed Python, but rather wanted to avoid spending his and other programmers' time on helping people with yet another set of silly bugs. I serious doubt sort's return value of lack thereof made any measurable difference in the time spent helping people. There is much about Perl's rich functionality that is very worthy. Unfortunately, as you know, it's syntax leaves a lot to be desired. Which is mainly a consequence of TMTOWTDI... If you want something more perlish, but with somewhat more sane syntax, you might want to try Ruby. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Neil Hodgson [EMAIL PROTECTED] wrote: Magnus Lycka: Except when it isn't obvious. What constitutes mutation of an object? C++ handles this with 'const', and lets the programmer cheat by using transient member variables, since there are cases when you actually want to mutate objects a little, but claim that you don't... Ruby uses '!' not for mutation but to indicate surprising or destructive mutation. If it was placed on all mutators, code would be full of '!'s. '!' is less common on methods that modify the receiver than on methods that mutate other arguments. Thanks for the clarification! Unfortunately, this variation on the convention does make it substantially less clear/sharp/well-defined, and therefore less useful; whenever I call a mutator I must memorize or work out (or guess) whether the author considered its mutation surprising or destructive to know whether I need to append a bang or not, which is peeving; so, I'm now happily reconciled to Python never adopting this. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: do things right is my fundamental beef with Python. Dispite claims, I don't believe Python's designers have a monopoly on the definition of right. I think raymond's post more correctly described it. Rather than do things right, it is more the world view of python, just that it has been pushed too far in certain situation(mostly unconciously) and turning it into a holy war. We seem to see it every where, not just about a programming language though. it also avoids the mistake of introducing hurdles in a vain attempts to prevent programmer mistakes. Such hurdles typically lead to ugly workarounds. There are a few cases when things don't work as some people would expect them to work, but I think there are good resons for that. I'm surprised that you don't complain about not being able to do while x = f(): ... while you're at it. That's also a restriction of the kind you seem to rebel against. I would have but fortunately the introduction of iterators spared you from having to read about that :-) Exactly, it is the functionality, not syntax that matters. if-then-else vs then-if-else, does it really matter other than proving one is righter ? I'm pretty sure Guido didn't think a bit about *your* memory capacity when he designed Python, but rather wanted to avoid spending his and other programmers' time on helping people with yet another set of silly bugs. I serious doubt sort's return value of lack thereof made any measurable difference in the time spent helping people. I kind of understand the rationale behind it now, thanks to another post. I think the argument is that Python is intended for people without prior programming experience and that the current behaviour is more intuitive(people expect 321321 in the example case), how that conclusion is drawn I have no idea but could be valid. The real life situation though is, Python is usually not the first language one learns and the net result is that one has to unlearn/wash away what is learnt to appreciate the pythonic way. But that since we never has a chance of this from pure to python, we would never appreciate that as we already know things about mutable/immutable object. Thereful, we would not make the mistake of expecting 321321 and thus no chance to appreciate the oops, what is this not a iterable error, let me lookup the manual saga. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] (Alex Martelli) writes: Neil Hodgson [EMAIL PROTECTED] wrote: Ruby uses '!' not for mutation but to indicate surprising or destructive mutation. If it was placed on all mutators, code would be full of '!'s. '!' is less common on methods that modify the receiver than on methods that mutate other arguments. Thanks for the clarification! Unfortunately, this variation on the convention does make it substantially less clear/sharp/well-defined, and therefore less useful; For the record, the ! convention (and the ? convention) are used by scheme, where it is used to indiciation mutation (and a predicate). Of course, scheme isn't OO, and is functional, so that mutation is the exception rather than the rule. mke -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka wrote: Actually, I guess it's possible that sorted() is done so that it works like below, but I don't think pre-sorted() versions of Python support keyword arguments to list.sort() anyway... def sorted(l, *p, **kw): s=l[:];s.sort(*p, **kw);return s One part you missed, sorted is actually closer to: def sorted(iterable, cmp=None, key=None, reverse=False): sorted(iterable, cmp=None, key=None, reverse=False) -- new sorted list s=list(iterable) s.sort(cmp, key, reverse) return s The point being that while in general only a list will have a sort method, the sorted builtin may be called on any iterable and will return a sorted list. Also note that it only accepts specific named arguments, and has a docstring. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Magnus Lycka wrote: sorted_l = l.sort() and while sorted_l would contain what one might expect, it would in fact just be another name referencing exactly the same sorted list as l, and it would probably be surprising that l was also sorted, and that subsequent changes would show up in both sorted_l and l, and that sorted_l might not be sorted and longer even though you only modified l. It's this particular gotcha that the language creator wanted to avoid. Since python's '=' is just name binding and that most objects(other than those like int/float/string?) are mutable, I don't quite understand why this is a gotcha that is so worrying. a = [1,2,3] a.sorted() b = a even an entry level python programmer can't expect 'b' to be unchanged(after getting the first bite may be) if there is any operation on a later. This not only applies to list but almost all mutable object. As you said, if one wants a copy of an object, use copy/deepcopy or even pickle to get a snapshot of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? I have no idea. That is my expectation. I don't know yours. My interpretation of it is : a got reversed then I consume it one by one a got reversed again then I consume it one by one Because I expect a being a mutable object, anything works on it(not just object method, but even other functions) is by default has side effect, unless otherwise stated, like copy/deepcopy. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 As for your other comment, I don't even understand them. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: Since python's '=' is just name binding and that most objects(other than those like int/float/string?) are mutable, I don't quite understand why this is a gotcha that is so worrying. a = [1,2,3] a.sorted() b = a even an entry level python programmer can't expect 'b' to be unchanged(after getting the first bite may be) if there is any operation on a later. This not only applies to list but almost all mutable object. so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item (as the X people used to say, the only thing worse than generalizing from one example (sort) is generalizing from no examples at all (let's assume I have a use case)). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? Still don't see why even you ask it again. May be you can enlight me a bit. If this is Haskell, I would expect the result you posted. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Still don't see why even you ask it again. fyi, I'm not [EMAIL PROTECTED] , and I've never, as far I know, posted from readfreenews.net /F -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: Still don't see why even you ask it again. fyi, I'm not [EMAIL PROTECTED] , and I've never, as far I know, posted from readfreenews.net I have no idea what you are talking about. I read this list through Google's group and I saw two of the same post. Google unfortunately just should your name Fredrik Lundh, may be something went wrong with the service. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? I am not a complete newb at python, but I am still pretty new. I too thought immediately that the output should be 3,2,1, 1,2,3. I used reverse() and sort() a couple time and of course read the docs before I did. I noted they do the change inplace, and don't find rememering that to be a terrible burden. Actually, I get rather annoyed by the comment that they return None as a reminder that the change is inplace. How arrogant! While I'm sure the designers had kindly intentions. my memory, though bad, is not that bad, and I object to being forced to write code that is more clunky than need be, because the designers thought they needed to help me with my memory. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
On Tue, 22 Nov 2005 08:53:07 -0800, rurpy wrote: I am not a complete newb at python, but I am still pretty new. I too thought immediately that the output should be 3,2,1, 1,2,3. What you are saying is that a.reverse() should *both* change a in place *and* return a reference to the same list. I used reverse() and sort() a couple time and of course read the docs before I did. I noted they do the change inplace, and don't find rememering that to be a terrible burden. Actually, I get rather annoyed by the comment that they return None as a reminder that the change is inplace. How arrogant! While I'm sure the designers had kindly intentions. my memory, though bad, is not that bad, and I object to being forced to write code that is more clunky than need be, because the designers thought they needed to help me with my memory. Built-in methods with side-effects (sort, reverse, update, clear, etc.) return None because every function must return something, not because it is a reminder. Python is not Pascal, and there are no procedures. There are four possibilities for a construction like list.sort(): (1) sort the list in place and return a reference to the same list; (2) sort the list in place and return a copy of the same list; (3) sort the list in place and return None; (4) don't sort in place and return a sorted list. No solution is always right, no solution is always wrong, but the most flexible is a combination of (3) and (4). Python now has that with sort() and sorted(). Prior to the addition of sorted() to the language, (3) was considered the best solution because of a simple Python principle: never duplicate objects unless explicitly told to. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? Yes. The unintuitive thing is that the list is sorted in place at all. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Steven D'Aprano wrote: There are four possibilities for a construction like list.sort(): (1) sort the list in place and return a reference to the same list; (2) sort the list in place and return a copy of the same list; (3) sort the list in place and return None; (4) don't sort in place and return a sorted list. No solution is always right, no solution is always wrong, but the most flexible is a combination of (3) and (4). Python now has that with sort() and sorted(). Prior to the addition of sorted() to the language, (3) was considered the best solution because of a simple Python principle: never duplicate objects unless explicitly told to. I don't see the reason that (3) and (4) are the most flexible. Again, never duplicate objects unless explicitly told to combined with = is name binding gives me a very strong message that list.sort() it will change things in place and which is why it is quite natural(for me at least) 3 2 1 1 2 3 for this language. Wether it is best or make more sense doesn't really matter to me, though I am curious to know why. But basically, I just use the language as it is, and the way I want to. So long it solves my problem and gives me the result I want. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
OKB (not okblacke) wrote: Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: so what would an entry-level Python programmer expect from this piece of code? for item in a.reverse(): print item for item in a.reverse(): print item I would expect it to first print a in reverse then a as it was. a=[1,2,3] I expect it to print 3 2 1 1 2 3 really? wouldn't 3 2 1 3 2 1 make a lot more sense ? Yes. The unintuitive thing is that the list is sorted in place at all. intuitive seems to be a very subjective matter, depends on once background etc :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Steven D'Aprano [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 22 Nov 2005 08:53:07 -0800, rurpy wrote: I am not a complete newb at python, but I am still pretty new. I too thought immediately that the output should be 3,2,1, 1,2,3. What you are saying is that a.reverse() should *both* change a in place *and* return a reference to the same list. Yes. I don't see a problem with this. I used reverse() and sort() a couple time and of course read the docs before I did. I noted they do the change inplace, and don't find rememering that to be a terrible burden. Actually, I get rather annoyed by the comment that they return None as a reminder that the change is inplace. How arrogant! While I'm sure the designers had kindly intentions. my memory, though bad, is not that bad, and I object to being forced to write code that is more clunky than need be, because the designers thought they needed to help me with my memory. Built-in methods with side-effects (sort, reverse, update, clear, etc.) return None because every function must return something, not because it is a reminder. Python is not Pascal, and there are no procedures. Quoting directly from the Library Reference: To remind you that they operate by side effect, they don't return the sorted or reversed list. There are four possibilities for a construction like list.sort(): (1) sort the list in place and return a reference to the same list; (2) sort the list in place and return a copy of the same list; (3) sort the list in place and return None; (4) don't sort in place and return a sorted list. No solution is always right, no solution is always wrong, but the most flexible is a combination of (3) and (4). Python now has that with sort() and sorted(). Prior to the addition of sorted() to the language, (3) was considered the best solution because of a simple Python principle: never duplicate objects unless explicitly told to. #2 makes no sense. I see the primary difference as inplace or copy sort, and the return value as a secondary issue: (1) Leave orignal list alone and sort a copy. Obviously this has to return a reference to that copy. (2) Sort list in place and... (2a) Don't return anything (i.e. return None) (2b) Return a reference to the list. (2b) is clearly the most flexible (of the inplace options) because it subsumes option (2a) -- if is you don't want to use the returned refernce for stylistic reasons, then don't. I think this is just another (admittedly minor) case of Python's designers using Python to enforce some idea of programming style purity. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] writes: I think this is just another (admittedly minor) case of Python's designers using Python to enforce some idea of programming style purity. You say that as if it were a bad thing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Mike Meyer wrote: [EMAIL PROTECTED] writes: I think this is just another (admittedly minor) case of Python's designers using Python to enforce some idea of programming style purity. You say that as if it were a bad thing. I would say interesting thing. As it seems that quite some people don't see the language as the creator or wants them to see it. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Mike Meyer wrote: [EMAIL PROTECTED] writes: I think this is just another (admittedly minor) case of Python's designers using Python to enforce some idea of programming style purity. You say that as if it were a bad thing. Well, there are many languages that promote a specific style of programming and many of the ideas developed have been incorporated in later, more general languages to good effect. But for a language that wants to be a general purpose language, yea, I guess I think it's bad. A general purpose language should strive to support as wide a varity of styles as possible. But this is getting rather off-topic. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... intuitive seems to be a very subjective matter, depends on once background etc :-) That's a strong point of Ruby, actually -- allowing an exclamation mark at the end of a method name, which conventionally is always used to indicate that the method is a mutator. So, you can have a.reverse [NOT mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much of a change even for Python 3000, alas... but, it DOES make it obvious when an object's getting mutated, and when not... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: ... language, yea, I guess I think it's bad. A general purpose language should strive to support as wide a varity of styles as possible. Definitely NOT Python's core design principle, indeed the reverse of it. But this is getting rather off-topic. Yep. If you disagree so deeply with Python's foundations, other language such as Perl, embodying just the striving you cherish, should probably make you much happier. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Alex Martelli wrote: [EMAIL PROTECTED] wrote: ... language, yea, I guess I think it's bad. A general purpose language should strive to support as wide a varity of styles as possible. Definitely NOT Python's core design principle, indeed the reverse of it. Priciples are fine if not carried to an extreme, as any examination of religous or political groups will show. But this is getting rather off-topic. Yep. If you disagree so deeply with Python's foundations, other language such as Perl, embodying just the striving you cherish, should probably make you much happier. There is much about Perl's rich functionality that is very worthy. Unfortunately, as you know, it's syntax leaves a lot to be desired. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Alex Martelli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... intuitive seems to be a very subjective matter, depends on once background etc :-) That's a strong point of Ruby, actually -- allowing an exclamation mark at the end of a method name, which conventionally is always used to indicate that the method is a mutator. So, you can have a.reverse [NOT mutating a since no !] _and_ a.reverse! [mutating a]. Probably too much of a change even for Python 3000, alas... but, it DOES make it obvious when an object's getting mutated, and when not... And I doubt if it should be added because of the history of python. As that would effectively mean changing the meaning of a function because of version, where old codes means differently for people who learn the new syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Alex Martelli wrote: [EMAIL PROTECTED] wrote: ... language, yea, I guess I think it's bad. A general purpose language should strive to support as wide a varity of styles as possible. Definitely NOT Python's core design principle, indeed the reverse of it. Priciples are fine if not carried to an extreme, as any examination of religous or political groups will show. But this is getting rather off-topic. Yep. If you disagree so deeply with Python's foundations, other language such as Perl, embodying just the striving you cherish, should probably make you much happier. There is much about Perl's rich functionality that is very worthy. Unfortunately, as you know, it's syntax leaves a lot to be desired. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: Steven D'Aprano wrote: There are four possibilities for a construction like list.sort(): (1) sort the list in place and return a reference to the same list; (2) sort the list in place and return a copy of the same list; (3) sort the list in place and return None; (4) don't sort in place and return a sorted list. No solution is always right, no solution is always wrong, but the most flexible is a combination of (3) and (4). Python now has that with sort() and sorted(). Prior to the addition of sorted() to the language, (3) was considered the best solution because of a simple Python principle: never duplicate objects unless explicitly told to. I don't see the reason that (3) and (4) are the most flexible. If you only want one copy of the data, sorted, you sort in place with (3). If you want two copies of the data, one sorted and one not sorted, you use solution (4). (2) fails the don't wastefully make a copy of data if it isn't needed test. (1) is sub-optimal because it introduces a dependency that isn't obvious. It not only modifies the list in place, but it creates a new reference to the same list. Expect to see lots of wasteful L = L.sort() lines by people who forget it sorts in place. Expect to see code like M = L.sort(); print L; print M by people who forget that M and L are both the same sorted list. Again, never duplicate objects unless explicitly told to combined with = is name binding gives me a very strong message that list.sort() it will change things in place and which is why it is quite natural(for me at least) Which is the behaviour of L.sort(). Did you think I was arguing against that? Heavens no -- I think sort() as it exists is the optimal solution. It isn't that difficult to say M = L[:]; M.sort() when you want a sorted copy. Having said that, since sorted() now exists, I'll happily use it. I just don't think it is necessary. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
[EMAIL PROTECTED] wrote: most built-in function/method don't return the object but None. This I believe is the language creator's preference for everything being explicit. The list methods .sort() and .reverse() don't create copies, but rather change the existing object. The reson for this is to save RAM. If you have 512MB RAM and a 300 MB list, it's nice that you can sort it without swapping virtual memory to disk. That would slow down the sort operation a lot, and that would be a shame, considering all the efforts that went into Python's excellent sort implementation. If you sort (or reverse) a list l, and don't need to keep the unsorted list, you simply do l.sort() (or l.reverse()). If you need to keep the original as well, you must make a copy before the sort, like this: sorted_l = l[:]; sorted_l.sort(). If the sort operation had returned self, it would have been easy to write: sorted_l = l.sort() and while sorted_l would contain what one might expect, it would in fact just be another name referencing exactly the same sorted list as l, and it would probably be surprising that l was also sorted, and that subsequent changes would show up in both sorted_l and l, and that sorted_l might not be sorted and longer even though you only modified l. It's this particular gotcha that the language creator wanted to avoid. With newer versions of Python, the builtin functions sorted() and reversed() have been added, so those who think it's ugly to call a list sorted before it actually *is* sorted, can simply write: sorted_l = sorted(l) With older Python's you need to do the hard work to add this to your program: def sorted(l): s=l[:];s.sort();return s def reversed(l): r=l[:];r.reverse();return r Actually, I guess it's possible that sorted() is done so that it works like below, but I don't think pre-sorted() versions of Python support keyword arguments to list.sort() anyway... def sorted(l, *p, **kw): s=l[:];s.sort(*p, **kw);return s -- http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Shi Mu wrote:
Got confused by the following code:
a
[6, 3, 1]
b
[4, 3, 1]
c
{1: [[6, 3, 1], [4, 3, 1]], 2: [[6, 3, 1]]}
c[2].append(b.sort())
c
{1: [[6, 3, 1], [1, 3, 4]], 2: [[6, 3, 1], None]}
#why c can not append the sorted b??
In python 2.4, you can use the sorted() builtin instead:
c[2].append(sorted(b))
George
--
http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Shi Mu wrote:
Got confused by the following code:
a
[6, 3, 1]
b
[4, 3, 1]
c
{1: [[6, 3, 1], [4, 3, 1]], 2: [[6, 3, 1]]}
c[2].append(b.sort())
c
{1: [[6, 3, 1], [1, 3, 4]], 2: [[6, 3, 1], None]}
#why c can not append the sorted b??
In python 2.4, you can use the sorted() builtin instead:
c[2].append(sorted(b))
George
--
http://mail.python.org/mailman/listinfo/python-list
about sort and dictionary
Got confused by the following code:
a
[6, 3, 1]
b
[4, 3, 1]
c
{1: [[6, 3, 1], [4, 3, 1]], 2: [[6, 3, 1]]}
c[2].append(b.sort())
c
{1: [[6, 3, 1], [1, 3, 4]], 2: [[6, 3, 1], None]}
#why c can not append the sorted b??
b.sort()
b
[1, 3, 4]
--
http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Shi Mu wrote:
Got confused by the following code:
a
[6, 3, 1]
b
[4, 3, 1]
c
{1: [[6, 3, 1], [4, 3, 1]], 2: [[6, 3, 1]]}
c[2].append(b.sort())
c
{1: [[6, 3, 1], [1, 3, 4]], 2: [[6, 3, 1], None]}
#why c can not append the sorted b??
b.sort()
b
[1, 3, 4]
most built-in function/method don't return the object but None. This
I believe is the language creator's preference for everything being
explicit. You better do it like this :
b.sort()
c[2].append(b)
Of course, this make things like this not possible :
obj.method_a().method_b().method_c()
But the language(and the community) in general discourage you to write
code like this ;-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: about sort and dictionary
Shi Mu [EMAIL PROTECTED] writes: #why c can not append the sorted b?? Because sort() doesn't return anything? According to the library reference: 7) The sort() and reverse() methods modify the list in place for economy of space when sorting or reversing a large list. To remind you that they operate by side effect, they don't return the sorted or reversed list. -- Eric Jacoboni, ne il y a 1435934131 secondes -- http://mail.python.org/mailman/listinfo/python-list
