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 <something> which lets you do "del aDict[<something>]" 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 their side of this. Don't just accept it. Try to figure out why these really bright people have taken this standpoint. They've probably heard your question 20 times before, and might be bored to go through all the arguments again. (Part of this is to figure out who are the guys you should really listen to. If people are allowed to commit code to the Python code base, that's a hint that they know what they are talking about... http://sourceforge.net/project/memberlist.php?group_id=5470 In other words, you cn safely ignore me... ;^) I'm sure Python can and will be improved in various ways, and that some people who are fairly new to Python might come up with bright ideas. I also suspect that those old farts (like me) who have used it for ages might respond in a stubborn and reactionary way. That doesn't change the fact that the overwhelming amount of comp.lang.python threads about flaws in Python and suggestions for improvements in the core would make Python worse rather than better if they were implemented. I know that the last time (the one time) I claimed that Python had a really bizarre bug, it turned out that I was just being blind and sloppy. -- http://mail.python.org/mailman/listinfo/python-list
