[Aahz] > >> I think so, yes, on that latter clause. I think perhaps it wasn't clear > >> at the time, but I believe that much of the yelling over "print >>" was > >> less over the specific design but because it came so close to the > >> release of 2.0 that there wasn't *time* to sit down and talk things > >> over rationally. [Guido] > >In my eyes the issues are somewhat different: "print >>" couldn't > >possibly break existing code; nested scopes clearly do, and that's why > >we decided to use the __future__ statement. > > > >But I understand that you're saying that the community has grown so > >conservative that it can't stand new features even if they *are* fully > >backwards compatible. [Aahz] > Then you understand incorrectly. There's a reason why I emphasized > "*time*" up above. It takes time to grok a new feature, time to think > about whether and how we should argue in favor or against it, time to > write comprehensible and useful arguments. In hindsight, I think you > probably did make the right design decision on "print >>", no matter how > ugly I think it looks. But I still think you made absolutely the wrong > decision to include it in 2.0. Then I respectfully disagree. We took plenty of time to discuss "print >>" amongst ourselves. I don't see the point of letting the whole community argue about every little new idea before we include it in a release. We want good technical feedback, of course. But if it takes time to get emotionally used to an idea, you can use your own time. > >With the CVS branch it's *trivial* to keep it going. We should have > >learned from the Tcl folks, they've had 8.NpM releases for a while. > > I'm suggesting having one official PythonLabs-created bug fix release as > being a small incremental effort over the work in the feature release. > But if you want it to be an entirely community-driven effort, I can't > argue with that. We will surely put in an effort, but we're limited in what we can do, so I'm inviting the community to pitch in. Even just a wish-list of fixes that are present in 2.1 that should be merged back into 2.0.1 would help! > My one central point is that I think this will fail if PythonLabs > doesn't agree to formally certify each release. Of course we will do that -- I already said so. And not just for 2.0.1 -- for all bugfix releases, as long as they make sense. > I've seen too many cases where a bugfix introduced new bugs somewhere > else. Even if "tested", there might be a border case where an > unexpected result shows up. Finally, there's the issue of system > testing, making sure the entire package of bugfixes works correctly. I hope that the experience with 2.1 will validate most bugfixes that go into 2.0.1. > The main reason I suggested two betas was to "lockstep" the bugfix > release to the next version's feature release. Unclear what you want there. Why tie the two together? How? > >Or are you thinking of adding small new features to a "bugfix" > >release? That ought to be a no-no according to your own philosophy! > > That's correct. One problem, though, is that sometimes it's a little > difficult to agree on whether a particular piece of code is a feature or > a bugfix. For example, the recent work to resolve case-sensitive > imports could be argued either way -- and if we want Python 2.0 to run > on OS X, we'd better decide that it's a bugfix. ;-) But the Windows change is clearly a feature, so that can't be added to 2.0.1. We'll have to discuss this particular one. If 2.0 doesn't work on MacOS X now, why couldn't MacOS X users install 2.1? They can't have working code that breaks, can they? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4