Is 3.0 worth breaking backward compatibility?

[walterbyrd]

IMO: breaking backward compatibility is a big deal, and should only be
done when it is seriously needed.

Also, IMO, most of, if not all, of the changes being made in 3.0 are
debatable, at best. I can not think of anything that is being changed
that was really a "show stopper" anyway.

At best, I am a casual python user, so it's likely that I am missing
something.

 

[Andreas Waldenburger]

IMO: breaking backward compatibility is a big deal, and should only be
done when it is seriously needed.

Pleeeeze. Python 3 is shipping now, and so is 2.x, where x > 5. Python
2 is going to be around for quite some time. What is everybody's
problem?

Also, IMO, most of, if not all, of the changes being made in 3.0 are
debatable, at best. I can not think of anything that is being changed
that was really a "show stopper" anyway.

Right. But warts accumulate, and some day you'll have a troglodyte
of a language. Better to scrubb off some warts every now and then, so
the whole thing remains agile.

At best, I am a casual python user, so it's likely that I am missing
something.

Yes, the big picture.

Also, being a casual Python user (like myself, just to clarify), *you*
will least be bitten by the incombatibilties.


I *really* don't get all the outrage. It's a major new version. What
better time to tighten things up a bit?


/W

 

[Andreas Waldenburger]

Yes, the big picture.

OK, that was a bit harsh. I apologize.

But my point remains. To reiterate:

* It's not like they rewrote Pascal and called it Python 3.
* There is a script that helps you porting. Jeez.
* Also: Spilt milk.


Sorry, I do get agitated over things like this.
/W

 

[bearophileHUGS]

walterbyrd:

I can not think of anything that is being changed that was really a "show stopper" anyway.<

I agree, but Python and its culture has a characteristic that not many
other languages share: it tries to be a tidy language, to have one
obvious way to do most things, it values readability and sometimes
even elegance.

So even if those problems aren't "showstoppers" for most languages,
for the Python culture they are bad enough to need a fix. The amount
of warts in the language that a Python programmer is used to tolerate
in the the language is probably 1/20 of the warts a C++ programmer
digests with no problem every day.

Different languages, different cultures, and sometimes even different
psychology & cognitive profile of the programmer.

Bye,
bearophile

 

[nnp]

Have a read of this http://www.b-list.org/weblog/2008/dec/05/python-3000/

It's a response to questions similar to yours by James Bennett

 

[Tim Rowe]

IMO: breaking backward compatibility is a big deal, and should only be
done when it is seriously needed.

Also, IMO, most of, if not all, of the changes being made in 3.0 are
debatable, at best. I can not think of anything that is being changed
that was really a "show stopper" anyway.

But that's what a major release number does for you. Modula2 was quite
a break from Modula. Think of Python3.0 it as a new language, if you
like, that's inspired by Python2. You can stay with Python2 or you can
adopt the new language. That way you won't have to think of it in
terms of breaking any sort of backwards compatibility because there is
no backwards ;-)

 

[Steven D'Aprano]

IMO: breaking backward compatibility is a big deal, and should only be
done when it is seriously needed.

Also, IMO, most of, if not all, of the changes being made in 3.0 are
debatable, at best. I can not think of anything that is being changed
that was really a "show stopper" anyway.

At best, I am a casual python user, so it's likely that I am missing
something.

To answer your subject line: "Is 3.0 worth breaking backward
compatibility?"

That depends on what you are doing with Python.

Python 3 is the future of Python. "Show stopper" or not, all the new
(mis)features in Python 3 are here to stay, and all the (mis)features in
Python 2 are on the way out. You can start moving to Python 3 now, or you
can do it later, but *eventually* you will have to move.

 

[Lie Ryan]

But that's what a major release number does for you. Modula2 was quite a
break from Modula. Think of Python3.0 it as a new language, if you like,
that's inspired by Python2. You can stay with Python2 or you can adopt
the new language. That way you won't have to think of it in terms of
breaking any sort of backwards compatibility because there is no
backwards ;-)

Actually I noticed a tendency from open-source projects to have slow
increment of version number, while proprietary projects usually have big
version numbers.

Linux 2.x: 1991 Python 3.x.x: 1991. Apache 2.0: 1995. OpenOffice.org 3.0:
acquired by Sun at 1999. GIMP 2.x: 1995. Wine 1.x: 1993.

Compare with
Windows: NT 3.1-NT 6.x: 1993. Visual Studio 97, 6.0, .NET, .NET
2003, .NET 2005, 2008: 1997. Photoshop (11 versions to CS4): 1987.
Microsoft Office 3, 4, 95, 97, 2000, XP, 2003, 2007: 1990. Flash MX, 9,
CS 1-4. iTunes 8: 2001. RealPlayer 4-11: 1995. Macintosh 1.0-9:
1984-2001, X.5: 2001. Winzip 12.0: early 1990s.

Interestingly, many linux _distro_ also inhibit this quick version number
change. Fedora 10, Ubuntu is 2 years old, version 8 (they start from
version 6 not 1).

Probably having higher version numbers sells better and looks more
attractive (since it'd make it seem like the software is not a new
product), having quick changing version number also makes users doesn't
mind compatibility breaks. Also a pattern is that prop software often
change how they version their product, (extreme example: visual studio:
from using years, version number, .NET, .NET + Year, back to year).
Changing how you version your product would make it "looks" like it's a
fresh new product (boring ol' photoshop 9 looks fresh with the new CS-
tag).

By having quick changing version number and often changing how product is
versioned, vendors could also say: "its two/three major version away, we
don't support that feature anymore since a veeery long time".

 

[Albert Hopkins]

Actually I noticed a tendency from open-source projects to have slow
increment of version number, while proprietary projects usually have
big
version numbers.

Linux 2.x: 1991 Python 3.x.x: 1991. Apache 2.0: 1995. OpenOffice.org
3.0:
acquired by Sun at 1999. GIMP 2.x: 1995. Wine 1.x: 1993.

One exeption would be GNU Emacs 22: 1984, but according to Wikipedia:

"Versions 2 to 12 never existed. Earlier versions of GNU Emacs
had been numbered "1.x.x", but sometime after version 1.12 the
decision was made to drop the "1", as it was thought the major
number would never change."

So you can think of Emacs 22 as being 1.22.

 

[Lie Ryan]

One exeption would be GNU Emacs 22: 1984, but according to Wikipedia:

"Versions 2 to 12 never existed. Earlier versions of GNU Emacs
had been numbered "1.x.x", but sometime after version 1.12 the
decision was made to drop the "1", as it was thought the major
number would never change."

So you can think of Emacs 22 as being 1.22.

most odd is TeX an METAFONT:

TeX has an idiosyncratic version numbering system. Since version 3,
updates have been indicated by adding an extra digit at the end, so that
the version number asymptotically approaches π. The current version is
3.1415926. This is a reflection of the fact that TeX is now very stable,
and only minor updates are anticipated. TeX developer Donald Knuth has
stated that the "absolutely final change (to be made after my death)"
will be to change the version number to π, at which point all remaining
bugs will become permanent features.

In a similar way, the version number of METAFONT asymptotically
approaches e.

 

[Marc 'BlackJack' Rintsch]

Interestingly, many linux _distro_ also inhibit this quick version
number change. Fedora 10, Ubuntu is 2 years old, version 8 (they start
from version 6 not 1).

Ubuntu's version numbers don't follow the usual rules but are year and
month of release. So this year's releases have "version" 8 and the
latest is from october so it is 8.10.

Ciao,
Marc 'BlackJack' Rintsch

 

[Lie Ryan]

Wine actually timed the 1.0 release to be at about t the 15th "birthday"
of the project.

15 years is a very long time to get to version 1.0, many other (usually
commercial or commercial-oriented front of a software) software release
version 1.0 after 2-3 years of development, often shorter. wine has been
used by a lot of people, not only a few internal developers and beta
testers.

Just to note: Office 2007 is also known as Office 12, if you want to
look at version numbers. Also, Mac OS hasn't increased the major version
number past 10 since they switched from their own proprietary kernel to
using the open-source Darwin.



That's because 8 isn't the verison number- it's the year the version was
released (8.10 is October 2008, not the 10th update to version 8).

I know about that, but in my definition (and Wikipedia's), it is still
the version number (maybe I forget to put a footnote). My point is that
commercial software and commercial front of a free software (linux
distros, Cedega 6.1) prefers having big version numbers.

<snip>

 

[News123]

Troll?

bye

N

 

[walterbyrd]

Pleeeeze. Python 3 is shipping now, and so is 2.x, where x > 5. Python
2 is going to be around for quite some time. What is everybody's
problem?

A possible, potential, problem, could arise if you were using python
2.x, but some other code, that you wanted to include, was writen in
python 3.x.

It always surprises me that so many python developers never consider
the possibility that you may not always be working with your own code.

 

[Chris Mellon]

A possible, potential, problem, could arise if you were using python
2.x, but some other code, that you wanted to include, was writen in
python 3.x.

A possible, potential, problem, could arise if you were using [Java],
but some other code,
that you wanted to include, was writen in [Pascal].

Surely the software industry is doomed?

 

[Andreas Waldenburger]

A possible, potential, problem, could arise if you were using python
2.x, but some other code, that you wanted to include, was writen in
python 3.x.

Yes, that would be a problem, of course. But I fail to see how that is
not a problem with python 2.x as well. New Style Classes? Generators?
The "with" statement? I use those all the time. Why aren't as many
people complaining about them with the same argument?

/W