[Python-Dev] Re: Stability and change (original) (raw)

Christopher Petrilli petrilli@amber.org
Mon, 08 Apr 2002 12:31:06 -0400

On 4/8/02 12:07 PM, "Guido van Rossum" <guido@python.org> wrote:

In Python's case, that's a vanishingly small fraction of the total user base. Even the alpha/beta releases are downloaded by a disappointingly small number of people. Many Python users apparently consider themselves early adopters when they install 2.2 final when it comes out. This sounds to me like we must strive to make those releases as stable as possible, rather than the reverse. Certainly, when I download something that is termed a release, I think of something that's been tested. Perhaps we simply need to more actively solicit people to participate in more early stages of the process.

Unfortunately, what's frequent for one person appears at glacial speed for another. Since 2.0 came out, we've new Python releases (counting only the minor version numbers) every 6-8 months. Apparently the conservative forces in the community find this too often. Are the conservative forces truly the majority, or are they simply the most vocal? Often those whose voices are loudest represent the smallest percentage of the population. Perhaps the best thing to do is to take a poll, or something. This isn't great, but it certainly is more indicative than a self-selecting group that complaint about something. WE all know that thanks comes rarely, and only after complaints.

A lot of people, myself included, don't bother to read the news groups because of the noise ratio. This selects out those who are "content" with the status quo.

I though that PEP 285 did everything humanly possible to make the bool type backward compatible. But according to the c.l.py crowd it's not enough.

The people I care about are not the people who "play" with Python for fun and games, but those who do serious work with it. For example, Red Hat, and their installer work, the guys at the Hubbel Telescope and NASA, LLNL, Zope, others who we don't know about. These are the people with something on the line besides their preferences when the Python core team makes a decision. I don't want to say someone is a second class citizen, but certainly, one must weigh the importance of having a specific user. If we had thousands of individuals clamoring for a new process, it would sway me more than a few vocal people.

Try telling Logajan or Rubin that. :-(

There will always be disagreement with the decisions, regardless of what the decision might be. The goal is to please a majority.

I sure hope so, but in practice, even the smallest incompatibility between 2.Y and 2.(Y+1) seems to trip people up.

Most of my "trip ups" have been sloppy coding on my part. The only one that nailed me of any size was the change in various things that now require tuples. It said it in the docs, but hey, I didn't read the docs! ;-) This is one place where a warning would have definitely helped a lot more, but in the end was my mistake. Perhaps Python needs a --pedantic option? :-)

Have multiple versions installed, with binaries named "python2.1, python2.2, python2.3" and "python" linked to the most popular one. Bleeding edge users can place a symlink to python2.3 in their personal bin directory if they don't want to type "python2.3" all the time.

Exactly, and something I know dozens of people personally who do. I've even considered removing "python" as a link to anything, except for sloppy code that uses it rather than calling the version it expects. Certainly those who have worked with Java/JVM know the pain of version incompatibilities better than we ever have.

I will point out that it is trivial to maintain multiple X.Y releases on the same machine, and for example, I have 1.5.2, 2.1 and 2.2 on my main development machine currently, and simply always make sure to specify the Python release in the #! header at the top of the file. This way in the future, I can still use it.

Apparently few people know how to use this properly. Also, there are those who want the impossible: they want no old code to break, yet they want to be able to use bleeding edge packages.

The first is solvable by documentation and education, perhaps even by modifying how the installer works so encourage this scenario. Change all the scripts to use the preferred syntax in the #! component, and make sure we reinforce use of the different library releases.

As for the later issue, medication is perhaps the only suitable option.

A panacea of universal happiness is a wonderful thing, but I think we need to step back and answer the question of who we are trying to please with these proposed changes, whether that group is in fact using Python at any large level, or would use Python at any large level, and whether or not we would alienate people who have been with the community for a large period of time.

This certainly seems closer to resolution that peace in the Middle East. :-)

Intransigence is often the primary problem in all conflicts :-)

As someone commented (and I can't remember who now), this needs to be taken in the context of increasing the spread of Python, rather than pleasing a potentially vocal minority. If such a change is advantageous to the spread of Python and its adoption, then I'm 100% for it.

Unfortunately, the vocal minority is claiming that Python's fast-paced releases are what keeps the spread from going up. Are they right? Who knows?

Instinct has served you and the community well so far, and you are the BDFL. I would say take a poll of people who have been involved in the community for an extended period, and we all know who they are. Find out what they think the issue is, and the resolution. We'll call it representative democracy. :-)

Chris

| Christopher Petrilli