Hacker News new | past | comments | ask | show | jobs | submit login

Python has taken many things away, hence the 2 to 3 transition. And people didn't like it. Not one bit. We even had to bring features back (u'', %, etc) after taking them away.

Now I agree, if I could snap my gantlet I would remove a lot more. We don't need Template(), the wave module or @static and so many other things. And we could have cleaned up Python more deeply in the transition.

But reality is very messy.

Plus, you gotta realize that the Python community has nowhere near the resources of languages such as Javascript. JS is developed by giants that poured hundreds of millions in it and set dozens of geniuses to work solely on improving the implementations.

Python barely (and this is recent, we had less before!) has a few millions for operating the PSF related activities, which includes organizing PyCons all over the world and hosting python.org or pypi.org. Only a handful of people are actually paid to work on Python.

So you have a giant, diverse community, with billions of lines of code for so many different activities, and not enough resources to work on cleaning up everything.

Welcome to life, this stuff where if you want to get things done, you have to compromise.

In practice, at a workplace, you can probably remove quite a lot through linting or some other form on enforcement. In general, as long as the majority of people out there use the same good style and don't use stuff like Template(), I don't think it'll be an issue for newbies. The real issue is when you have many methods of doing the same thing that are all popular.

Yes but I do understand the problem. E.g learning packaging in python is a terrible experience, not because it's hard, it's really not, but because of the noise we accumulated.

> not because it's hard, it's really not, but because of the noise we accumulated.

In an effort to avoid the noise, would you be so kind as to point me in the direction of the current way to handle packaging in python? I don't work in Python consistently enough to be up to date on this, but every time I do it's hard for me to suss out the best way to package up and distribute the work for internal end users.

I don't know of any resource that make a good summary of everything, that is up to date and pragmatic.

The least worst is https://packaging.python.org/ but it skip major issues I know beginners have (multiple installed Python, path problems, etc), it's not clear what works on what OS. It also promotes pyproject.toml over setup.cfg, and ignore pex and nuikta.

That's one of the numerous short pocket books I should write.

Give me a book deal, I'll do it :)

Thanks for the link! I've worked with Python long enough to be familiar with those beginner issues, just infrequent enough (and even more so for stuff that needs packaged) that I've never quite been able to wade through the noise.


> not because it's hard, it's really not

and then

> Give me a book deal, I'll do it :)

gave me chuckle. Because they're both true: it's not necessarily hard, and yet despite that it still needs a short book to really tackle the subject. That's such an out of place state for something related to a core component of Python.

You still can remove from the spec of python 4 while letting cpython4 implementation keep using python3 constructs also.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact