myths about python 3
in [Python]
|
Prev: Ad hoc lists vs ad hoc tuples
Next: Python and Ruby
From: Martin v. Loewis on 29 Jan 2010 03:16 > 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. Regards, Martin
From: Martin v. Loewis on 29 Jan 2010 03:25 > 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 this. 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 well). > 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). Regards, Martin
From: Martin v. Loewis on 29 Jan 2010 03:33 > 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 appropriately. Regards, Martin
From: Ben Finney on 29 Jan 2010 03:48 "Martin v. Loewis" <martin(a)v.loewis.de> 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. +1 QOTW -- \ “I installed a skylight in my apartment. The people who live | `\ above me are furious!” —Steven Wright | _o__) | Ben Finney
From: Anssi Saari on 29 Jan 2010 08:00
Stefan Behnel <stefan_ml(a)behnel.de> 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. |