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

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! :-)

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.

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

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" ;-)

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.

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.

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.

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.

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.

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... :-)

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.

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.

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

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!