[posted to c.l.py with cc to python-dev]
[I apologize for the delay in posting this, but it's taken me some time
to get my thoughts straight. I hope that by posting this right before
IPC9 there'll be a chance to get some good discussion in person.]
In article <mailman.982897324.9109.python-list@python.org>,
Guido van Rossum <guido@digicool.com> wrote:
>
>We have clearly underestimated how much code the nested scopes would
>break, but more importantly we have underestimated how much value our
>community places on stability.
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.
As I see it, there's a natural tension between between adding features
and delivering bug fixes. Particularly because of Microsoft, I think
that upgrading to a feature release to get bug fixes has become anathema
to a lot of people, and I think that seeing features added or changed
close to a release reminds people too much of the Microsoft upgrade
treadmill.
>So here's the deal: we'll make nested scopes an optional feature in
>2.1, default off, selectable on a per-module basis using a mechanism
>that's slightly hackish but is guaranteed to be safe. (See below.)
>
>At the same time, we'll augment the compiler to detect all situations
>that will break when nested scopes are introduced in the future, and
>issue warnings for those situations. The idea here is that warnings
>don't break code, but encourage folks to fix their code so we can
>introduce nested scopes in 2.2. Given our current pace of releases
>that should be about 6 months warning.
As some other people have pointed out, six months is actually a rather
short cycle when it comes to delivering enterprise applications across
hundreds or thousands of machines. Notice how many people have said
they haven't upgraded from 1.5.2 yet! Contrast that with the quickness
of the 1.5.1 to 1.5.2 upgrade.
I believe that "from __future__" is a good idea, but it is at best a
bandage over the feature/bug fix tension. I think that the real issue
is that in the world of core Python development, release N is always a
future release, never the current release; as soon as release N goes out
the door into production, it immediately becomes release N-1 and forever
dead to development
Rather than change that mindset directly, I propose that we move to a
forked model of development. During the development cycle for any given
release, release (N-1).1 is also a live target -- but strictly for bug
fixes. I suggest that shortly after the release for Na1, there should
also be a release for (N-1).1b1; shortly after the release of Nb1, there
would be (N-1).1b2. And (N-1).1 would be released shortly after N.
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.
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.
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.
If there's interest in this idea, I'll write it up as a formal PEP.
It's too late for my proposed model to work during the 2.1 release
cycle, but I think it would be an awfully nice gesture to the community
to take a month off after 2.1 to create 2.0.1, before going on to 2.2.
BTW, you should probably blame Fredrik for this idea. ;-) If he had
skipped providing 1.5.2 and 2.0 versions of sre, I probably wouldn't
have considered this a workable idea. I was just thinking that it was
too bad there wasn't a packaged version of 2.0 containing the new sre,
and that snowballed into this.
--
--- 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