In article <mailman.983646726.27322.python-list@python.org>, Guido van Rossum <guido@digicool.com> wrote:
Aahz writes:
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.
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.
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.
So that relegates us at PythonLabs to a number of things: coding new modules (boring), or trying to improve performance of the virtual machine (equally boring, and difficult to boot), or fixing bugs (did I mention boring? :-).
So what can we do for fun? (Besides redesigning Zope, which is lots of fun, but runs into the same issues.)
Write new versions of Python. You've come up with a specific protocol in a later post that I think I approve of; I was trying to suggest a balance between lots of grunt work maintenance and what I see as perpetual language instability in the absence of any bug fix releases.
Your math at first confused the hell out of me, but I see what you mean. You want us to spend time on 2.0.1 which should be a bugfix release for 2.0, while at the same time working on 2.1 which is a new feature release.
Yup. The idea is that because it's always an N and N-1 pair, the base code is the same for both and applying patches to both should be (relatively speaking) a small amount of extra work. Most of the work lies in deciding *which* patches should go into N-1.
Guess what -- I am secretly (together with the PSU) planning a 2.0.1 release. I'm waiting however for obtaining the ownership rights to the 2.0 release, so we can fix the GPL incompatibility issue in the license at the same time. (See the 1.6.1 release.) I promise that 2.0.1, unlike 1.6.1, will contain more than a token set of real bugfixes. Hey, we already have a branch in the CVS tree for 2.0.1 development! (Tagged "release20-maint".)
Yay! (Sorry, I'm not much of a CVS person; the one time I tried using it, I couldn't even figure out where to download the software. Call me stupid.)
We could use some checkins on that branch though.
Fair enough.
This means that each feature-based release gets one-and-only-one pure bugfix release. I think this will do much to promote the idea of Python as a stable platform for application development.
Anything we can do to please those republicans! :-)
<grin>
There are a number of ways I can see this working, including setting up a separate project at SourceForge (e.g. pythonpatch.sourceforge.net). But I don't think this will work at all unless the PythonLabs team is at least willing to "bless" the bugfix release. Uncle Timmy has been known to make snarky comments about forever maintaining 1.5.2; I think this is a usable compromise that will take relatively little effort to keep going once it's set up.
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. My one central point is that I think this will fail if PythonLabs doesn't agree to formally certify each release.
I think one key advantage of this approach is that a lot more people will be willing to try out a beta of a strict bugfix release, so the release N bugfixes will get more testing than they otherwise would.
Wait a minute! Now you're making it too complicated. Betas of bugfix releases? That seems to defeat the purpose. What kind of beta-testing does a pure bugfix release need? Presumably each individual bugfix applied has already been tested before it is checked in!
"The difference between theory and practice is that in theory, there is no difference, but in practice, there is." 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. The main reason I suggested two betas was to "lockstep" the bugfix release to the next version's feature release.
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. ;-)
If there's interest in this idea, I'll write it up as a formal PEP.
Please do.
Okay, I'll do it after the conference. I've e-mailed Barry to ask for a PEP number. -- --- Aahz (Copyright 2001 by aahz@pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 Nostalgia just ain't what it used to be -- --- Aahz (Copyright 2001 by aahz@pobox.com) Androgynous poly kinky vanilla queer het <*> http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 Nostalgia just ain't what it used to be
[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/)
[Aahz]
... 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. ;-)
[Guido]
But the Windows change is clearly a feature,
Yes.
so that can't be added to 2.0.1.
That's what Aahz is debating.
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?
You're a Giant Corporation that ships a multi-platform product, including Python 2.0. Since your IT dept is frightened of its own shadow, they won't move to 2.1. Since there is no bound to your greed, you figure that even if there are only a dozen MacOS X users in the world, you could make 10 bucks off of them if only you can talk PythonLabs into treating the lack of 2.0 MacOS X support as "a bug", getting PythonLabs to backstitch the port into a 2.0 follow-on (*calling* it 2.0.x serves to pacify your IT paranoids). No cost to you, and 10 extra dollars in your pocket. Everyone wins <wink>. There *are* some companies so unreasonable in their approach. Replace "a dozen" and "10 bucks" by much higher numbers, and the number of companies mushrooms accordingly. If we put out a release that actually did nothing except fix legitimate bugs, PythonLabs may have enough fingers to count the number of downloads. For example, keen as *I* was to see a bugfix release for the infamous 1.5.2 "invalid tstate" bug, I didn't expect anyone would pick it up except for Mark Hammond and the other guy who bumped into it (it was very important to them). Other people simply won't pick it up unless and until they bump into the bug it fixes, and due to the same "if it's not obviously broken, *any* change is dangerous" fear that motivates everyone clinging to old releases by choice. Curiously, I eventually got my Win95 box into a state where it routinely ran for a solid week without crashing (the MTBF at the end was about 100x higher than when I got the machine). I didn't do that by avoiding MS updates, but by installing *every* update they offered ASAP, even for subsystems I had no intention of ever using. That's the contrarian approach to keeping your system maximally stable, relying on the observation that the code that works best is extremely likely to be the code that the developers use themselves. If someone thinks there's a market for Python bugfix releases that's worth more than it costs, great -- they can get filthy rich off my appalling lack of vision <wink>. "worth-more-than-it-costs"-is-key-ly y'rs - tim
[Tim justifies one-release-back mentality]
You're a Giant Corporation that ships a multi-platform product, including Python 2.0. Since your IT dept is frightened of its own shadow, they won't move to 2.1. Since there is no bound to your greed, you figure that even if there are only a dozen MacOS X users in the world, you could make 10 bucks off of them if only you can talk PythonLabs into treating the lack of 2.0 MacOS X support as "a bug", getting PythonLabs to backstitch the port into a 2.0 follow-on (*calling* it 2.0.x serves to pacify your IT paranoids). No cost to you, and 10 extra dollars in your pocket. Everyone wins <wink>.
There is a curious psychology involved. I've noticed that a significant number of people (roughly 30%) always download an older release. Example: Last week I announced a new release (j) of Installer. 70% of the downloads were for that release. There is only one previous Python 2 version of Installer available, but of people downloading a Python 2 version, 17% chose the older (I always send people to the html page, and none of the referrers shows a direct link - so this was a concious decision). Of people downloading a 1.5.2 release (15% of total), 69% chose the latest, and 31% chose an older. This is the stable pattern (the fact that 83% of Python 2 users chose the latest is skewed by the fact that this was the first week it was available). Since I yank a release if it turns out to introduce bugs, these people are not downloading older because they've heard it "works better". The interface has hardly changed in the entire span of available releases, so these are not people avoiding learning something new. These are people who are simply highly resistent to anything new, with no inclination to test their assumptions against reality. As Guido said, Republicans :-). - Gordon
Gordon> There is a curious psychology involved. I've noticed that a Gordon> significant number of people (roughly 30%) always download an Gordon> older release. Gordon> Example: Last week I announced a new release (j) of Installer. Gordon> 70% of the downloads were for that release. ... Gordon> Of people downloading a 1.5.2 release (15% of total), 69% Gordon> chose the latest, and 31% chose an older. This is the stable Gordon> pattern (the fact that 83% of Python 2 users chose the latest Gordon> is skewed by the fact that this was the first week it was Gordon> available). Check your web server's referral logs. I suspect a non-trivial fraction of those 30% were coming via offsite links such as search engine referrals and weren't even aware a new installer was available. Skip
Gordon> Of people downloading a 1.5.2 release (15% of total), 69% Gordon> chose the latest, and 31% chose an older. This is the stable Gordon> pattern (the fact that 83% of Python 2 users chose the latest Gordon> is skewed by the fact that this was the first week it was Gordon> available).
[Skip]
Check your web server's referral logs. I suspect a non-trivial fraction of those 30% were coming via offsite links such as search engine referrals and weren't even aware a new installer was available.
That's the whole point - these stats are from the referrals. My download directory is not indexed or browsable. I only announce the page with the download links on it. And sure enough, all downloads come from there. - Gordon
aahz> Yup. The idea is that because it's always an N and N-1 pair, the aahz> base code is the same for both and applying patches to both should aahz> be (relatively speaking) a small amount of extra work. Most of aahz> the work lies in deciding *which* patches should go into N-1. The only significant problem I see is making sure submitted patches contain just bug fixes or new features and not a mixture of the two. aahz> The main reason I suggested two betas was to "lockstep" the bugfix aahz> release to the next version's feature release. I don't see any real reason to sync them. There's no particular reason I can think of why you couldn't have 2.1.1, 2.1.2 and 2.1.3 releases before 2.2.0 is released and not have any bugfix release coincident with 2.2.0. Presumably, any bug fixes between the release of 2.1.3 and 2.2.0 would also appear in the feature branch. As long as there was someone willing to manage a particular bug fix branch, such a branch could continue for a relatively long ways, long past the next feature release. Skip
participants (5)
-
aahz@panix.com
-
Gordon McMillan
-
Guido van Rossum
-
Skip Montanaro
-
Tim Peters