Steve wrote:
On Oct 17, 8:28 pm, Tim Chase <python.l...@tim.thechases.com> wrote:
Christian Heimes wrote:
Alan G Isaac wrote:
On 10/16/2009 5:03 PM, Christian Heimes wrote:
It's not going to happen.
That's a prediction, not a justification.
It's not a prediction, it's a statement. It's not going to happend
because it violates Guido's gut feeling as well as the Zen of Python.
I'm not sure how it violates ZoP...particularly
Simple is better than complex.
[complex is special casing or explaining why there's an error]
Special cases aren't special enough to break the rules.
[raising an error is a special case]
Although practicality beats purity.
In the face of ambiguity, refuse the temptation to guess.
[there's nothing ambiguous about sum() meaning "+"]
If the implementation is easy to explain, it may be a good idea.
[sum(lst_of_strs) should do exactly what it says..."+" 'em]
-tkc
Sorry about the late reply.
You overlooked "There should be one-- and preferably only one --
obvious way to do it.", which in this case is join()
That doesn't mean *only* one obvious way to do it, and more importantly
it *does not* mean *only one way* to do it.
To me the current implementation is blatantly correct. sum is an
operation on a list of numeric values, returning a numeric value -
this is why we have the seemingly strange "".join() rather than [].join
("")
I think duck typing is wonderful so long as its specific applications
make sense.
Duck typing is about not guessing what will make sense, or what needs
will arise, to the users of our code.
We don't handle integers being passed to len() do we?
Technically we could return the number of digits but it wouldn't make
sense as len() works on iterables.
Ints do not have a __len__ method, so why should len() work on them?
Strs, on the other hand, do have an __add__ method.
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
