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
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