[Python-Dev] Re: Stability and change

[Christopher Petrilli]

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.
<wink>

>> 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