Nick Vargish wrote:
"news.sydney.pipenetworks.com" <[EMAIL PROTECTED]> writes:
Really ? Then why are you using python.
Try "import this" at a Python prompt. I didn't invent "Explicit is better than implicit."
Thanks for the pointer. Let's see how many zen points are for the OP's idea vs against
Against Explicit is better than implicit. Special cases aren't special enough to break the rules.
On the wall Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. Namespaces are one honking great idea -- let's do more of those!
For Beautiful is better than ugly. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Although practicality beats purity. Unless explicitly silenced. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
From the point of view of someone who actually *tried* doing this to the relevant method, while maintaining backward compatibility. . .
Against:
Explicit is better than implicit Special cases aren't special enough to break the rules
In the face of ambiguity, refuse the temptation to guess - there are plenty of ambiguious cases to handle Simple is better than complex (Semantics & C code) - and much complexity in dealing with the ambiguities Errors should never pass silently. Unless explicitly silenced. - and a bunch of them are likely to indicate errors. Maybe. Readability counts (C code) - This makes the implemenation hard to read If the implementation is hard to explain, it's a bad idea. - or explain to anyone, too
For:
Beautiful is better than ugly. - the explicit calls to str() aren't that clean.
There should be one-- and preferably only one --obvious way to do it. - Currently listcomp, genexp, map, string interpolation, etc
IMO, the rest can be used to argue either side, or simply don't weigh heavily either way.
The things that make it a real cow are the current behaviour of auto-promotion to the Unicode version when there are any Unicode strings in the list, and the existence of __str__ and __repr__ methods which actually return instances of unicode rather than str.
Calling str() explicitly makes the different behaviours unsurprising. Trying to do the same thing behind the scenes has the potential to make the method behave *very* suprisingly depending on the objects involved.
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
