[nickserv]

I've been using Python since the 2.3 days, and it's great to see it become so popular.

But lately I think the language has grown more complex, new functionality is being added all the time.

I feel this is unfortunate in some ways. It's not so true anymore that "there's one way of doing things, and it's obvious", which was one of the best things about the language IMHO.

My feeling is the language developers should slow down a bit on new features and focus on packaging and speed.

Still, it's a great, flexible language, and I think it will keep on being relevant for a long time.

[brundolf]

The packaging/environments story is really just unacceptable to me in the year 2021. Coming from the JS world, Python's is just a total mess. And it can't even really lean on the "Python didn't start out as a language that needed that stuff" angle, because JS was in the same boat, and overcame it.

Maybe it's too late and it would be an XKCD "now there are 15 competing standards" situation at this point. But Python desperately needs an all-in-one, officially-sanctioned, package manager/manifest format/bundler/etc that keeps all dependencies and environment info in the project directory, not in global symlinks that get shuffled around by a global collection of "virtual environments". It needs to get installed automatically alongside Python itself. It needs to be prescribed by the Python Foundation. And it needs to be here yesterday.

[atom_arranger]

As an occasional Python developer this is the thing I dislike most about it. I always end up spending an hour or two figuring out how to get things installed and working right.

To be fair Node also requires some work to be setup correctly but it seems easier.

[nsonha]

I thought it should be better now? Last I checked people used poetry for this

[atom_arranger]

I first heard of Poetry (posted to HN) several minutes after making this comment.

I’ll definitely give it a shot next time I do any Python dev.

[jnxx]

Maybe Guix can save the packaging aspect, which would need to include C and C++ extensions.

[brundolf]

We've got pip, conda, poetry, etc, all with their different advantages and disadvantages. I think the only thing that could solve the fragmentation problem is an authoritative solution from the Python Foundation itself. Cohesion is what's needed, not more options.

[jnxx]

The thing is that a comprehensive Python packaging solution would need to include packaging of C and C++ extensions at least. And that's not simple. In the meantime, Guix is establishing itself as a cross-language package manager wich can define an own distro, or run on top of a POSIX system like Debian, Ubuntu or Arch. And it is rock solid and currently features around 17,000 packages. A new Python packaging solution would have a hard time competing with that.

[brundolf]

I believe pip and conda already support native modules. I'm not saying it was easy to get there, but it's a solved problem at this point. The problem that still needs to be solved is project-scoped dependencies vs system-scoped dependencies. Virtual envs are a hacky workaround that causes all sorts of problems. I'm convinced Python has been one of the major drivers of Docker's adoption, because any given module is concerned with the entire system.

[jnxx]

I think the biggest drawback is a cultural one: The Python developers and the wider python community do not value backwards compatibility.

This has the consequence that it is easy to write new code, or to maintain short-lived code, like what is typical for a SAAS company or a start-up, but it will become almost impossible to maintain legacy code. And as Python becomes older, more and more of the total of Python code will become legacy code. The focus on writing new code rather than reading and maintaining old code is also very obvious by the befuddling added complexity of the language. Nobody knows all of C++, but I am not sure whether many Python developers know all of Python syntax and PEPs.

And what makes it even worse is that a lot of development in Python initially came from academic science and universities, like Numpy, but actually most scientific code is legacy code, because researchers and most research institutes operate differently from start-ups.