[MichaelMoser123]

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

That is a python design principle https://en.wikipedia.org/wiki/Zen_of_Python

Now there are multiple (sometimes very confusing) ways to import stuff in python, so I am not quite sure if this principle is being followed.

https://realpython.com/absolute-vs-relative-python-imports/

[cure]

The other place where this principle is completely ignored is when it comes to Python packaging, which is a complete and utter disaster.

There are many different ways to package Python, none of them are feature complete, and the result is an absolute maintenance nightmare for those of us who have to maintain tools that have Python dependencies.

Perl got packaging right, there's one way to do it, and it just works!

[a3n]

> Python packaging, which is a complete and utter disaster.

This is a huge barrier to entry for the first time or casual contributor. And when you try to figure it out (or figure it out again), you have to triage all the old and new overlapping documentation.

[perigrin]

There isn't one way to do it in Perl (EUMM, Module::Build, Module::Build::Tiny, Module::Install etc), we just tried to make sure that they all interoperated cleanly. And we have things like the Toolchain Summit to make an emphasis on that.

[cure]

I stand corrected, thank you :) Clearly, you succeeded in your mission since it feels like there's one way, and most importantly, it 'just works'. Many, many thanks to you and everyone who made that happen!

[Izkata]

Also don't forget, how to manage a virtualenv and how to do parallel processing.

[hedora]

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

In practice, perl came closer to achieving this than python.

[kevin_thibedeau]

Minus the dozens of cryptic special variables.

[prakashk]

Every (most?) special variable has a non-cryptic alias, if only one were disciplined enough to choose to use the alternative.