New PythonLabs site revealed!
Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place. The new beta will be released via this site. And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README): """ While Pythoneers have grown fond of Python's exceedingly slow version incrementing, that same quality makes parts of the rest of the world think Python is barely out of its first alpha test. Especially enterprise customers are often fearful of anything that's version 1.x! The new version number also clearly marks Python's departure from CNRI. Previously, the version number 2.0 was associated with a mythical and elusive incompatible future release. That release (still ways off, and not as incompatible as people fear!) is now referred to as Python 3000. """ --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Today, without much fanfare, we opened the new PythonLabs website. The design is by BeOpen's creative Director, Jun Simmons. Thanks to Jeremy Hylton, who did most of the actual HTML editing to get our contents in place.
The new beta will be released via this site.
And since you python-dev folks will find this out through my checkins anyway, let this be an advance warning that it will be called Python 2.0. Here's my explanation for the version bump (soon to be checked in to README):
Guido van Rossum just won't stop surprising us! :-) Witness the three shocking news that arrived in one day: (1) very strict self-discipline about "long-term" TODO's full of short-term and less than medium-term topics that were very logically left behind, (2) major version number revision one day before the official beta-cycle, (3) a new PythonLabs corporate-style Web site with a flashing color palette & tutti quanti. I am really (positively) amazed! :-) spanish-inquisition-is-all-we-deserve-<wink>-ly y'rs -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
Guido van Rossum wrote:
let this be an advance warning that it will be called Python 2.0.
On Fri, 30 Jun 2000, Vladimir Marangozov wrote:
Guido van Rossum just won't stop surprising us! :-)
Will many be spooked by the jump in version number into fearing incompatibility with older scripts...? I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time. Perl 5 was basically incompatible with Perl 4. Some things run, but a lot don't. (Actually many microversions of Perl 5 were mutually incompatible with each other, but i'll ignore that. :) ) I've thought of the jump to Python3k (lowercase "k", please) much like the Perl-4-to-Perl-5 jump: simple stuff is still okay but a lot of guts have changed. If i hadn't been "on the inside" watching development activity, i might expect something of similar magnitude upon hearing of going from Python 1.x to 2.0. I guess we can point at Unicode and SRE as big things. -- ?!ng
Will many be spooked by the jump in version number into fearing incompatibility with older scripts...?
I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time.
I see your concerns, but I think the trick is to be honest, just as Guido was. We simply say it was bumped to V2 for the reasons of percieved maturity, and a clear break from CNRI Python. Both seem reasonable. I believe many people will simply wait for some form of consensus on the newsgroup, regardless of the version number. Personally, Im a little - umm - lets just say that I can see the irony in the fact that I recently changed a few bits of code that were dependent on a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x family. I figured there was no point trying to predict the packaging details of the 2.x family, seeing it as still some time off. Nothing like foresight :-) And-"foresight"-isnt-an-excuse-for-Tim-to-get-back-on-the-topic-of-his-geni tals-<wink>-ly, Mark.
mark wrote:
Personally, Im a little - umm - lets just say that I can see the irony in the fact that I recently changed a few bits of code that were dependent on a hard-coded "Python15.dll" to work not only with 1.6, but _all_ of the 1.x family.
heh. you're not the only one... btw, now that we're bumping to 2.0, maybe we can break socket.connect and friends once again? if somebody com- plains, just tell them "it's a major release, dammit" ;-) </F>
Fredrik Lundh writes:
btw, now that we're bumping to 2.0, maybe we can break socket.connect and friends once again? if somebody com- plains, just tell them "it's a major release, dammit" ;-)
If by "break" you mean "tightly conform to the documentation", I'm all for it! ;) -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
"FL" == Fredrik Lundh <effbot@telia.com> writes:
FL> btw, now that we're bumping to 2.0, maybe we can break FL> socket.connect and friends once again? if somebody com- FL> plains, just tell them "it's a major release, dammit" ;-) That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule. There's always 3.0 though, which will mesh nicely with the mythical Py3k. -Barry
barry wrote:
"FL" == Fredrik Lundh <effbot@telia.com> writes:
FL> btw, now that we're bumping to 2.0, maybe we can break FL> socket.connect and friends once again? if somebody com- FL> plains, just tell them "it's a major release, dammit" ;-)
That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule.
yeah, but I'm sure Guido has the patches somewhere (after all, the 1.6 release notes still mention this change). if not, the mad patcher volunteers to fix (or rather, break) this. Guido? </F>
That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule.
Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release. Some advance notice would have been nice. --david
David Ascher writes:
Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release.
Some advance notice would have been nice.
I agree, but this was news to at least some of us even Wednesday. The upside is that major releases are more likely to happen now that the precedent has been set. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule.
[David Ascher]
Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release.
You have no idea how frustration it is for me! But sometimes the marketing people force us engineers to act quickly. Just be glad I'm not following the release schedule that they had *wanted* me to use... :-)
Some advance notice would have been nice.
Same here. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
That's a good point. A bump in major rev number is an /opportunity/ to break things, like a bone that hasn't healed right, so that they can be fixed correctly. We'll lose that for 2.0, mostly likely because of the tight release schedule.
GvR> [David Ascher]
Yes, I find that frustrating. The story for months (years?) has been that we don't break things because it's a 'dot-release', and so we've shelved improvements left and right. Now we don't have time to do those things even when it _is_ a major release.
GvR> You have no idea how frustration it is for me! But sometimes GvR> the marketing people force us engineers to act quickly. Just GvR> be glad I'm not following the release schedule that they had GvR> *wanted* me to use... :-) Perhaps I am too easy-going, but I consider the 2.0 release a 'dot-release' masquerading as a major revision. It might be a little silly, but it seems even sillier to preserve a naming scheme that makes users think that the technology is immature. Jeremy
Jeremy Hylton [jeremy@beopen.com] wrote:
Perhaps I am too easy-going, but I consider the 2.0 release a 'dot-release' masquerading as a major revision. It might be a little silly, but it seems even sillier to preserve a naming scheme that makes users think that the technology is immature.
I have to say I always thought Guido was a bit conservative... 1.3 -> 1.4 would have been a 3.x release from any "other company", and certainly 1.4 to 1.5 has some major new things (exception changes, etc). I think X.Y means X MAY introduce backward incompatibility, but doesn't have to. It just means major new functionality... I've seen a few of our customers go... "But wait, it's only at 1.5"... yeah, so? Chris -- | Christopher Petrilli | petrilli@amber.org
Ka-Ping Yee writes:
Will many be spooked by the jump in version number into fearing incompatibility with older scripts...?
I wonder if we'll end up trying to persuade the user community that the changes are small ("no, don't worry, your scripts will still work") and yet big ("honest, it really deserves to be called 2.0, it's not just a ploy") at the same time.
Ping, Haven't we heard our users complain about the conservative version numbering a lot? Pushing to 2.0 allows us to make the next release 2.1, which neither the "never 1.x!" crowd nor the "never x.0!" will worry about. Sounds like a good move to me! -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
participants (11)
-
bwarsaw＠beopen.com -
Christopher Petrilli -
David Ascher -
Fred L. Drake, Jr. -
Fredrik Lundh -
Guido van Rossum -
Jeremy Hylton -
Ka-Ping Yee -
Mark Hammond -
Tim Peters -
Vladimir.Marangozov＠inrialpes.fr