From: Martin v. Loewis on
> Python has had
> previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and
> hardly anyone made a complaint.

I think this is actually false for the switch from 1.5 to 2.0. People
complained a lot, and announced that they won't switch to Python 2 in
any foreseeable future, and indeed, they stayed with Python 1.5.2 for
several years after Python 2 was released.

Of course, the Python user base was much smaller then than it is now,
so the absolute number of complainers surely was never as high is it
is now. Only when Python 4 gets released, even more people will complain
and announce that Python 4 has failed and that they stay with Python
3.8 forever.

From: Martin v. Loewis on
> Well, I'd consider that an official release. Note that I didn't claim
> there was no hope PSF wouldn't change it's mind on 2.8.

I'd like to point out that the PSF formally doesn't have any say in

Instead, releases are created by the release manager, who gets appointed
by Guido van Rossum. Those two listen primarily to the opinions of the
fellow committers (which may or may not happen to be PSF members as

> Regardless of how magnaminous the people of PSF are, the unfortunate
> reality is that trademark owners are forced by the law to be
> "particularly petty". PSF's IP lawyer will advise not to allow
> unsanctioned fork of Python 2.7 to call itself Python 2.8.

However, calling it "Passive Python", or "John Smith Python", for
example, would certainly be fine. Calling something "Python 2.8"
may not be unreasonable, also "Python 2.9", but surely "Python 2.10"
will hit strong objections (GvR always announced that there will
never be a two-digit minor release number).

From: Martin v. Loewis on
> Why do I feel like there's less of an onus on Unladen Swallow to
> _actually prove itself in substantial real world usage_ before
> integration into CPython than there is on even the smallest of modules
> for inclusion in the standard library?

Because it's a VM change, not an end-user change. VM changes can be
reviewed and evaluated by core developers, without requiring necessarily
feedback from end users (although end users can and do certainly
evaluate VM changes themselves also and provide feedback).

For library changes, it's more difficult to evaluate them, because
you not only need to find out whether the change is correct, but also
whether it is useful.

> Are we really expected to just ditch everything we know about
> CPython's performance characteristics just for some questionable and
> possibly uneven gains?

That's the point of writing a PEP. Provide feedback to the PEP authors,
and ask them to incorporate your objections into the PEP in case they
forget. Then, when the PEP is about to be approved, that feedback
gets taken into consideration.

Posting in the 665th message on a Usenet thread is unlikely to have any
effect on the PEP process, though.

> I've been a big supporter of Py3 from the beginning, but this repeated
> claim of US becoming the mainline interpreter for 3.x pretty much
> kills dead a lot of my interest.

It's not a claim, it's a PEP. Not being interested in the PEP process
is your choice, of course, but you shouldn't complain afterwards that
your opinion wasn't considered if you didn't actually voice it

From: Ben Finney on
"Martin v. Loewis" <martin(a)> writes:

> Not being interested in the PEP process is your choice, of course, but
> you shouldn't complain afterwards that your opinion wasn't considered
> if you didn't actually voice it appropriately.


\ “I installed a skylight in my apartment. The people who live |
`\ above me are furious!” —Steven Wright |
_o__) |
Ben Finney
From: Anssi Saari on
Stefan Behnel <stefan_ml(a)> writes:

> 'Stable Debian' has a long tradition of being late and outdated on arrival.
> That doesn't mean you can't use existing Debian packages on it.

Yes, but that's beside the point. No released version of Debian ships
with Python3 or even 2.6.

Oh, and RHEL5 and CentOS5 ship with 2.4.

First  |  Prev  |  Next  |  Last
Pages: 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Ad hoc lists vs ad hoc tuples
Next: Python and Ruby