Are new Python devs forgetting the Zen of Python: "There should be one—and preferably only one—obvious way to do it"?

Python Help
1

At Twitter/X, someone posted a Python puzzle:

L = [1, 2, 3, 4]

for i in L[::-1]:
…print(i, end=’ ')

This’ll output:

4 3 2 1

This could’ve been done more intuitively like this:

L = [1, 2, 3, 4]

for i in reversed(L):
…print(i, end=’ ')

But I guess the one who posted it was trying to make things difficult/complicated since it was a ‘puzzle.’ Still some of the comments on the post were giving the impression that it was a teaching moment, that they were going to actually use this code in their projects. This worried me ‘cuz it forgets this: “Python generally has one way of doing things” refers to a core philosophy of the language, articulated in the Zen of Python, which states: “There should be one—and preferably only one—obvious way to do it”.

So I commented a reply to the puzzle: “One of the things that attracted me to Python was the philosophy that there should only be one way of doing things. Lately, people have been introducing multiple ways of doing things which is making Python less intuitive, overly complicated. Like L[::-1] instead of reversed(L).”

Someone replied: “Bro chill. It’s good to have options.”

I replied: “When you’re debugging a complex project w/ many programmers working on it, code that does the same thing but written in a myriad of ‘options’ makes for hard-to-read code & a nightmare to debug.”

What do you think? Are Python devs forgetting what makes Python great and successful compared to other programming languages?

One of the reasons PHP became unpopular is that so many PHP frameworks (Laravel, Symfony, CakePHP, etc.) appeared and they were adopted by different companies so PHP devs had to master a new framework if they changed jobs. Something similar is happening to Python’s web dev: Python devs now have to master Django, Flask, FastAPI depending on their client. And if you don’t use one framework for months, you’ll lose your mastery of it. If more frameworks come up, the same problem PHP programmers face will descend on Python devs (and it’s already occurring). I wish the Python Development Foundation would address this to avoid the mess PHP devs face.

3 Likes
2

The Zen is a funny poem which does contain many good ideas, but it should not be taken as dogma regarding the use or design of the language. The line you quote is a particularly misquoted one, since people tend to overlook the word “obvious” there.

6 Likes
3

There have always been multiple approaches to any problem, Python is no different in this regard.

I look at the Zen of Python as a set of proverbs to spark thought. Like all proverbs, there are contradictions among them. They are not a set of rules.

Times like this can be good moments to join the conversation and provide your own perspective, but you can’t be too prescriptive. This example was just a puzzle, so don’t take it too seriously. If fragments like this help pull people into the Python world and keep them excited about programming, it’s all good.

This sounds roughly like, “kids these days!” Like I said, don’t take these puzzles too seriously. You could also criticize it because neither [::-1] or reversed() is used much in real code at all. For me it goes on the trivia pile along with which integers are interned and which are not.

This has been true for decades. Python is very popular, and will be used by many people in many ways. A proliferation of web frameworks (or packaging tools, or plotting libraries, or anything else) is a sign of community energy and low barriers to entry. Those are good things overall.

I’m not sure what the Python Software Foundation can do to affect the situation (I won’t call it a mess). They can’t (and should not try to) forbid people from creating new frameworks. They aren’t going to bless any particular one. Maybe you have a different idea I haven’t thought of.

You aren’t happy that Django, Flask, and FastAPI are all popular now. If somehow the PSF had prevented this proliferation, we’d all still be using frameworks that were at the forefront when Django appeared: CherryPy, Turbogears, and Pyramid. Would that be good? The three you mentioned are more presumably more popular than those because they improved on them. And CherryPy improved on CGI.

Progress is good. Options are good.

6 Likes
4

That trivia pile is a spectacular source of material for quizzes and puzzles.

5

Good points, but please address this concern: “When you’re debugging a complex project w/ many programmers working on it, code that does the same thing but written in a myriad of ‘options’ makes for hard-to-read code & a nightmare to debug.”

Imagine buying a new car and they’ve changed how to turn on the lights, the wipers, the air-conditioner, the radio. Happened to me when I borrowed my brother’s VW – the way of doing the same things were so vastly different from my Mazda.

1 Like
6

Easy. This is where project standards and code review are important. Having a team with a shared sense of what is readable and maintainable code is crucial for any project, regardless of the language it’s written in. Python (and in particular the Zen item you quoted) reflects that principle, but it doesn’t enforce it - no language can.

And having options is good[1]. What is readable and maintainable is context sensitive - a comprehension might be ideal in one place, but an explicit loop might work better somewhere else. You have to have options for your judgement and sense of aesthetics to have any meaning in the first place.

  1. Up to a point - I’m looking at you, Perl :slightly_smiling_face: ↩︎

4 Likes
7

This is a concern, yes. But what can we do about it as a community? The Python world has been growing and innovating for more than 30 years. There are bound to be multiple ways to do similar things.

Ideally within one organization, similar things will be done in similar ways, but I can tell you from experience, this rarely happens. As you point out, this is not specific to Python. It’s true in any rich ecosystem.

8

And people tend to overlook the next line even more:

Although that way may not be obvious at first unless you’re Dutch.

10 Likes
9

Hello, @bluelobe, and welcome to the Python Software Foundation’s discussion forum!

Please see the following pages, which offer helpful information about this forum:

Note that the first of those two pages contains a section entitled How do I post code snippets, error messages etc?. Within that section is an explanation of how to format Python code by enclosing it between two lines with triple backticks. This could be done with your first posted example of code:

```
L = [1, 2, 3, 4]

for i in L[::-1]:
    print(i, end=' ')
```

Then it would appear as follows, which displays its original indentation and quote characters properly:

L = [1, 2, 3, 4]

for i in L[::-1]:
    print(i, end=' ')

That section also explains other techniques for formatting code for display.

Interestingly, there is more than one obvious way to position hyphens within a sentence :grin::

There should be one-- and preferably only one --obvious way to do it.
1 Like
10

reversed() was added in Python 2.4 (see Highlights: Python 2.4 | Python.org )

I’m convinced that the “less intuitive” slicing method worked prior to 2.4 as I remember being puzzled by it when I was first learning Python, prior to version 2.4. So, the introduction of reverse() was the actual exception to the Zen of Python.

3 Likes
11

As is very common, you have misquoted this line from the Zen of Python:

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

Notice how the spacing around the em dashes are inconsistent, this is intentional and is meant to humorously allude to there not always being one obvious way to do it.

10 Likes
12

It is one of the reasons why it is my favorite line in The Zen.

2 Likes
13

Monoculture is bad.

One of the conclusions I’ve drawn from the unfortunate recent events in the Ruby community is that Rails, and therefore Shopify, held much too much power and were too central for that community to function without them. Luckily, in Python we have many options, many distinct corporate interests which we attempt to counterbalance against one another, and independent governance structures.

It’s good that we have options for web frameworks. It’s good that we have options within packaging[1]. It’s good that we have options for linting and formatting.[2]

If we didn’t have various alternatives, not only competing but also feeding into one another and collaborating, it could mean that power is beginning to consolidate in a dangerous way.

  1. Yes, we have too many. Another topic for another time. ↩︎

  2. One of my concerns with the mass adoption of ruff is that we have lost energy in a lot of the alternative projects. I think that’s inevitable, but I still use flake8 because having local plugins is super useful. ↩︎

5 Likes
14

Having one obvious, intuitive, elegant way of coding things vs allowing the proliferation of complicated-just-to-show-off, sloppy, unintuitive, hard-to-understand coding leads to a programming language becoming unpalatable for most decent coders. Once it becomes the norm, it’ll be difficult to put the garbage-genie back in the bottle. Imagine Python having ten or more frameworks, each taking months to master, each required by a myriad of clients. It’ll end up like PHP, basically where developers who master one framework can’t easily transfer to another company or take on a project ‘cuz they’re using a different framework.

1 Like
15

Do you have any ideas about how to achieve what you are looking for? No one set out to make Python a large diverse ecosystem. It happens because it’s used by many people in many ways, and has been for more than 30 years.

What do you want us to do?

2 Likes
16

No need to imagine

1 Like
17

Although practicality beats purity.

2 Likes
18

That’s not a puzzle. Or, well, there’s one puzzling thing about it, namely why they didn’t simply do print(*L[::-1]).

And there’s nothing “difficult/complicated” about L[::-1], it’s a basic and very well known standard thing.

4 Likes
19

It matters how you define any given “thing” of which there should be one way. Everyone will define it differently, with different scopes, in different contexts. Trying to strictly apply the saying across contexts or over an ecosystem isn’t really meaningful. It can still be a helpful guide when deciding how to design within a project, but it’s not an absolute law.

3 Likes
20

Three-part slices are unusual in the first place, and -1 as a step is unusual. It’s punctuation, so it’s hard to search for. reversed() is a word that hints at what is going on, so the slice syntax is easily more difficult than that.

Whether it’s basic and well-known depends on where you are in your learning, and the original puzzle is meant for new learners. That puzzle might be how [::-1] becomes well-known among that crowd.

But why do we have to debate what is difficult or not in the first place?

2 Likes