[Python-Dev] Backporting PEP 414 (original) (raw)
Chris McDonough chrism at plope.com
Tue Feb 28 23:17:24 CET 2012
- Previous message: [Python-Dev] Backporting PEP 414
- Next message: [Python-Dev] Backporting PEP 414
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, 2012-02-28 at 16:48 -0500, Barry Warsaw wrote:
On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
>> If there is already a FAQ entry feel free to point me to it, but I would >> still be curious why, in this instance, practicality does not beat purity? > >Because it's practical not to break bugfix releases with new features. And because now your code is incompatible with three micro-release versions (3.2.0, 3.2.1, and 3.2.2), two of which are bug fix releases. Which means for example, you can't be sure which version of which distro your code will work on.
That I do sympathize with.
Doesn't anybody else remember the True/False debacle in 2.2.1?
I do. It was slightly different than this because the feature was added twice, once in 2.2.1 with direct aliases to 0 and 1, which was found to be lacking, and then later again in 2.3 with explicit types, so it was sort of an extended-timeframe unpleasantness, and the feature's minor-dot-introduction was only a contributing factor, IIRC.
But yeah. A year from now I wouldn't remember which version of 3.2 got a new feature, and neither would anybody else. The no-new-features guidelines are useful in the real world this way, because they represent a coherent policy, as tempting as it is to just jam it in.
- C
- Previous message: [Python-Dev] Backporting PEP 414
- Next message: [Python-Dev] Backporting PEP 414
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]