6 ms·
Because Python's design philosophy is that, for a given operation exposed by the language, there should ideally be a single clear way of doing it, and that phil
by andolanra 6y ago
Because Python's design philosophy is that, for a given operation exposed by the language, there should ideally be a single clear way of doing it, and that philosophy is optimized around reading code rather than writing it. You might need to do a few more edits while you're writing the code, sure, but now a reader of your code will always find sum for numbers and join for strings without even having to examine the context of the code in question.
I'm not saying that's necessarily the correct design approach, but it's the one that Python has explicitly established as their guiding principle! A different language will take a different approach: Ruby, for example, likes to build multiple alternative ways of accomplishing the same thing, which leads to multiple aliases for built-in methods or various alternative flags that allow a method to behave in a number of ways. It shouldn't be a surprise that Ruby is fine with the equivalent operation:
irb(main):001:0> ["a", "b"].sum(identity="")
=> "ab"
But that's because Ruby's design sensibility is different from Python's. You might like one better than another, but they both come from a consistent vision of how to design programming languages.
- saagarjha 6y ago> Because Python's design philosophy is that, for a given operation exposed by the language, there should ideally be a single clear way of doing it This philosophy falls apart immediately once you start using Python though. I have yet to see it actually be used for anything but not implementing features that someone wants.
- canjobear 6y agoWhat other languages are you comparing against? I came to Python from Perl and the one-way-to-do-it-ness was noticeable and refreshing.
- saagarjha 6y agoI don't think many other languages make that claim, and I think it's generally an anti-goal in diverse multiparadigm languages. I don't even understand why Python tries to have it: I can think of three fairly idiomatic ways to sum a list of numbers right off the top of my head; it's immediately clear that such a proposition is not feasible for the language. The only time I have heard it come up is when there is an unsaid accusation that the language is getting "to complex" and someone wants to block the addition of a feature…
- oh_sigh 6y agoBut in almost all of the langauge, TOOWTDI is not strictly enforced, it is merely a highly encouraged convention. For example, why am I allowed to do mylist = [x*2 for x in range(1,10)] but also do mylist = [] for x in range(1,10): mylist.append(x*2) That's two ways to do the same thing, and I bet you would find a lot of the latter in beginner's python code. I think a better choice would to just have a linter which enforced the correct usage of sum() and join(), and not the implementation itself.
- nitrogen 6y agoUnless something has changed recently in Ruby, won't identity="" as a parameter just assign the empty string to a variable named identity and then pass the empty string as an unnamed positional parameter?
- DougBTX 6y agoYou're right, it should be: ["a", "b"].sum("")
- hawski 6y agoLet's concatenate strings. a + b f"{a}{b}" "".join([a, b]) "{}{}".format(a, b) If a == b, then you can also, which itself is a bit ridiculous: a * 2 Is mentioning StringIO considered cheating? I would feel the Zen if Python would have a separate concatenation operator, it could be even the same for strings and lists. Lack of the operator in popular languages is my pet peeve.
- Izkata 6y agoYou forgot: "%s%s" % (a, b) (Still works at least as of python 3.6)