Re: Question about idioms for clearing a list
Magnus Lycka wrote: > Bryan Olson wrote: > >> Magnus Lycka wrote: >> >>> Bryan Olson wrote: >>> big_union = set() for collection in some_iter: big_union.update(t) collection.clear() >>> >>> >>> I don't understand the second one. Where did 't' come from? >> >> >> Cut-and-past carelessness. Meant to update with 'collection'. > > > If some_iter gives you dicts, the code above will throw away > your values, and put the set of keys in big_union. Is that what > you meant to do? It can be quite useful. Python only recently added the set type. Previously, the usual way to implement sets with efficient membership testing was to use a dict where the keys map to some irrelevant value. The above will work for the old technique as well as for the set type. > I suspect most people would find this somewhat > surprising. For sets and "BryanLists" it will put a set of all > the contents of those collections in big_union. That was the description: moving everything from several collections into a single union. > I think this > just verifies my previous arguments. It's rarely meaningful to > write functions that are meaingful for all builtin collections. That's a nonsense argument, polymorphism doesn't have to work over every type to be useful. Functions meaningful for either sets or lists are common; that's enough justification for giving corresponding operations the same interface. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Bryan Olson wrote: > Magnus Lycka wrote: > >> Bryan Olson wrote: >>> big_union = set() >>> for collection in some_iter: >>> big_union.update(t) >>> collection.clear() >> >> I don't understand the second one. Where did 't' come from? > > Cut-and-past carelessness. Meant to update with 'collection'. If some_iter gives you dicts, the code above will throw away your values, and put the set of keys in big_union. Is that what you meant to do? I suspect most people would find this somewhat surprising. For sets and "BryanLists" it will put a set of all the contents of those collections in big_union. I think this just verifies my previous arguments. It's rarely meaningful to write functions that are meaingful for all builtin collections. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Raymond Hettinger wrote: [...] > If you're asking why list's don't have a clear() method, the answer is > that they already had two ways to do it (slice assignment and slice > deletion) and Guido must have valued API compactness over collection > polymorphism. That's a decision from long ago. Now that we have sets and the iterable protocol, the case is quite different. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
> > If you're asking why list's don't have a clear() method, the answer is > > that they already had two ways to do it (slice assignment and slice > > deletion) and Guido must have valued API compactness over collection > > polymorphism. The latter is also evidenced by set.add() vs > > list.append() and by the two pop() methods having a different > > signatures. [bonono] > Sounds to me that it is a preference(style, whatever), rather than some > other posts of this thread argued that "del L[:]" is better. It was simply design decision reflecting Guido's values on language economics. > > If you're asking why your specific case looked so painful, I suspect > > that it only looked hard because the adaptation was force-fit into a > > lambda (the del-statement or slice assignment won't work as an > > expression). You would have had similar difficulties embedding > > try/except logic or a print-statement. Guido, would of course > > recommend using a plain def-statement: > > > > L = list() > > def L_clearer(L=L): > > del L[:] > > for listbunch in buncher(src, '', L, L.append, L_clearer): > > print listbunch > > > Is that really "clearer" ? While it is still very localized(just read a > few lines up for the definition), buncher(src, '', L.append, L.clear) > seems to be clearer to me, especially there are two similar construct > on set/dict above, Hmm, my post was so long that the main points were lost: * the example was tricky only because of the unnecessary in-place update requirement * eliminating that requirement solves the adaptation problem and simplifies the client code * the constructor API is polymorphic, use it * adding clear() doesn't help with the other API variations between set, list, dict, etc. * Guido's decision for distinct APIs is intentional (i.e. set.add vs list.append) * Alex's adapter PEP is likely a better solution for forcing polymorphism on unlike APIs * When a lambda becomes awkward, Guido recommends a separate def * Guido has no sympathy for atrocities resulting from squeezing everything into one line * Alex's example can be simplified considerably: def buncher(sourceit, sentinel, constructor): for k, g in groupby(sourceit, lambda x: x != sentinel): if k: yield constructor(g) for setbunch in buncher(src, '', set): print setbunch * The improved version has no need for list.clear(). End of story. Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Magnus Lycka wrote: > Bryan Olson wrote: > >> Magnus Lycka wrote: >> >>> Do you really have a usecase for this? It seems to me that your >>> argument is pretty hollow. >> >> >> Sure: >> >> if item_triggering_end in collection: >> handle_end(whatever) >> collection.clear() >> >> Or maybe moving everything from several collections into >> a single union: >> >> big_union = set() >> for collection in some_iter: >> big_union.update(t) >> collection.clear() > > > I don't understand the second one. Where did 't' come from? Cut-and-past carelessness. Meant to update with 'collection'. > Anyway, tiny code snippets are hardly usecases. The task is the usecase. [...] > I still don't see any convincing usecase for the kind of > ducktyping you imply. I didn't say I could convince you. I said that when different types can support the same operation, they should also support the same interface. That's what enables polymorphism. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Magnus Lycka wrote: > >>> class BryansList(list): > ... add=list.append > ... def clear(self): > ... del self[:] > ... > >>> b = BryansList([1,2,3,4,5]) > >>> b > [1, 2, 3, 4, 5] > >>> b.add(6) > >>> b.clear() > >>> b > [] > > Happy now? You can keep it, I don't need it. :) > Most of us consider minimal interfaces a virtue. What kind of performance penalty are we talking about here ? list being such a fundamental thing, no one would like to use a slower version just for the clear/add method. And if it is a "use when you really need to", it would make the code harder to understand as it would be "sometimes it is BryansList, sometimes it is builtin list". That said, I don't find clear() to be useful as unless one needs to pass around a single copy of list object around and saved them for future use(which can be a source of subtle bug), just lst=[] is usually good enough for localized usage. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Bryan Olson wrote: > Magnus Lycka wrote: >> Do you really have a usecase for this? It seems to me that your >> argument is pretty hollow. > > Sure: > > if item_triggering_end in collection: > handle_end(whatever) > collection.clear() > > Or maybe moving everything from several collections into > a single union: > > big_union = set() > for collection in some_iter: > big_union.update(t) > collection.clear() I don't understand the second one. Where did 't' come from? Anyway, tiny code snippets are hardly usecases. Are these from real code? If they are, why aren't there support for emptying lists? Have you patched your Python? Didn't you actually need to support lists? I still don't see any convincing usecase for the kind of ducktyping you imply. There are certainly situations where people have used lists or dicts before there were sets in Python, and want to support both variants for a while at least, but since their APIs are so differnt for these types, .clear() seems like a non-issue. If this was a problem in the real world, I bet we'd see a lot of code with functions similar to this: def clear(container): try: del container[:] except TypeError: container.clear() If you *do* have this problem, this is a very simple workaround. >> As far as I understand, the only operation which is currently used >> by all three collections is .pop, but that takes a different number >> or parameters, since these collections are conceptually different! > > The all support len, iteration, and membership test. Ok. Forgot that. id(), str() and repr() as well. Still, after almost 10 years of Python programming I can't remember that I ever ran into a situation where I ever needed one single piece of code to empty an arbitrary container. It's trivial to solve, so I wouldn't have stopped to think about it for even a minute if it happened, but I still don't think it happened.This was never a problem for me, and I don't think I saw anyone else complain about it either, and I've seen plenty of complaints! ;) I can understand the argument about making it easy to remember how to perform an action. I think the current situation is correct. To introduce redunancy in this case (del x[:] <==> x.clear()) would not be an improvement of Python. In the long run, such a strategy of synonyms would make Python much more like Perl, and we don't want that. So I can understand that the question pops up though (but not why it gets such proportions). I don't buy this duck-typing argument though. Considering how little it would change in unifying these divergent APIs, it still sounds as hollow to me. > Many algorithms make sense for either sets or lists. Even if they > cannot work on every type of collection, that's no reason not > to help them be as general as logic allows. >>> class BryansList(list): ... add=list.append ... def clear(self): ... del self[:] ... >>> b = BryansList([1,2,3,4,5]) >>> b [1, 2, 3, 4, 5] >>> b.add(6) >>> b.clear() >>> b [] Happy now? You can keep it, I don't need it. :) Most of us consider minimal interfaces a virtue. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Raymond Hettinger wrote: > [Alex] > > So what is the rationale for having list SO much harder to use in such a > > way, than either set or collections.deque? > > Sounds like a loaded question ;-) > > If you're asking why list's don't have a clear() method, the answer is > that they already had two ways to do it (slice assignment and slice > deletion) and Guido must have valued API compactness over collection > polymorphism. The latter is also evidenced by set.add() vs > list.append() and by the two pop() methods having a different > signatures. Sounds to me that it is a preference(style, whatever), rather than some other posts of this thread argued that "del L[:]" is better. > > If you're asking why your specific case looked so painful, I suspect > that it only looked hard because the adaptation was force-fit into a > lambda (the del-statement or slice assignment won't work as an > expression). You would have had similar difficulties embedding > try/except logic or a print-statement. Guido, would of course > recommend using a plain def-statement: > > L = list() > def L_clearer(L=L): > del L[:] > for listbunch in buncher(src, '', L, L.append, L_clearer): > print listbunch > Is that really "clearer" ? While it is still very localized(just read a few lines up for the definition), buncher(src, '', L.append, L.clear) seems to be clearer to me, especially there are two similar construct on set/dict above, even the Alex's lambda form conveys more info, IMO. Usng the new partial function, may be it can be written as : buncher(src.'', L, L.append, partial(L.__delslice__, 0, sys.maxint)) #assuming list can have at at most maxint items. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
[Alex Martelli] > I was thinking of something different again, from a use case I did have: > > def buncher(sourceit, sentinel, container, adder, clearer): > for item in sourceit: > if item == sentinel: > yield container > clearer() > else > adder(item) > yield container > > s = set() > for setbunch in buncher(src, '', s, s.add, s.clear): ... I'm curious, what is the purpose of emptying and clearing the same container? ISTM that the for-loop's setbunch assignment would then be irrelevant since id(setbunch)==id(s). IOW, the generator return mechanism is not being used at all (as the yielded value is constant and known in advance to be identical to s). Just for jollies, I experimented with other ways to do the same thing: from itertools import chain, groupby def buncher(sourceit, sentinel, container, updater, clearer): # Variant 1: use iter() to do sentinel detection and # use updater() for fast, high volume updates/extensions it = iter(src) for item in it: updater(chain([item], iter(it.next, sentinel))) yield container clearer() s = set() for setbunch in buncher(src, '', s, s.update, s.clear): print setbunch, id(setbunch) def buncher(sourceit, sentinel, container, updater, clearer): # Variant 2: use groupby() to the bunching and # use updater() for fast, high volume updates/extensions for k, g in groupby(sourceit, lambda x: x != sentinel): if k: updater(g) yield container clearer() s = set() for setbunch in buncher(src, '', s, s.update, s.clear): print setbunch Of course, if you give-up the seemingly unimportant in-place update requirement, then all three versions get simpler to implement and call: def buncher(sourceit, sentinel, constructor): # Variant 3: return a new collection for each bunch for k, g in groupby(sourceit, lambda x: x != sentinel): if k: yield constructor(g) for setbunch in buncher(src, '', set): print setbunch Voila, the API is much simpler; there's no need initially create the destination container; and there's no need for adaptation functions because the constructor API's are polymorphic: constructor = list constructor = set constructor = dict.fromkeys [Alex] > d = dict() > for dictbunch in buncher(src, '', d, lambda x: d.setdefault(x,''), > d.clear): ... > > L = list() > for listbunch in buncher(src, '', L, L.append, > lambda: L.__setslice__(0,len(L),[])): ... Hmm, is your original buncher a candidate for adapters? For instance, could the buncher try to adapt any collection input to support its required API of generic adds, clears, updates, etc.? [Alex] > So what is the rationale for having list SO much harder to use in such a > way, than either set or collections.deque? Sounds like a loaded question ;-) If you're asking why list's don't have a clear() method, the answer is that they already had two ways to do it (slice assignment and slice deletion) and Guido must have valued API compactness over collection polymorphism. The latter is also evidenced by set.add() vs list.append() and by the two pop() methods having a different signatures. If you're asking why your specific case looked so painful, I suspect that it only looked hard because the adaptation was force-fit into a lambda (the del-statement or slice assignment won't work as an expression). You would have had similar difficulties embedding try/except logic or a print-statement. Guido, would of course recommend using a plain def-statement: L = list() def L_clearer(L=L): del L[:] for listbunch in buncher(src, '', L, L.append, L_clearer): print listbunch While I question why in-place updating was needed in your example, it did serve as a nice way to show-off various approaches to adapting non-polymorphic API's for a generic consumer function with specific needs. Nice post, Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Bryan Olson <[EMAIL PROTECTED]> wrote: ... > > I agree that emptying is logically the same thing for all of these > > types. Beyond that, they don't seem to have a lot in common. It's ... > > Do you really have a usecase for this? It seems to me that your > > argument is pretty hollow. > > Sure: > > if item_triggering_end in collection: > handle_end(whatever) > collection.clear() > > Or maybe moving everything from several collections into > a single union: > > big_union = set() > for collection in some_iter: > big_union.update(t) > collection.clear() I was thinking of something different again, from a use case I did have: def buncher(sourceit, sentinel, container, adder, clearer): for item in sourceit: if item == sentinel: yield container clearer() else adder(item) yield container s = set() for setbunch in buncher(src, '', s, s.add, s.clear): ... d = dict() for dictbunch in buncher(src, '', d, lambda x: d.setdefault(x,''), d.clear): ... L = list() for listbunch in buncher(src, '', L, L.append, lambda: L.__setslice__(0,len(L),[])): ... the dict case is semi-goofy (since some arbitrary value must be set, one ends up with a lambda willy nilly), but the list case is even worse, with that horrid "lambda calling __setslice__" (eek). BTW, we do have other mutable collections...: import collections q = collections.deque() for qbunch in buncher(src, q, q.append, q.clear): ... just as neat as a set. So what is the rationale for having list SO much harder to use in such a way, than either set or collections.deque? (For dict, I can see the rationale for not having an 'addkey', even though the presence of class method 'fromkeys' weakens that rationale... but for list, I cannot see any reason that makes sense to me). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Magnus Lycka wrote: > Bryan Olson wrote: > >> The original question was about idioms and understanding, but >> there's more to the case for list.clear. Python is "duck typed". >> Consistency is the key to polymorphism: type X will work as an >> actual parameter if and only if X has the required methods and >> they do the expected things. >> >> Emptying out a collection is logically the same thing whether >> that collection is a list, set, dictionary, or user-defined >> SortedBag. When different types can support the same operation, >> they should also support the same interface. That's what >> enables polymorphism. > > > I agree that emptying is logically the same thing for all of these > types. Beyond that, they don't seem to have a lot in common. It's > quite possible to support a duck typing approach that works for all > sorts of sequences, but it's fairly meaningless to use ducktyping > for conceptually different types such as dicts, lists and sets. > > Do you really have a usecase for this? It seems to me that your > argument is pretty hollow. Sure: if item_triggering_end in collection: handle_end(whatever) collection.clear() Or maybe moving everything from several collections into a single union: big_union = set() for collection in some_iter: big_union.update(t) collection.clear() [...] > As far as I understand, the only operation which is currently used > by all three collections is .pop, but that takes a different number > or parameters, since these collections are conceptually different! The all support len, iteration, and membership test. Many algorithms make sense for either sets or lists. Even if they cannot work on every type of collection, that's no reason not to help them be as general as logic allows. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Bryan Olson wrote: > The original question was about idioms and understanding, but > there's more to the case for list.clear. Python is "duck typed". > Consistency is the key to polymorphism: type X will work as an > actual parameter if and only if X has the required methods and > they do the expected things. > > Emptying out a collection is logically the same thing whether > that collection is a list, set, dictionary, or user-defined > SortedBag. When different types can support the same operation, > they should also support the same interface. That's what > enables polymorphism. I agree that emptying is logically the same thing for all of these types. Beyond that, they don't seem to have a lot in common. It's quite possible to support a duck typing approach that works for all sorts of sequences, but it's fairly meaningless to use ducktyping for conceptually different types such as dicts, lists and sets. Do you really have a usecase for this? It seems to me that your argument is pretty hollow. For lists, which are mutable sequences, you add new data with .insert, .append or .extend. You replace or remove existing data using indexing l[x] or slicing l[x:y] in del or assignment statements. You can also remove data with .pop or .remove. These overlapping methods have specific use. l.remove(x) is short for del l[l.index(x)] (it's also faster, and that sometimes matter) and .pop() is there to support a stack-like behaviour. Dicts use indexing d[x] or .update to either add new data or to replace existing data. There is no distinction between these operations in dicts, since dicts are semantically so different from sequences. They have content, but no order, no specific "positions". You can delete one item at a time with del d[x], but since slices don't make sense for dicts, there is a d.clear() method to achieve this common task quickly. One could imagine that it was allowed to write "del d[]" or something like that, but then we also expect x = d[] and d[] = x to work... We probably don't want that. Sets are also semantically different, and thus use a different set of operations. They share the lack of order with dicts, but they aren't pairs, so the semantics is naturally different. They don't support indexing at all, since they neither have order nor keys. As far as I understand, the only operation which is currently used by all three collections is .pop, but that takes a different number or parameters, since these collections are conceptually different! Then we have Queues. They have a different purpose, and again, a different API, since they provide features such as blocking or non- blocking reads and writes. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Magnus Lycka wrote: > Ed Singleton wrote: > >> The point is that having to use del to clear a list appears to the >> inexperienced as being an odd shaped brick when they've already used >> the .clear() brick in other places. > > > Agreed. The smart way to go from this stage of surprise is > not to assume that Python is broken, but to try to understand > how lists are different from e.g. dicts, and why the so-much- > smarter-than-me Python designers made it like this. That two of Python's three built-in mutable collections support clear() is clearly a historical artifact. > Not that Python is perfect, but when you don't get a > "sorry, this change would break existing code, won't happen > until Python 3.0"-resonse, but a "study this more"-response, > the smart thing is to open your mind and try to fully grok > this. The original question was about idioms and understanding, but there's more to the case for list.clear. Python is "duck typed". Consistency is the key to polymorphism: type X will work as an actual parameter if and only if X has the required methods and they do the expected things. Emptying out a collection is logically the same thing whether that collection is a list, set, dictionary, or user-defined SortedBag. When different types can support the same operation, they should also support the same interface. That's what enables polymorphism. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
"Magnus Lycka" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Statements and operators are really fundamental in Python. We > don't support n = 1.add(2), since we have the '+' operator. Actually, since the 2.2 union of type and new-style classes, which gave attributes to all types >>> 1 .__add__(2) # note space after 1 3 >>> 1.__add__(2) # ambiguous, interpreter won't guess SyntaxError: invalid syntax >>> 1..__add__(2.) 3.0 I only see this as useful for making bound methods: >>> inc = 1 .__add__ >>> inc(2) 3 >>> dub = 2 .__mul__ >>> dub(2) 4 which is certainly nicer than the older method of writing a 'makeoper' function that returned a nested function with either a default param or a closure. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I am confused. Could you explain this ? I was under the impression said > above(mapping don't support slicing), until after I read the language > reference. I don't think it is slicing as in the list slicing sense but > it does use the term "extend slicing". > > http://www.python.org/doc/2.4.2/ref/slicings.html I believe that extended slicing was introduced for multidimensional slicing of multidimensional arrays in Numerical Python. Apparently, since such arrays are not indexed sequentially, they are considered as mappings. The paragraph on extended slicing is much clearer if one knows how they are used in one of the numerical Python packages. In the mathematical sense, a sequence can be considered to be a mapping of counts to whatever. In some languages, sequences have been implemented literally as a mapping by 'associative arrays', the equivalent of Python's dict. And dicts are sometimes used in Python to implement sparse arrays. A set is not a mapping unless its members are all ordered pairs, as in a dict. Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
A slim lady in a brown overcoat appears and says with a silly French accent: "Lizten very carefully, I vill zay ziz only onze." BTW, I happen to reply to Ed's post now, but I'm really responding to a fairly common attitude which I find somewhat counterproductive. I hope people are openminded and able to see the point I'm trying to make. Ed Singleton wrote: > The point is that having to use del to clear a list appears to the > inexperienced as being an odd shaped brick when they've already used > the .clear() brick in other places. Agreed. The smart way to go from this stage of surprise is not to assume that Python is broken, but to try to understand how lists are different from e.g. dicts, and why the so-much- smarter-than-me Python designers made it like this. Hubris is considered a virtue in the Perl community. While not mentioned so much, I'd say that humility is considered a virtue here. Not that Python is perfect, but when you don't get a "sorry, this change would break existing code, won't happen until Python 3.0"-resonse, but a "study this more"-response, the smart thing is to open your mind and try to fully grok this. There is a very strong ambition among the Python developers to avoid duplication of features. This is one of the keys to Python's ease of use and readability. Don't bother suggesting synonyms. While there are thousands of situations where adding just another method would make life easier in the short run, life would be much harder if there were thousands of extra methods in the Python core! It isn't always possible to use one approch to a problem in all cases. If two approaches are used, they don't usually overlap. The "extra" approach is only used where the normal approach doesn't work. > Having bricks that work in lots of places makes the language > 'guessable'. "I've never cleared a list before, but I've cleared > dictionaries and I guess the same way would work here". I think we both agree that Python is very useful in this regard. It's more consistent than other languages I've worked with, and when things seems inconsistent, that's probably deliberate, and the appearent lack of consistency is a hint that we need to grok how these cases are different. You really happen to arrive at this from the wrong direction. :) The .clear() methods in dicts and sets are there because there is no other convenient way to empty these containers. There is no support in these kinds of containers to refer to the whole contents without copying. There is no which lets you do "del aDict[]" to clean a dict. You can do "for key in aDict: del aDict[key]", but since this is a fairly common thing to do, there is a shortcut for that called .clear(). I'm pretty sure the reason to implement it was speed rather than convenience. As you know, "There should be one-- and preferably only one --obvious way to do it." "Although practicality beats purity." In other words, moving a very common loop from Python to C was more important than a minimal interface. Don't forget to "import this" and ponder a bit... Statements and operators are really fundamental in Python. We don't support n = 1.add(2), since we have the '+' operator. You can't do x.clear() to remove arbitrary variables x from a namespace, but del x works for every x, whether it's a dict, a module or an int etc. Python basically just use methods when the statements and operators aren't enough. To really understand more about this, it might be useful to ask why we can't use del to somehow empty dicts instead. In the best case, that might possibly lead to the removal or at least deprecation of the .clear() method in Python 3.0, but I doubt that people would find some way that had the required beauty. > The problem is you have to be very careful when talking about this, > not to use the C-word, because that's the hobgoblin of little minds, > whereas in almost every other field it is considered an important part > of usability. That hobgoblin-phrase isn't very helpful. First of all, not all who respond to questions at comp.lang.python know what they are talking about. This is the internet. Take everything you read with a grain of salt. But another thing I've learnt in my years as a consultant, is that when experienced people directly and strongly reject an idea, they usually do that based on intuition and experience, and even if they are arguing poorly for their case, it's in your best interest to try to understand why they react like they do, or you'll fall down in that tar pit they were trying to warn you about. It's like being in a foreign country and meeting someone who is waving his arms and shouting incomprehensibly to you. Just because you don't understand what he's saying, you shouldn't assume that he's just talking jibberish and can be safely ignored. The smart approach is neither to stubbornly repeat your already rejected idea, nor to try to crush the arguments of those who oppose you, but rather to openly and humbly try your best to see
Re: Question about idioms for clearing a list
Magnus Lycka wrote: >... I sometimes come across things that I once new but had forgotten. I'm sorry, and I mean no offense, _but_ I think _new_ there is a lovely typo. :-) I stopped, corrected it in my head, proceeded, and then I backed up, put it back and laughed out loud. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 08/02/06, Magnus Lycka <[EMAIL PROTECTED]> wrote: > Ed Singleton wrote: > > Is it obvious to a newbie what the difference between mappings and > > "not-mappings", and is it obvious exactly what is and isn't a mapping? > > > > Should it be necessary to "know" python before it becomes easy to use? > > QOTW! (You are joking, aren't you? :) It was a genuine question. Judging from one of your other responses, that you are still learning new things and remembering forgotten ones after 10 years, I assume the answer is "no, it is not necessary". (I'm also assuming you find Python easy to use). The thing that first attracted me to Python was that I only had to read a page or two of the tutorial before I could get started on doing little things with Python and find it easy. > I can undestand how people can turn a bit defensive when some > people who are more skilled in programming than in diplomacy > basically tells the confused that they are ignorant and should > just learn the language. > > On the other hand, I think that Art Siegel said it very well: > "My ability to grok Python to any extent, from that starting point, > was based on an understanding that it was my responsibility to come > to Python, not it to me." > (Actually, that's a much better QOTW! It gives me flashbacks from > a book I once read, http://www.amazon.com/gp/product/0060958324 ) > > There are just a few statements in Python. Some of them should > really have been functions (print and exec) but anyway, they are > still few enough to learn. There are also a few ways to get inside > composite objects, x.y, x[y], x[y:z]. These things are among the > most fundamental in Python. > > If luminaries like Fredrik Lundh and Raymond Hettiger tells you > that things should be done in a certain way, it's really just > silly to argue further. I've programmed Python since 1996, but if > these guys tell me I'm wrong, I won't bother to argue. If I don't > understand their position, I'll try to study the subject further, > and I might ask them to clarify, but I'll assume that they are > right. That assumption has worked so far for me. I didn't know they were luminaries. I apologise. I've never heard of any of the people on the list before I came to Python and the only people I've learned to trust are Kent Johnson and Alan Gauld. I guess if I start to see those guys say things that turn out to be right I might start assuming they are right as well. Maybe there should be a list of luminaries on the website so we know who not to argue with? > There are warts and quirks in Python, everybody will agree to that, > but Python is *not* Perl. A basic motto has always been to avoid > synonyms, to try to provide as few ways to do one thing, rather > than to provide as many ways, as possible. This has proven very > successful in making Python easy to learn and use. The opposite > approach has made Perl into the favourite programimng language > among people who think that "if the program was difficult to write, > it should be difficult to read as well!" I think people concentrate on the total number of ways to do something, when the obviousness or consistency of one one of those ways is more important. For example one of the few things Microsoft does okay at, is in having a pretty consistent interface across their applications. There's a menu bar that (theoretically) has all the commands you can perform in a structured format. But you can also use reasonably consistent keyboard shortcuts to do something, or context menus for things that you do a lot. Having several different ways means that everyone can use the way they prefer. Beginners tend to use the menu bar a lot as they can always find what they want there, but can start using the keyboard shortcuts as they start to perform the action a lot and start to become more experienced. I know this isn't entirely applicable but hopefully you see the analogy. > When you can't transfer one approach from one type to another, > there is a reason for that. A few times it might be due to some > obscure practical aspect of the implementation, but most of the > time, it's completely intentional, and finding these aspects of > Python, learning why they are the way they are, and embracing the > language rather than trying to fight it, is actually very rewarding. No, it's rewarding for a certain type of person. It's not a rewarding activity for every type of person. I find it deeply frustrating when I have to constantly look things up to see what is the way of doing things for this type. I'd rather spend my time writing code then looking things up to see which way I have to do it now. > Tuples aren't just immutable lists--they have different purposes > beyond that. Ordereded and unordered collections are conceptually > different. Neither call-by-referece nor call-by-value describes > parameter passing in Python well, the clue lies in understanding > how assignments and objects work, and you need to understand th
Re: Question about idioms for clearing a list
Ed Singleton wrote:
> Having bricks that work in lots of places makes the language
> 'guessable'. "I've never cleared a list before, but I've cleared
> dictionaries and I guess the same way would work here".
f = open("foo")
f.clear()
sys.stdout.clear()
os.getcwd().clear()
shelve.clear()
s = "sky"
s.clear()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 08/02/06, Magnus Lycka <[EMAIL PROTECTED]> wrote: > Ed Singleton wrote: > > I'm a fairly average programmer (better than average compared to my > > immediate colleagues). I've read every tutorial I can get my hands > > on, but I have no _memory_ of ever coming across the del keyword, let > > alone that it is fundamental to Python, and I have no idea what > > collections school is. I doubtless have read of it at some point, but > > as no importance has ever been attached to it, I have probably not > > remembered it. > > > > Similarly, I remember slices simply because they are handy, not > > because I have ever heard of them being fundamental before. > > Ok, I can understand that, but I think that you really understand > that the strength of a programming language such as Python is that > it's like lego bricks. You have some basic pieces, and you can > combine them to into something unique that does what you want. > > There are plenty of statements, operators, functions, types, modules > and other things in Python already. I can well imagine that you had > forgotten about del, and that you don't immediately think about slices > when you wonder how to empty a list. It's like when I build lego with > my son. I guess he has around 2000 pieces, and it's not always easy > to spot what you need. It was difficult enough when I was a kid. Now > there are so many different kinds of pieces, shaped to fulfil some > niche usecase. > > One thing that I'm sure of is this: Making more kinds of odd-shaped > "pieces", especially prepared to solve the specific problem I'm facing > right now, won't make it easier to understand or use Python in the > long run. I agree utterly with this, particularly the general philosophy of having simple bricks that work in as many different places as possible. The point is that having to use del to clear a list appears to the inexperienced as being an odd shaped brick when they've already used the .clear() brick in other places. Having bricks that work in lots of places makes the language 'guessable'. "I've never cleared a list before, but I've cleared dictionaries and I guess the same way would work here". The problem is you have to be very careful when talking about this, not to use the C-word, because that's the hobgoblin of little minds, whereas in almost every other field it is considered an important part of usability. > I've used Python for almost 10 years now, and I still learn new > things, and I sometimes come across things that I once new but > had forgotten. > > It might work for a while to add a new convenience function as soon > as someone finds that they don't immediately now how to solve a > certain problem. It's my impression that that's pretty much the idea > with PHP. It's not Python though. PHP is only successful in a fairly > narrow (if important) niche, it has failed in getting used outside > its niche, and I assume we'll see a decline in its use one the web > pretty soon, just as it happened with Perl. (Whether RoR, something > Python based or something entirely new will replace it is beyond my > radar screen though.) > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 2/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > you seem to be missing that we're talking about a programming language > here. nothing is obvious if you don't know anything about the language; > a lot of things are obvious once you've learned a little about it. a little > is > all it takes. why is that so hard to understand ? "The only 'intuitive' user interface is the nipple. After that, it's all learned." - Bruce Ediger -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Ed Singleton wrote: > Is it obvious to a newbie what the difference between mappings and > "not-mappings", and is it obvious exactly what is and isn't a mapping? > > Should it be necessary to "know" python before it becomes easy to use? QOTW! (You are joking, aren't you? :) I can undestand how people can turn a bit defensive when some people who are more skilled in programming than in diplomacy basically tells the confused that they are ignorant and should just learn the language. On the other hand, I think that Art Siegel said it very well: "My ability to grok Python to any extent, from that starting point, was based on an understanding that it was my responsibility to come to Python, not it to me." (Actually, that's a much better QOTW! It gives me flashbacks from a book I once read, http://www.amazon.com/gp/product/0060958324 ) There are just a few statements in Python. Some of them should really have been functions (print and exec) but anyway, they are still few enough to learn. There are also a few ways to get inside composite objects, x.y, x[y], x[y:z]. These things are among the most fundamental in Python. If luminaries like Fredrik Lundh and Raymond Hettiger tells you that things should be done in a certain way, it's really just silly to argue further. I've programmed Python since 1996, but if these guys tell me I'm wrong, I won't bother to argue. If I don't understand their position, I'll try to study the subject further, and I might ask them to clarify, but I'll assume that they are right. That assumption has worked so far for me. There are warts and quirks in Python, everybody will agree to that, but Python is *not* Perl. A basic motto has always been to avoid synonyms, to try to provide as few ways to do one thing, rather than to provide as many ways, as possible. This has proven very successful in making Python easy to learn and use. The opposite approach has made Perl into the favourite programimng language among people who think that "if the program was difficult to write, it should be difficult to read as well!" When you can't transfer one approach from one type to another, there is a reason for that. A few times it might be due to some obscure practical aspect of the implementation, but most of the time, it's completely intentional, and finding these aspects of Python, learning why they are the way they are, and embracing the language rather than trying to fight it, is actually very rewarding. Tuples aren't just immutable lists--they have different purposes beyond that. Ordereded and unordered collections are conceptually different. Neither call-by-referece nor call-by-value describes parameter passing in Python well, the clue lies in understanding how assignments and objects work, and you need to understand the difference between mutable and immutable objects etc. There are a number of fundamental concepts that you need to understand to really use Python well. Python works very smoothly, and you can do a lot of productive work with it even if you don't know these things, but in time you'll trip over them, and as you do, you need to grok these concepts to get further. Asking for some syntactic change or some convenience method so that you can get a little further without understanding the fundamental concept isn't the way to get beyond these little stumbling blocks. It's a bit as if you call the design department of your car manufacturer and tell them how they should redesign the suspension since it was so bumpy when you drove around with flat tires. Saying that it's too much to ask that you keep the tires filled with the right amount of air won't meet much sympathy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Ed Singleton wrote: > I'm a fairly average programmer (better than average compared to my > immediate colleagues). I've read every tutorial I can get my hands > on, but I have no _memory_ of ever coming across the del keyword, let > alone that it is fundamental to Python, and I have no idea what > collections school is. I doubtless have read of it at some point, but > as no importance has ever been attached to it, I have probably not > remembered it. > > Similarly, I remember slices simply because they are handy, not > because I have ever heard of them being fundamental before. Ok, I can understand that, but I think that you really understand that the strength of a programming language such as Python is that it's like lego bricks. You have some basic pieces, and you can combine them to into something unique that does what you want. There are plenty of statements, operators, functions, types, modules and other things in Python already. I can well imagine that you had forgotten about del, and that you don't immediately think about slices when you wonder how to empty a list. It's like when I build lego with my son. I guess he has around 2000 pieces, and it's not always easy to spot what you need. It was difficult enough when I was a kid. Now there are so many different kinds of pieces, shaped to fulfil some niche usecase. One thing that I'm sure of is this: Making more kinds of odd-shaped "pieces", especially prepared to solve the specific problem I'm facing right now, won't make it easier to understand or use Python in the long run. I've used Python for almost 10 years now, and I still learn new things, and I sometimes come across things that I once new but had forgotten. It might work for a while to add a new convenience function as soon as someone finds that they don't immediately now how to solve a certain problem. It's my impression that that's pretty much the idea with PHP. It's not Python though. PHP is only successful in a fairly narrow (if important) niche, it has failed in getting used outside its niche, and I assume we'll see a decline in its use one the web pretty soon, just as it happened with Perl. (Whether RoR, something Python based or something entirely new will replace it is beyond my radar screen though.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
[Ed Singleton] > Is it obvious to a newbie what the difference between mappings and > "not-mappings", and is it obvious exactly what is and isn't a mapping? FWIW, there is a glossary in the tutorial: http://docs.python.org/tut/node18.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Tim Hochberg wrote: > [EMAIL PROTECTED] wrote: > > Fredrik Lundh wrote: > > > >>>Python now has, what, three built-in mutable collections types: > >>>lists, dictionaries, and sets. Dicts and sets both have a clear() > >>>method and lists do not. > >> > >>dicts and sets are mappings, and lists are not. mappings don't > >>support slicing. lists do. > > > > > > I am confused. Could you explain this ? I was under the impression said > > above(mapping don't support slicing), until after I read the language > > reference. I don't think it is slicing as in the list slicing sense but > > it does use the term "extend slicing". > > > > http://www.python.org/doc/2.4.2/ref/slicings.html > > > > "The semantics for an extended slicing are as follows. The primary must > > evaluate to a mapping object, and it is indexed with a key that is > > constructed from the slice list, as follows. If the slice list contains > > at least one comma, the key is a tuple containing the conversion of the > > slice items; otherwise, the conversion of the lone slice item is the > > key. The conversion of a slice item that is an expression is that > > expression. The conversion of an ellipsis slice item is the built-in > > Ellipsis object. The conversion of a proper slice is a slice object > > (see section 3.2) whose start, stop and step attributes are the values > > of the expressions given as lower bound, upper bound and stride, > > respectively, substituting None for missing expressions." > > > This is in place to support multidimensional arrays, such as in numpy. > If, for instance, you have a 9x9 array A, then A[3:6,3:6] will extract a > 3x3 block from the center of it. A[3:6,3:6] is equivalent to > A[(slice(3,6,None), slice(3,6,None))] and the resulting tuple gets > passed through the mapping interface, but it is not a mapping in any > real sense. > > I don't think there's anything in core Python that uses this and it's > not really relevant to this thread. > Thanks. I would say that it is not relevant to the OP's question but the thread has turned to "anyone who read the doc should know about slicing" and that prompted me to go and read the doc(I don't have the OP's mentioned need in my coding so far and never read about the full pontential of slicing, just use it as the right hand side intuitively) about slicing and found the documentation to be a bit lacking(only a brief mentioning of slicing in the turtorial and this confusing section). Beside, just from reading this page, it seems that a[start:stop:stride] is not a valid construction for sequence object 'a'. To me, reading the doc makes me more confuse about what is slicing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
[EMAIL PROTECTED] wrote: > Fredrik Lundh wrote: > >>>Python now has, what, three built-in mutable collections types: >>>lists, dictionaries, and sets. Dicts and sets both have a clear() >>>method and lists do not. >> >>dicts and sets are mappings, and lists are not. mappings don't >>support slicing. lists do. > > > I am confused. Could you explain this ? I was under the impression said > above(mapping don't support slicing), until after I read the language > reference. I don't think it is slicing as in the list slicing sense but > it does use the term "extend slicing". > > http://www.python.org/doc/2.4.2/ref/slicings.html > > "The semantics for an extended slicing are as follows. The primary must > evaluate to a mapping object, and it is indexed with a key that is > constructed from the slice list, as follows. If the slice list contains > at least one comma, the key is a tuple containing the conversion of the > slice items; otherwise, the conversion of the lone slice item is the > key. The conversion of a slice item that is an expression is that > expression. The conversion of an ellipsis slice item is the built-in > Ellipsis object. The conversion of a proper slice is a slice object > (see section 3.2) whose start, stop and step attributes are the values > of the expressions given as lower bound, upper bound and stride, > respectively, substituting None for missing expressions." This is in place to support multidimensional arrays, such as in numpy. If, for instance, you have a 9x9 array A, then A[3:6,3:6] will extract a 3x3 block from the center of it. A[3:6,3:6] is equivalent to A[(slice(3,6,None), slice(3,6,None))] and the resulting tuple gets passed through the mapping interface, but it is not a mapping in any real sense. I don't think there's anything in core Python that uses this and it's not really relevant to this thread. -tim -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven D'Aprano wrote: > As for the earlier suggestion that it would be obvious if only I'd done > the tutorial, if you need to be taught something it is hardly obvious > is it? Otherwise "obvious" loses all meaning, and we can say any feature, > no matter how obscure, is obvious if only you'd read the right book, had > the right teacher, taken the right college degree. you seem to be missing that we're talking about a programming language here. nothing is obvious if you don't know anything about the language; a lot of things are obvious once you've learned a little about it. a little is all it takes. why is that so hard to understand ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote: > > Python now has, what, three built-in mutable collections types: > > lists, dictionaries, and sets. Dicts and sets both have a clear() > > method and lists do not. > > dicts and sets are mappings, and lists are not. mappings don't > support slicing. lists do. I am confused. Could you explain this ? I was under the impression said above(mapping don't support slicing), until after I read the language reference. I don't think it is slicing as in the list slicing sense but it does use the term "extend slicing". http://www.python.org/doc/2.4.2/ref/slicings.html "The semantics for an extended slicing are as follows. The primary must evaluate to a mapping object, and it is indexed with a key that is constructed from the slice list, as follows. If the slice list contains at least one comma, the key is a tuple containing the conversion of the slice items; otherwise, the conversion of the lone slice item is the key. The conversion of a slice item that is an expression is that expression. The conversion of an ellipsis slice item is the built-in Ellipsis object. The conversion of a proper slice is a slice object (see section 3.2) whose start, stop and step attributes are the values of the expressions given as lower bound, upper bound and stride, respectively, substituting None for missing expressions." -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote: > > Python now has, what, three built-in mutable collections types: > > lists, dictionaries, and sets. Dicts and sets both have a clear() > > method and lists do not. > > dicts and sets are mappings, and lists are not. mappings don't > support slicing. lists do. I am confused. Could you explain this ? I was under the impression said above(mapping don't support slicing), until after I read the language reference. I don't think it is slicing as in the list slicing sense but it does use the term "extend slicing". http://www.python.org/doc/2.4.2/ref/slicings.html "The semantics for an extended slicing are as follows. The primary must evaluate to a mapping object, and it is indexed with a key that is constructed from the slice list, as follows. If the slice list contains at least one comma, the key is a tuple containing the conversion of the slice items; otherwise, the conversion of the lone slice item is the key. The conversion of a slice item that is an expression is that expression. The conversion of an ellipsis slice item is the built-in Ellipsis object. The conversion of a proper slice is a slice object (see section 3.2) whose start, stop and step attributes are the values of the expressions given as lower bound, upper bound and stride, respectively, substituting None for missing expressions." -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On Tue, 07 Feb 2006 22:32:40 +0100, Fredrik Lundh wrote: > are you sure you know Python ? Oh my, a little tetchy today aren't we? Obviousness is a subjective matter! It is one thing to say that 9 out of 10 programmers not only discover this technique (by reading the tutorial perhaps) but remember it, and therefore it is not an issue. It is another issue altogether to say "When I want to CLEAR a list, I think of DELETING A SLICE, and anyone who doesn't obviously doesn't know Python." As for the earlier suggestion that it would be obvious if only I'd done the tutorial, if you need to be taught something it is hardly obvious is it? Otherwise "obvious" loses all meaning, and we can say any feature, no matter how obscure, is obvious if only you'd read the right book, had the right teacher, taken the right college degree. I understand that get/set/del of slices is absolutely fundamental to lists. I understand that lists are not precisely the same as dicts. I understand that if you read help(list) and see the entry for the __del__ method and extrapolate sufficiently you will come up with del L[:] as a technique for clearing a list. But I also see that Python includes convenience methods, like pop and extend and insert, and it is my opinion is that Python's clarity would be slightly increased if lists had a clear() method. That's a very mild claim, and I don't understand why there is so much vehemence against the suggestion. It's not like I suggested Python should get rid of slicing altogether. If it is just "I've had a bad week and I'm grumpy", then I can understand that -- I've been there and done that. If it's "I hate the word 'clear' and it fills me with rage that dicts have a clear method too", then I'll just back away slooowly now. But if there are good, solid reasons for rejecting *this particular* (hypothetical) convenience method, then I'd like to hear about them, sans questions about my ability to program in Python. Thank you, -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Ed Singleton wrote > > > I'm not mud-slinging, I'm just saying that people are very dismissive > > of making the language easier to use for newbies. > > no, you're telling people who have long experience in explaining things > to "newbies" that their experiences don't count, and that you are the > only newbie that's important. No, I'm saying that people are very dismissive of making things easier to use for newbies (as you yourself were only a few posts ago) Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote: > Bryan Olson wrote: > > >>So is consistency; it ain't Perl, thank Guido. > > consistency is the hobgoblin of little minds. Look up that saying. Any clues? >>Python now has, what, three built-in mutable collections types: >>lists, dictionaries, and sets. Dicts and sets both have a clear() >>method and lists do not. > > dicts and sets are mappings, and lists are not. Sets are mappings? Look up the terms, or check the library doc: http://docs.python.org/lib/lib.html > mappings don't > support slicing. lists do. Do they all have an empty state? Can you figure out what a clear() method for lists should do, just from what it does for sets and dicts? > are you sure you know Python ? Why would you post a messages like that? -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Ed Singleton wrote > I'm not mud-slinging, I'm just saying that people are very dismissive > of making the language easier to use for newbies. no, you're telling people who have long experience in explaining things to "newbies" that their experiences don't count, and that you are the only newbie that's important. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 7 Feb 2006 07:08:17 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > As a general rule of thumb, I would say that if a person is struggling > > with a language, it is primarily a problem with the language, and than > > problem with the documentation, and lastly a problem with the person. > > I would swap the first two. No language has yet been invented > (including HTML and LOGO) that someone doesn't struggle with. In > contrast, no documentation has ever been written that couldn't be > improved. (I should clarify that by documentation, I mean external documentation rather than self-documentation features) Given the choice of having a language that is hard to use but has good documentation or one that is easy to use but has bad documentation, which would you go for? If you could write the perfect language, would it be so easy to use (including self-documentation) that no one ever needed to look things up in external documentation, or would it have such good documentation that you could always find what you needed in external documentation? Documentation is there to cover up the cracks in the none-obvious (or confusing) parts of the language. Python is starting to show that one day anything but the most perfunctory documentation may one day become unnecessary. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Again we unfortunately have a bit of an attitude problem > > > towards anyone posting here that doesn't know whatever the experts > > > think is obvious. > > > > I agree wholeheartedly with this, particularly as there often seems to > > be strong (and confusing) resistance to making Python easier and more > > obvious. > > That is B.S. > > We simply disagree on whether list.clear() is an improvement. Adding a > non-essential method to an important API does not make the language t > easier to learn or use. Yes it does. It makes it a lot easier to learn. Even list.del() would be a massive improvement. > Also, it doesn't address the wider issue that > learning about slices is important for understanding the language (it > appears in many guises). Likewise, learning about the del-statement is > somewhat essential for people setting out to mutate collections > in-place. You're not helping someone if you steer them away from > learning the basics. Maybe it's better to put the basics in a place that they will find them, rather than trying to steer them. Manipulating the language is hell of a lot easier than manipulating every user. Languages are only there for people to use therefore I'm going to go out on a limb and say that they should be designed for people to use. > > I can only assume that it is by people who have forgotten > > what it is like to be an average programmer. > > More B.S. > > My thoughts on the issue are informed by several years of answering > average programmer questions on the python-help list. In that time, > the question of how to clear a list has never come up. There are > several areas of recurring confusion but this isn't one of them. > You're mud-slinging over a non-issue. My thoughts on the issue are informed by many years of being an average programmer and knowing and working with lots of average programmers (and well below average programmers for that matter) I'm not mud-slinging, I'm just saying that people are very dismissive of making the language easier to use for newbies. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Bryan Olson wrote: > > > So is consistency; it ain't Perl, thank Guido. > > consistency is the hobgoblin of little minds. > > > Python now has, what, three built-in mutable collections types: > > lists, dictionaries, and sets. Dicts and sets both have a clear() > > method and lists do not. > > dicts and sets are mappings, and lists are not. mappings don't > support slicing. lists do. > > are you sure you know Python ? Is it obvious to a newbie what the difference between mappings and "not-mappings", and is it obvious exactly what is and isn't a mapping? Should it be necessary to "know" python before it becomes easy to use? Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > >dicts and sets are mappings, and lists are not. mappings don't >support slicing. lists do. > >are you sure you know Python ? Actually, after spending some time thinking about this, I've decided that sets are *not* mappings. I believe that a mapping should support __getitem__(); in addition, sets do not consist of key/value pairs like any other mapping. (Just to be clear, I do agree with your basic point; I'm nitpicking on a tangent.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Bryan Olson wrote: > So is consistency; it ain't Perl, thank Guido. consistency is the hobgoblin of little minds. > Python now has, what, three built-in mutable collections types: > lists, dictionaries, and sets. Dicts and sets both have a clear() > method and lists do not. dicts and sets are mappings, and lists are not. mappings don't support slicing. lists do. are you sure you know Python ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote: > Steven D'Aprano wrote: [...] >>del L[:] works, but unless you are Dutch, it fails the >>obviousness test. > > > unless you read some documentation, that is. del on sequences > and mappings is a pretty fundamental part of Python. so are slicings. So is consistency; it ain't Perl, thank Guido. Python now has, what, three built-in mutable collections types: lists, dictionaries, and sets. Dicts and sets both have a clear() method and lists do not. That's a wart, minor but easily fixed. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On Tue, 7 Feb 2006, Ben Sizer wrote: > Raymond Hettinger wrote: >> [Steven D'Aprano] The Zen isn't "only one way to do it". If it were, we wouldn't need iterators, list comps or for loops, because they can all be handled with a while loop (at various costs of efficiency, clarity or obviousness). del L[:] works, but unless you are Dutch, it fails the obviousness test. >> >> [Fredrik Lundh] >>> unless you read some documentation, that is. del on sequences >>> and mappings is a pretty fundamental part of Python. so are slicings. >>> >>> both are things that you're likely to need and learn long before you >>> end up in situation where you need to be able to clear an aliased >>> sequence. I don't agree with that at all. I'd been programming python for a while (a year?) before i knew about del l[:]. >> Likewise, the del keyword is fundamental -- if you can't get, set, and >> del, then you need to go back to collections school. > > I have hardly used the del keyword in several years of coding in Python. Ditto. > Why should it magically spring to mind in this occasion? Similarly I > hardly ever find myself using slices, never mind in a mutable context. > > del L[:] is not obvious, especially given the existence of clear() in > dictionaries. Agreed. tom -- GOLDIE LOOKIN' CHAIN [...] will ultimately make all other forms of music both redundant and unnecessary -- ntk -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Ben Sizer wrote: >> Likewise, the del keyword is fundamental -- if you >> can't get, set, and del, then you need to go back to collections >> school. > > I have hardly used the del keyword in several years of coding in > Python. Why should it magically spring to mind in this occasion? > Similarly I hardly ever find myself using slices, never mind in a > mutable context. I just grepped through my codebase, and while I do see a number of dels with dicts, and a number of dels with instance attributes, I see only two dels with lists, both from the same module. So I think your point about infrequent use of del, at least with lists, is pretty valid. I suspect this is reinforced by the fact that del is usually not the right way to go when using lists -- repeated dels in the middle of a list is almost always less efficient than other techniques due to the underlying array implementation. That said, I didn't find anywhere in my codebase that I needed to clear a list (i.e. where ``L = []`` wasn't perfectly fine), while I do find a small number of dict clears. So I guess I don't really care if clearing a list is a little less intuitive than clearing a dict. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
> I'm a fairly average programmer (better than average compared to my > immediate colleagues). I've read every tutorial I can get my hands > on, but I have no _memory_ of ever coming across the del keyword, let > alone that it is fundamental to Python, My thought is that get/set/del are fundamental ops in almost any computing context: songs on your iPod playlist, records in a database, files in a directory, or elements in a Python list. Individual element deletion doesn't seem to come-up as much in Python because we tend to build data collections and then throw them away in their entirity. However, the concept becomes more prominent when dealing with persistence or when mutating a collection in-place. The OP was specifically seeking to do in-place modifications and so found himself in need of understanding the del-statement. IMHO, it goes with the territory. > Similarly, I remember slices simply because they are handy, not > because I have ever heard of them being fundamental before. FWIW, I regard slices to be fundamental to the language not because they are easy or that everyone automatically knows about them; rather, I am just recognizing that the concept of slices pervades the language and comes up in many different guises. It is a lesson that should not be skipped. That is why I think that the OP's problem is better solved by improved documentation than by adding an unnecessary method to the list API. > As a general rule of thumb, I would say that if a person is struggling > with a language, it is primarily a problem with the language, and than > problem with the documentation, and lastly a problem with the person. I would swap the first two. No language has yet been invented (including HTML and LOGO) that someone doesn't struggle with. In contrast, no documentation has ever been written that couldn't be improved. The "problem with the person" part goes last only because it suggests immutability. The reality is that incomplete learning is a fixable problem (independent of language or doc issues). If I never learn the del-statement, should I be surprised that I stuggle with how to express deletion? Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Arthur wrote: > > My ability to grok Python to any extent, from that starting point, was > based on an understanding that it was my responsibility to come to > Python, not it to me. And concerted, almost obsessive effort, And time. > > OTOH - because of exactly these factors - I have actively resented and > resisted promulgation of the Python is Easy meme. > > Pity that this stance has separated me from a sense of belonging to the > community, which seems to so highly value that meme. What Python *is*, to me, is a game worth playing. Not something I come across all that often. And easy games, almost invariably, are not. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Ed Singleton wrote: > > I'm a fairly average programmer (better than average compared to my > immediate colleagues). I've read every tutorial I can get my hands > on, but I have no _memory_ of ever coming across the del keyword, let > alone that it is fundamental to Python, and I have no idea what > collections school is. I doubtless have read of it at some point, but > as no importance has ever been attached to it, I have probably not > remembered it. > I'm probably below average as a programmer, except when compared with my immediate colleagues [1]. I wrote an extremely simple (albeit non-conventional) tutorial on learning how to program with Python, partly as a means to learn Python myself. (Google for rur-ple if you are curious.) I introduced del shortly after I introduced lists. I think it is important that one learns at least a couple of example usage of every Python keyword as soon as possible, before attempting to write complicated programs. The same probably goes for built-in functions. André [1] Because I have none. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 7 Feb 2006 02:02:42 -0800, Ben Sizer <[EMAIL PROTECTED]> wrote: > > Fred is exactly correct. Slicing is absolutely basic to Python. > > Accordingly, it gets covered right at the beginning of the tutorial > > (section 3.1). > > Yes, right after UTF encoding details, complex numbers, and various > mentions of shell scripts. Now that is GPotD (Good Point of the Day) which is much better than QotW as it's actually useful. > I don't want to criticise the hard work that > went into making the tutorial but let's not pretend it's the epitome of > documentation or even necessary the most obvious reference for users. > > > Likewise, the del keyword is fundamental -- if you > > can't get, set, and del, then you need to go back to collections > > school. > > I have hardly used the del keyword in several years of coding in > Python. Why should it magically spring to mind in this occasion? > Similarly I hardly ever find myself using slices, never mind in a > mutable context. > > del L[:] is not obvious, especially given the existence of clear() in > dictionaries. I'm not necessarily requesting a clear() method, but I am > requesting a little more understanding towards those who expected one. > The list interface is full of redundant convenience methods, so one > more would hardly be a surprise or an unreasonable thing for people to > expect. Again we unfortunately have a bit of an attitude problem > towards anyone posting here that doesn't know whatever the experts > think is obvious. I agree wholeheartedly with this, particularly as there often seems to be strong (and confusing) resistance to making Python easier and more obvious. I can only assume that it is by people who have forgotten what it is like to be an average programmer. (Paul Graham constantly makes the same mistake when he goes on about how everyone should use lisp). Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steve Holden wrote: >> While the sentiment behind the list.clear() suggestion is noble, it is >> an exercise in futility to design a language around the presumption >> that other programmers are incapable of learning the basics of the >> language. > > +1 QOTW >> There was a pithy Tim Peters quotation to the effect that he was >> unpersuaded by language proposals predicated on some hypothetical >> average programmer not being smart enough to understand something that >> the rest of us find to be basic. >> > Well, for those who can't find it you just provided a fairly pithy > Raymond Hettinger quote :-) for the record, the original quote is: The "of course, while *I* have no problem with this at all, it's surely too much for a lesser being" flavor of argument always rings hollow to me. Are you personally confused by the meanings for "+" that exist today? *Objecting* to the variations is a different story; I'm wondering whether you personally stumble over them in practice. I don't; Steven doesn't; I doubt that you do either. I'm betting that almost *nobody* ever does, in which case those "less nimble colleagues and students" must be supernaturally feeble to merit such concern. -- Tim Peters, 29 Apr 1998 -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 7 Feb 2006 00:27:05 -0800, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > There was a pithy Tim Peters quotation to the effect that he was > unpersuaded by language proposals predicated on some hypothetical > average programmer not being smart enough to understand something that > the rest of us find to be basic. The problem is that the average programmer in question isn't hypothetical in this case. I'm a fairly average programmer (better than average compared to my immediate colleagues). I've read every tutorial I can get my hands on, but I have no _memory_ of ever coming across the del keyword, let alone that it is fundamental to Python, and I have no idea what collections school is. I doubtless have read of it at some point, but as no importance has ever been attached to it, I have probably not remembered it. Similarly, I remember slices simply because they are handy, not because I have ever heard of them being fundamental before. (I don't argue their fundamentalness one way or other, it's just that you seem to think that all people who have learned Python have some knowledge of this hugely important feature). The other problem with your use of the quote is that the smartness of the average programmer, or their ability to understand the feature, is not in question. It is their ability to know of the existence of the feature, or to find out about it. As a general rule of thumb, I would say that if a person is struggling with a language, it is primarily a problem with the language, and than problem with the documentation, and lastly a problem with the person. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Raymond Hettinger wrote: > > There was a pithy Tim Peters quotation to the effect that he was > unpersuaded by language proposals predicated on some hypothetical > average programmer not being smart enough to understand something that > the rest of us find to be basic. Peters pithy ;) As someone coming to Python as a well less than the average programmer, I agree wholeheartedly with Mr. Peters. My ability to grok Python to any extent, from that starting point, was based on an understanding that it was my responsibility to come to Python, not it to me. And concerted, almost obsessive effort, And time. OTOH - because of exactly these factors - I have actively resented and resisted promulgation of the Python is Easy meme. Pity that this stance has separated me from a sense of belonging to the community, which seems to so highly value that meme. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Raymond Hettinger wrote: > [Steven D'Aprano] [...] > > While the sentiment behind the list.clear() suggestion is noble, it is > an exercise in futility to design a language around the presumption > that other programmers are incapable of learning the basics of the > language. > +1 QOTW > There was a pithy Tim Peters quotation to the effect that he was > unpersuaded by language proposals predicated on some hypothetical > average programmer not being smart enough to understand something that > the rest of us find to be basic. > Well, for those who can't find it you just provided a fairly pithy Raymond Hettinger quote :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Raymond Hettinger wrote: > [Steven D'Aprano] > > > The Zen isn't "only one way to do it". If it were, we > > > wouldn't need iterators, list comps or for loops, > > > because they can all be handled with a while loop (at > > > various costs of efficiency, clarity or obviousness). > > > > > > del L[:] works, but unless you are Dutch, it fails the > > > obviousness test. > > [Fredrik Lundh] > > unless you read some documentation, that is. del on sequences > > and mappings is a pretty fundamental part of Python. so are slicings. > > > > both are things that you're likely to need and learn long before you > > end up in situation where you need to be able to clear an aliased > > sequence. > > Fred is exactly correct. Slicing is absolutely basic to Python. > Accordingly, it gets covered right at the beginning of the tutorial > (section 3.1). Yes, right after UTF encoding details, complex numbers, and various mentions of shell scripts. I don't want to criticise the hard work that went into making the tutorial but let's not pretend it's the epitome of documentation or even necessary the most obvious reference for users. > Likewise, the del keyword is fundamental -- if you > can't get, set, and del, then you need to go back to collections > school. I have hardly used the del keyword in several years of coding in Python. Why should it magically spring to mind in this occasion? Similarly I hardly ever find myself using slices, never mind in a mutable context. del L[:] is not obvious, especially given the existence of clear() in dictionaries. I'm not necessarily requesting a clear() method, but I am requesting a little more understanding towards those who expected one. The list interface is full of redundant convenience methods, so one more would hardly be a surprise or an unreasonable thing for people to expect. Again we unfortunately have a bit of an attitude problem towards anyone posting here that doesn't know whatever the experts think is obvious. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
[EMAIL PROTECTED] > In my programs I have seen that there is another practical difference > between version 1 and 3: > (1) mylist[:] = [] > (3) mylist = [] > If you create a big mylist again and again many times, the version 1 > uses the memory more efficiently (probably less work for the garbage > collector), and the program can be (quite) faster (this is true in some > implementations different from CPython too). There should be almost no difference in runtime between the two. The underlying CPython implementation caches list objects and is usually able to create the new list without any calls to the memory allocator. Likewise, garbage collection performs the same for both -- any objects left with no references are immediately freed and any with only circular references get freed when the collector runs. The speed-up you observed likely occured with different code. For instance, given a large list, you can typically update or replace individual elements faster than you can build-up a new list: L = [0] * 1000 # starting list for i in xrange(len(L)): L[i] += 1 beats: L = [0] * 1000 # starting list L = [L[i]+1 for i in xrange(len(L))] Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
[Steven D'Aprano] > > The Zen isn't "only one way to do it". If it were, we > > wouldn't need iterators, list comps or for loops, > > because they can all be handled with a while loop (at > > various costs of efficiency, clarity or obviousness). > > > > del L[:] works, but unless you are Dutch, it fails the > > obviousness test. [Fredrik Lundh] > unless you read some documentation, that is. del on sequences > and mappings is a pretty fundamental part of Python. so are slicings. > > both are things that you're likely to need and learn long before you > end up in situation where you need to be able to clear an aliased > sequence. Fred is exactly correct. Slicing is absolutely basic to Python. Accordingly, it gets covered right at the beginning of the tutorial (section 3.1). Likewise, the del keyword is fundamental -- if you can't get, set, and del, then you need to go back to collections school. Also specious is the suggestion that dir(L) or help(L) is useless. The entries for the __delitem__ and __delslice__ methods are no more hidden than for __getitem__ or __add__. The help entry goes a step further and shows the translation to del x[y] and del x[i:j]. While the sentiment behind the list.clear() suggestion is noble, it is an exercise in futility to design a language around the presumption that other programmers are incapable of learning the basics of the language. There was a pithy Tim Peters quotation to the effect that he was unpersuaded by language proposals predicated on some hypothetical average programmer not being smart enough to understand something that the rest of us find to be basic. Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven D'Aprano wrote: > > so we can have three ways to do the same thing? the right way to > > nuke a sequence is to do "del L[:]". this is explained in Python 101. > > The Zen isn't "only one way to do it". If it were, we > wouldn't need iterators, list comps or for loops, > because they can all be handled with a while loop (at > various costs of efficiency, clarity or obviousness). > > del L[:] works, but unless you are Dutch, it fails the > obviousness test. unless you read some documentation, that is. del on sequences and mappings is a pretty fundamental part of Python. so are slicings. both are things that you're likely to need and learn long before you end up in situation where you need to be able to clear an aliased sequence. > It also fails the introspection test: so does "print L". -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote: > Peter Hansen wrote: > > >>>Perhaps it is arguable that there is no need for a clear method because >>>L[:] = [] is so easy to do. Personally, while I agree that it is easy, it >>>is hardly intuitive or obvious, and I too would prefer an explicit clear >>>method for mutable sequences. >> >>Possibly another case where "patches are welcome"... > > > so we can have three ways to do the same thing? the right way to > nuke a sequence is to do "del L[:]". this is explained in Python 101. The Zen isn't "only one way to do it". If it were, we wouldn't need iterators, list comps or for loops, because they can all be handled with a while loop (at various costs of efficiency, clarity or obviousness). del L[:] works, but unless you are Dutch, it fails the obviousness test. It also fails the introspection test: neither dir(list) nor help(list) make it easy to discover how to empty a list. In my opinion, the primary advantage for a clear() method would be that it is self-documenting. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On Mon, 06 Feb 2006 09:39:32 -0500, Dan Sommers wrote:
> On Tue, 07 Feb 2006 01:01:43 +1100,
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
I'm wondering why there is no 'clear' for lists. It feels like a common
operation for mutable containers. :-/
>>> Because it's just as easy to create and assign a new empty list (and
>>> have the old unused one garbage collected).
>>>
>>> l = []
>>>
>>> is all you need!
>
>> Not so. If that logic were correct, then dicts wouldn't need a clear
>> method either, because you could just assign a new empty dict with d = {}.
>
>> But your own sentence tells us why this is not sufficient: because you
>> aren't emptying the list, you are reassigning (rebinding) the name. The
>> old list still exists, and there is no guarantee that it will be garbage
>> collected, because there is no guarantee that it isn't in use somewhere
>> else:
>
>> L = [0,1,2]
>> D = {"key": L}
>> L = [] # rebinds the name L, but the list instance still exists
>
> That is a red herring. Consider this:
>
> L = [object(), object()]
> O = L[1]
> L = [] # or insert your favorite list-clearing/emptying statement here
>
> What damage is done now that O is still referring to one of the items
> that used to be in L?
What relevance is this? If there is one and only one reference to the list
L, then it will be garbage collected when L is rebound. I never denied
that. I pointed out that, in the general case, you may have multiple
references to the list (not all of which are bound to names), and
rebinding the name L will NOT have the side-effect of clearing the list.
> The trouble begins when references to "the list to which L refers" end
> up somewhere else. Then we have to wonder if rebinding L will leave
> some other block of code with an outdated list.
Precisely, just as my example shows.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Fredrik Lundh wrote:
> (del doesn't work on dictionaries)
... or rather [:] doesn't work on dictionaries ...
Python 2.4.2 (#1, Jan 23 2006, 21:24:54)
[GCC 3.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d={'a':1, 'b':2, 'c':3}
>>> print d
{'a': 1, 'c': 3, 'b': 2}
>>> del d['b']
>>> print d
{'a': 1, 'c': 3}
>>> del d[:]
Traceback (most recent call last):
File "", line 1, in ?
TypeError: unhashable type
>>>
Regards.Mel.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Peter Hansen wrote: > > Perhaps it is arguable that there is no need for a clear method because > > L[:] = [] is so easy to do. Personally, while I agree that it is easy, it > > is hardly intuitive or obvious, and I too would prefer an explicit clear > > method for mutable sequences. > > Possibly another case where "patches are welcome"... so we can have three ways to do the same thing? the right way to nuke a sequence is to do "del L[:]". this is explained in Python 101. (del doesn't work on dictionaries) -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven D'Aprano wrote: > Perhaps it is arguable that there is no need for a clear method because > L[:] = [] is so easy to do. Personally, while I agree that it is easy, it > is hardly intuitive or obvious, and I too would prefer an explicit clear > method for mutable sequences. Possibly another case where "patches are welcome"... -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On Tue, 07 Feb 2006 01:01:43 +1100,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
>>> I'm wondering why there is no 'clear' for lists. It feels like a common
>>> operation for mutable containers. :-/
>>>
>> Because it's just as easy to create and assign a new empty list (and
>> have the old unused one garbage collected).
>>
>> l = []
>>
>> is all you need!
> Not so. If that logic were correct, then dicts wouldn't need a clear
> method either, because you could just assign a new empty dict with d = {}.
> But your own sentence tells us why this is not sufficient: because you
> aren't emptying the list, you are reassigning (rebinding) the name. The
> old list still exists, and there is no guarantee that it will be garbage
> collected, because there is no guarantee that it isn't in use somewhere
> else:
> L = [0,1,2]
> D = {"key": L}
> L = [] # rebinds the name L, but the list instance still exists
That is a red herring. Consider this:
L = [object(), object()]
O = L[1]
L = [] # or insert your favorite list-clearing/emptying statement here
What damage is done now that O is still referring to one of the items
that used to be in L?
The trouble begins when references to "the list to which L refers" end
up somewhere else. Then we have to wonder if rebinding L will leave
some other block of code with an outdated list.
Regards,
Dan
--
Dan Sommers
Re: Question about idioms for clearing a list
On Mon, 06 Feb 2006 13:35:10 +, Steve Holden wrote:
>> I'm wondering why there is no 'clear' for lists. It feels like a common
>> operation for mutable containers. :-/
>>
> Because it's just as easy to create and assign a new empty list (and
> have the old unused one garbage collected).
>
> l = []
>
> is all you need!
Not so. If that logic were correct, then dicts wouldn't need a clear
method either, because you could just assign a new empty dict with d = {}.
But your own sentence tells us why this is not sufficient: because you
aren't emptying the list, you are reassigning (rebinding) the name. The
old list still exists, and there is no guarantee that it will be garbage
collected, because there is no guarantee that it isn't in use somewhere
else:
L = [0,1,2]
D = {"key": L}
L = [] # rebinds the name L, but the list instance still exists
Perhaps it is arguable that there is no need for a clear method because
L[:] = [] is so easy to do. Personally, while I agree that it is easy, it
is hardly intuitive or obvious, and I too would prefer an explicit clear
method for mutable sequences.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Will McGugan wrote: > Steven Watanabe wrote: > >>I know that the standard idioms for clearing a list are: >> >> (1) mylist[:] = [] >> (2) del mylist[:] >> >>I guess I'm not in the "slicing frame of mind", as someone put it, but >>can someone explain what the difference is between these and: >> >> (3) mylist = [] >> >>Why are (1) and (2) preferred? I think the first two are changing the >>list in-place, but why is that better? Isn't the end result the same? > > > I'm wondering why there is no 'clear' for lists. It feels like a common > operation for mutable containers. :-/ > Because it's just as easy to create and assign a new empty list (and have the old unused one garbage collected). l = [] is all you need! regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven Watanabe wrote: > I know that the standard idioms for clearing a list are: > > (1) mylist[:] = [] > (2) del mylist[:] > > I guess I'm not in the "slicing frame of mind", as someone put it, but > can someone explain what the difference is between these and: > > (3) mylist = [] > > Why are (1) and (2) preferred? I think the first two are changing the > list in-place, but why is that better? Isn't the end result the same? I'm wondering why there is no 'clear' for lists. It feels like a common operation for mutable containers. :-/ Will McGugan -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Diez B. Roggisch: > The reason is that l = [] just rebinds a new object (a list, but it could be > anything) to a name, while l[:] = [] will alter the object _referred_ to by > l. That is a HUGE difference! In my programs I have seen that there is another practical difference between version 1 and 3: (1) mylist[:] = [] (3) mylist = [] If you create a big mylist again and again many times, the version 1 uses the memory more efficiently (probably less work for the garbage collector), and the program can be (quite) faster (this is true in some implementations different from CPython too). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven Watanabe wrote: > I know that the standard idioms for clearing a list are: > > (1) mylist[:] = [] > (2) del mylist[:] > > I guess I'm not in the "slicing frame of mind", as someone put it, but > can someone explain what the difference is between these and: > > (3) mylist = [] > > Why are (1) and (2) preferred? I think the first two are changing the > list in-place, but why is that better? Isn't the end result the same? > > Thanks in advance. > -- > Steven. The solution (1) and (2) clear the content of the list (replace the content of the list by an empty list for (1), or delete the content of the list for (2) while the solution (3) creates a new list and binds the old name to the new list. This means that you don't actually modify (clear) the initial list. Just try it out: >>> a = range(10) >>> a [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> b = a >>> b [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> c = a >>> c [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> a.append(10) # assert that a, b and c point to the same list >>> a [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> b [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> c [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> b = [] >>> b [] >>> a [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] >>> del c[:] >>> c [] >>> a [] >>> Here we can see that using method (3) on b didn't modify the content of a (even though we asserted that they were the same list). Using method (2) on c, the other hand, did modify the content of a. This is because method (3) on b actually created a new list and bound "b" (as a name) to that new list, without modifying the list "b" used to be bound to (which is the one "a" and "c" are still bound to). -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
Steven Watanabe wrote: > I know that the standard idioms for clearing a list are: > > (1) mylist[:] = [] > (2) del mylist[:] > > I guess I'm not in the "slicing frame of mind", as someone put it, but > can someone explain what the difference is between these and: > > (3) mylist = [] > > Why are (1) and (2) preferred? I think the first two are changing the > list in-place, but why is that better? Isn't the end result the same? No. Consider this simple example: class Foo(object): def __init__(self, all_my_thingies): self.all_my_thingies = all_my_thingies things = [1,2,3,4,5] f = Foo(things) things = [] # I've been robbed print f.all_my_thingies # or not? The reason is that l = [] just rebinds a new object (a list, but it could be anything) to a name, while l[:] = [] will alter the object _referred_ to by l. That is a HUGE difference! Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
> I know that the standard idioms for clearing a list are: > > (1) mylist[:] = [] > (2) del mylist[:] > > I guess I'm not in the "slicing frame of mind", as someone put it, but > can someone explain what the difference is between these and: > > (3) mylist = [] > > Why are (1) and (2) preferred? I think the first two are changing the > list in-place, but why is that better? Isn't the end result the same? A little example will demonstrate: >>> x = [1,2,3,4,5] >>> y = x >>> z = x >>> x = [] >>> y [1, 2, 3, 4, 5] * >>> z [1, 2, 3, 4, 5] >>> y[:]=[] * >>> z [] [*] note the differences in the results of "z", even though we've never touched "z" explicitly By using x = [] you set x, but you do not clear the list that other items (y & z) reference. If you use either of the two idioms you describe, you effect all items that reference that list. -tim -- http://mail.python.org/mailman/listinfo/python-list
Question about idioms for clearing a list
I know that the standard idioms for clearing a list are: (1) mylist[:] = [] (2) del mylist[:] I guess I'm not in the "slicing frame of mind", as someone put it, but can someone explain what the difference is between these and: (3) mylist = [] Why are (1) and (2) preferred? I think the first two are changing the list in-place, but why is that better? Isn't the end result the same? Thanks in advance. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
