"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.
Well this is clearly a goer ;-)
Python or most dynamic languages are are so great because of their common sense towards the "implicit".
Python is not "most dynamic languages", and does not seem to implicitly "cast" objects into other types. Python may be "dynamic", but it's also "strongly typed", a feature I consider a benefit, though you are of course free to disagree.
c = "%s%s" % (a, b) There is an implicit str(b) here.
Not if you read the docs, as another poster has pointed out.
''.join(["string", 2]) to me is no different then the example above.
TypeError: sequence item 1: expected string, int found
Which pretty much supports my initial argument -- if a non-string got into the list, something needs to be fixed, and it isn't the behavior of the join() method!
Nick
-- http://mail.python.org/mailman/listinfo/python-list
