Comments on: Python 3.0 to be backwards incompatible http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/ Sat, 22 Nov 2008 18:45:57 +0000 http://wordpress.org/?v=2.2.2 By: Steve Bergman http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5581 Steve Bergman Sat, 02 Feb 2008 15:45:40 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5581 Yeeks, third post. Need caffeine. But one of my previous sentences doesn't even make sense and that embarrasses me more than making three posts in a row and having to deal with yet another CAPTCHA. ;-) Should be: I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility *speaks for the quality of the engineering which has gone into python thus far*. I'm leaving for a client site now so this should be my last installment. Yeeks, third post. Need caffeine. But one of my previous sentences doesn’t even make sense and that embarrasses me more than making three posts in a row and having to deal with yet another CAPTCHA. ;-)

Should be: I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility *speaks for the quality of the engineering which has gone into python thus far*.

I’m leaving for a client site now so this should be my last installment.

]]> By: Steve Bergman http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5580 Steve Bergman Sat, 02 Feb 2008 15:40:21 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5580 Yeah, I know I've already replied. But I had not read Eugenia's comment at the time. I guess I would have to ask you to define "RIGHT". Is "RIGHT" agreed upon by everyone? And is it forever? To the extent that there are some decisions that Guido made back in 1990 that he and the current dev team would have made differently today, in 2008, I guess you could say that it was "bad engineering". But I think that's a pretty loaded phrase. You could actually make a better argument that the Python dev's philosophy on compatibility has negative repercussions regarding use of the language in certain common settings. And I would not argue with that view because it's true. I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility. I know that blogs are for rants and I respect that. But calling Python 2.x "bad engineering" seems a bit over the top to me. Yeah, I know I’ve already replied. But I had not read Eugenia’s comment at the time. I guess I would have to ask you to define “RIGHT”. Is “RIGHT” agreed upon by everyone? And is it forever?

To the extent that there are some decisions that Guido made back in 1990 that he and the current dev team would have made differently today, in 2008, I guess you could say that it was “bad engineering”. But I think that’s a pretty loaded phrase.

You could actually make a better argument that the Python dev’s philosophy on compatibility has negative repercussions regarding use of the language in certain common settings. And I would not argue with that view because it’s true.

I believe that the extent to which Python is used *despite* the small version to version incompatibilities, and this long-known and upcoming bigger break in compatibility.

I know that blogs are for rants and I respect that. But calling Python 2.x “bad engineering” seems a bit over the top to me.

]]> By: Steve Bergman http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5579 Steve Bergman Sat, 02 Feb 2008 14:14:29 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5579 This is very much a matter of programmer/admin taste. Python has always made certain changes between releases which can break some programs. It's a bit of a pain. But it does allow the language itself to improve more than it would if they were completely tied to backwards compatibility. Python 3.0 will be the first really major change to the language in its long 17 year history. It is intended to fix those design irritations which developers have just had to live with until now. I think that most Python programmers are OK with the 3.0 changes. Of course, you could make a good case for us being a self-selected group who don't mind a little backwards incompatibility in return for what we get back. Then again so are C++ programmers, who live in a hell of their own creation and seem to enjoy it. andTheSameCanBeSaidOfJavaProgrammers(). -Steve This is very much a matter of programmer/admin taste. Python has always made certain changes between releases which can break some programs. It’s a bit of a pain. But it does allow the language itself to improve more than it would if they were completely tied to backwards compatibility. Python 3.0 will be the first really major change to the language in its long 17 year history. It is intended to fix those design irritations which developers have just had to live with until now.

I think that most Python programmers are OK with the 3.0 changes. Of course, you could make a good case for us being a self-selected group who don’t mind a little backwards incompatibility in return for what we get back. Then again so are C++ programmers, who live in a hell of their own creation and seem to enjoy it. andTheSameCanBeSaidOfJavaProgrammers().

-Steve

]]> By: Tom Dison http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5565 Tom Dison Fri, 01 Feb 2008 21:54:42 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5565 Actually, things do change in the C/C++ world. Things get marked as deprecated, and then developers need to change their code before these deprecated methods go away. The same is true in the Java world. The same just happened in the move from Php 4 to 5 to 6. Register globals were marked as deprecated for a long time before going away in PHP 6. A lot of developers just continue to use deprecated functionality. That's why the implementation of Python 2.6 will clearly mark deprecated methods, facilitating the change to 3.0. This reminds me of the change from K&R C to Ansi C. A lot of developers dragged their feet on that, but they were necessary standardization changes. Actually, things do change in the C/C++ world. Things get marked as deprecated, and then developers need to change their code before these deprecated methods go away. The same is true in the Java world. The same just happened in the move from Php 4 to 5 to 6. Register globals were marked as deprecated for a long time before going away in PHP 6. A lot of developers just continue to use deprecated functionality. That’s why the implementation of Python 2.6 will clearly mark deprecated methods, facilitating the change to 3.0. This reminds me of the change from K&R C to Ansi C. A lot of developers dragged their feet on that, but they were necessary standardization changes.

]]> By: Timothy http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5563 Timothy Fri, 01 Feb 2008 21:51:46 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5563 There's a bit of a difference between C/C++ and Python. C/C++ is rather low level. They don't do to much, they have pointers, classes, etc. Python however, with iterators, maps, and all the other tons of stuff it includes, it's harder to get it right "the first time". I'm glad they are doing it right, and not trying to keep the cruft in. As Tom said, we have enough of that sort of junk from Intel. There’s a bit of a difference between C/C++ and Python. C/C++ is rather low level. They don’t do to much, they have pointers, classes, etc. Python however, with iterators, maps, and all the other tons of stuff it includes, it’s harder to get it right “the first time”.

I’m glad they are doing it right, and not trying to keep the cruft in. As Tom said, we have enough of that sort of junk from Intel.

]]> By: Eugenia http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5560 Eugenia Fri, 01 Feb 2008 19:54:31 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5560 C and C++ haven't broken compatibility for a long time. There are standards. You get it RIGHT the first time, or the second one. That's what engineering means. After so many years, Python's spec should have been stable by now. There is no excuse other than bad engineering. C and C++ haven’t broken compatibility for a long time. There are standards. You get it RIGHT the first time, or the second one. That’s what engineering means. After so many years, Python’s spec should have been stable by now. There is no excuse other than bad engineering.

]]> By: Alex http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5559 Alex Fri, 01 Feb 2008 19:41:19 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5559 How else is the language supposed to move forward if it can't break some compatibility between major versions? It isn't a minor release! You can always install both on the same machine if certain applications only work with an older version of Python. How else is the language supposed to move forward if it can’t break some compatibility between major versions? It isn’t a minor release!

You can always install both on the same machine if certain applications only work with an older version of Python.

]]> By: Tom Dison http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5557 Tom Dison Fri, 01 Feb 2008 19:06:00 +0000 http://eugenia.gnomefiles.org/2008/02/01/python-30-to-be-backwards-incompatible/#comment-5557 I think every once in a while you have to bite the bullet and break compatability. There were essentially several design flaws in Python that were allowed to continue for years. For Python 3.0 they decided to fix them. The same is true for the (as yet phantom) Perl 6 version. It will break a few things for the sake of sanity. It reminds me of how Microsoft (and even Intel) have managed to drag along the baggage of the original 8-bit IBM PC for the sake of backwards compatability. I predict at some point they will have to let it go. I don't think it will suck too much for users. Most software will continue to use I think every once in a while you have to bite the bullet and break compatability. There were essentially several design flaws in Python that were allowed to continue for years. For Python 3.0 they decided to fix them. The same is true for the (as yet phantom) Perl 6 version. It will break a few things for the sake of sanity. It reminds me of how Microsoft (and even Intel) have managed to drag along the baggage of the original 8-bit IBM PC for the sake of backwards compatability. I predict at some point they will have to let it go.

I don’t think it will suck too much for users. Most software will continue to use

]]>