Meta: how we evaluate / reach consensus on / approve ideas as a community

I have to disagree with you. The effect of support vs shut-down (especially from more senior members) could be greater than you try to portray here.

After all, even in our society, it is often regardless of how ungifted a person is, the status, support and connections of their rich parents push them to the top. And the genius kid that was in your class in first grade is working average job due to lack of resources and support.

Also, following your logic, there is an emphasis on a human variable, which is undeniably important, but if unaddressed properly results in good ideas being dismissed due to the fact that the person wasn’t determined/resourceful/motivated enough.

1 Like

OK. I’ll try to make sure I’m less discouaging in future. It won’t make the ideas any more likely to get accepted (the flaws in the arguments will still be present, after all) but :person_shrugging: If my attempts to help people improve their proposals aren’t welcome, others can provide their own feedback with my blessing.

(Just to be clear - personally, all I offer is opinions in discussions like this. I make no pretense that I’m trying to mentor contributors. That’s a much harder job, and one I don’t have the time or inclination to take on).

I was not referring to you personally. It was my opinion regarding what you said. Although, I don’t know many people (including myself) who couldn’t use an improvement in these skills.

I generally don’t think encouragement can be harmful as long as the probability of success is conveyed clearly.

One can be critical, but encouraging at the same time - it is not necessarily binary. I think the benefits of the fact that there are many volunteers here is not exploited due to the reason that people employ the same philosophy and approach that is being used in coorporate environment where someones salary needs to be justified and chasing unicorns is too risky.

1 Like

Yes, I should have said ‘only 2 removed other than those proposed in the PEP’, written 5 years ago and discussed, I believe before that. At least 27 modules were originally proposed for deletion; 5 were moved to ‘keep’ in the PEP. Of the 22 in the PEP, 3 were removed in 3.12 and the other 19 in 3.13.

1 Like

I think you foundamentally misunderstand how I use python.

For me, every dependency is extra hassle, while the expectation of using the stdlib was: “this will work until python3 exists”. I only use python packages that are present in the linux distribution I use, since I have no interest in compiling stuff in embedded systems, and with modules using rust, it’s even worse.

Now the assumption of stability is broken and I have plenty of .py files that will stop working once I need to update my LTS distribution.

And this is just a waste of my time (and many other like me who don’t comment here) for no reason whatsoever. If a module has no serious bugs, there is no reason to remove it just because it hasn’t been updated. So what?

The idea that a program will keep working also years from now has value, and now with python that is no longer the case.

2 Likes

Have you used ANY of the dead batteries that are being removed?

1 Like

Have you used ANY of the dead batteries that are being removed?

Yes. Obviously.

asyncore, cgi are currently in use by me.

Any more snark?

edit: not to forget that I had to patch a bunch of stuff because of distutil being dropped.

That wasn’t snark, that was a reflection of how an empty claim doesn’t carry much weight. Listing the modules you’ve actually been hit with is more useful than just implying that the stdlib should never change (we’ve already heard that argument). So, now that you know that these have been removed, you need to either stay on an old Python, or run one pip command to get access to these on a newer Python - right?

If you want to discuss this, can you make it a separate thread? It seems to be completely unrelated to the topic here, “how we reach consensus on ideas as a community”.

6 Likes

Right. But what I wanted to happen when I chose to use stdlib modules was that I would not ned to touch the code at all until python 4.0 was out.

What instead happens is that I must chose between out of date ssl and ssh or updating the code.

edit: My not so well expressed point was that possibly more than 99% of python developers do not partecipate here.

Getting up-to-date SSL comes with the risk of needing to touch the code, pretty well no matter what. After all, SSL’s interface can change, above and beyond anything the Python library maintainer might have in mind. Theoretically such changes could make the existing Python interface no longer viable.

Stability is a tradeoff, which is why there are LTS release of Linux distros. Or the Python release cycle, for that matter. The standard library aims to be more stable than a given point release of Python; so functionality doesn’t get removed for a couple minor versions after it’s deprecated, and deprecations are carefully considered. And if something was maintained externally before being added, newer changes just don’t get merged. In many of those cases it’s clear where to go if you want the bleeding edge (e.g. simplejson for json).

But there is no ssl in use in my python code there. The only changes are due to dropped modules in the standard library. Python code is not touching SSL, as that is done by a webserver included in the distribution.

I’m saying that overall this community is failing to account for projects that care about being distributable and usable without requiring administrator privileges (remember that pip install might require installing gcc, rustc, and various headers) and that the current trend of taking away things from the standard library hurts those projects.

It’s the kind of thing that should be done in a python4, along with a very clear note that running old code is no longer a goal of the project.

That is kinda how it works with QT for example. You know that code targeting QT5.1 will work with QT5.999, but might require changes for QT6.1.

After all if you are breaking compatibility like from py2 to py3, it’s completely normal to bump to python4.

1 Like

That is a rather serious misconception with a corresponding indictment of the backward compatibility goals of Python. You say this as though running Py2 code wasn’t a goal of Py3, which definitely isn’t the case.

It is well known that removing modules can break some code, if it happened to be using that. You are implying here that the core devs acted willy-nilly, breaking anyone’s code with gay abandon, and showing no respect for old code. That is simply not the case. Have you read the justifications in PEP 594 for the removals?

If you want Python to continue to support these old modules, are you willing to step up as their maintainer? And if not, are you okay with them being completely unmaintained? Because… that’s an option too. Just copy in the file from an older version of Python. You now have a cgi.py in your project directory, and you can import cgi just like you used to. (I just tested it, and you WILL need to make some small tweaks; for example, in Python 3.3, the collections.abc module was broken out. Which means, you are going to have to do some measure of maintenance yourself. It’s really not hard though - not in this situation.)

By whining about this change, you are effectively stating that your personal convenience (not needing to copy in one file from an older Python) is more important than everyone else’s, including the core devs’ who have to maintain it, users of embedded Pythons where every kilobyte counts, and people on slow internet connections who have to download useless modules.

Is that what you’re saying? You are the only person who matters? And if not, then what? You seem uninterested in actual solutions, only in complaining about decisions already made.

5 Likes

Oh, and this part is pure FUD. From my examinations, the modules involved here are all pure Python, so you can simply copy them in. Even if they weren’t, we have wheels. You don’t need administrator privileges to use a venv to install a wheel or a pure-Python package.

(And even if you absolutely have to install something that requires a C compiler, you CAN just install a C compiler without being root, and use that to build the Python package. That’s a bit more hassle than normal though, so I don’t expect people to do that, but as a simple proof, you could always get a separate computer that you have root access to, build the package, export it, and then copy the binary to the one you don’t have permissions on.)

Have you read

Yes I read it. I didn’t agree.

Is that what you’re saying? You are the only person who matters?

???

I am saying that most users of python are not on this forum. I think people can still exist without having an account to discuss.python.org. I know several of them myself.

are you willing to step up as their maintainer?

Yes. But my opinion doesn’t count so it’s rather pointless to join a project where I can only be wrong on account of not being already an established contributor.

Like when I pointed out that some PEP was going to make my library completely useless and I got told “deal with it” by Guido, but when the maintainer of pydantic said the same thing, the PEP got blocked completely instead. Because download counters have their weight.

By whining about this change, you are effectively stating that your personal convenience

Again, why do you presume it’s only me and can’t possibly be more than one person? Because they don’t post here? They can still exist just fine.

Oh, and this part is pure FUD. From my examinations, the modules involved here are all pure Python, so you can simply copy them in. Even if they weren’t, we have wheels.

Once you start designing a project to have external dependencies, it makes no sense to just limit yourself to modules that used to be in the standard library. You can use whatever. And wheels aren’t there for every combination.

Yes, but you’re saying that your experience (and the experiences of a small handful of unknown people that you claim to speak for) is more important than everyone else’s experience, as laid out in the justification for PEP 594. And that IS what you’re saying, since you say that you have read the PEP and simply disagree. That’s fine. You are allowed to disagree, but the PSF is deciding things for everyone, not just for you. I have offered you several solutions that work for you, which don’t require changes to anyone else’s experience, but you don’t want them.

So, your logic is this:

  1. Some modules are being removed from Python, but can be accessed from PyPI.
  2. Some modules that are available on PyPI require compilation.
  3. Therefore the removal of modules from Python demands that everyone have a compiler.

This is a fallacy, but a common one. Please be careful to separate your complaints about PEP 594 from considerations that come when you start making use of additional modules. The removal of cgi from Python did not in any way force you to start using other modules.

I’ll just echo @pf_moore’s request: can this rant / argument please get split into a different thread?

13 Likes