Hacker News Reader

Comment by softwaredoug | Hacker News Reader

Seems to violate "There should be one-- and preferably only one --obvious way to do it."

Sorry, but I think this is a poisonous, thought-terminating cliche.

Python has had multiple ways of doing many things for a very long time, and the longer you program in any language, the more you realize there are often many solutions to a problem and the "best" approach either depends on context or you realize there is no one "best" approach and go on preference.

I think the idea should be judged on its own merits without having to consult the Zen. That said, I seriously don't see the point of it. Python 3 already forced everybody to convert all their print statements to look like function calls, and now GVR wants to bring the old style back as an option? It's just parenthesis, what's the point?

If he wants to put that new parser to work, how about taking another look at multi-line lambdas?

The key words are ‘preferably’ and ‘obvious’ (although that way may not be obvious at first unless you're Dutch). It's fine if there are merely multiple ways to do something, as long as you're not actually giving people tough choices.

> Python has had multiple ways of doing many things for a very long time ... the more you realise there are often many solutions to a problem

But "solution" and "ways of doing things" from a language perspective are different. You can one way of doing something in a language, yet provide different implementations of the same solution. The difference is how different a "way" is at some level of abstract (vs "syntactic sugar).

Inventing new sentences is needed everyday, inventing new words much rarely so. "programmable program languages" or those highly dependant on custom frameworks fall prey to this: where code becomes a personal space that is hard to break into. You have to "terminate-thought" at some level, if else everyone "creatively" reinvents the low level (e.g. built-ins) then no collaboration is practical; accept the standard building block, and implement your solution with those.

> there is no one "best" approach

but there are "better" approaches

"There should be one-- and preferably only one --obvious way to do it."

This principle is often repeated for Python, but does it have any bearing on reality today? With every release of Python (and indeed for many other languages), new features give you even more ways of doing things.

Python is 30 years old - it's no longer the small language it may once have been, but is now chock-full of features. Maybe once there was an "obvious way to do it", but I don't thing this is true today.

Surely this principle becomes more important the more stuff you put in?

Says the line with two different hyphenating styles.

It's an Easter egg.

These look like brackets, not binary operators. So, that's one style, but a rather unobvious one, and also contradicts PEP8, which says (as the very first thing in the section on inline spaces!) to avoid whitespace immediately inside brackets.

So pedantic but I love it. For the GP, what you are looking for is them em dash (—) with no spaces around it, because the dash is its own form of punctuation.

A double-dash is a perfectly valid substitute for an em dash given that most (no?) keyboards have it on a key. Seems like a waste of time to always have to look up an escape code or copy/paste from somewhere when the intent of "--" is clear.

I don't hold random comments on the internet to the highest standard because I am not a monster. However they are not equivalent and the em dash is a sign of extra polish.

It’s option-shift-hyphen on a Mac. And you can get at em dashes on an iOS keyboard by long pressing the hyphen. Not so difficult.

Compose--- on anything with a compose key. Linux mostly and Windows with the WinCompose program.

Some style guides allow for surrounding the em dash with spaces. It's a matter of preference.

> Seems to violate "There should be one-- and preferably only one --obvious way to do it."

Just as representing a vector of numbers as a tuple, a list, a dictionary, a numpy matrix or a numpy array. And don't get me started on multidimensional arrays.

Reply on news.ycombinator.com