Comment by andolanra | Hacker News Reader

Comment by andolanra | Hacker News Reader

Parent Full thread

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.

> 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.

What other languages are you comparing against? I came to Python from Perl and the one-way-to-do-it-ness was noticeable and refreshing.

I 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…

But 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.

There's probably a lot more than two ways too, eg.

    mylist = map(lambda x: x * 2, range(1, 10))

map will return an iterator, not a list

Then call list(map(...

The point stands.

Only in Python 3, not Python 1 or Python 2.

Let'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.

You forgot:

  "%s%s" % (a, b)

(Still works at least as of python 3.6)

Unless 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?

You're right, it should be:

    ["a", "b"].sum("")

Reply on news.ycombinator.com