3 ms·

"second-system syndrome" sounds like exactly the opposite of what I think about py3k. (Pythonista with more than 10kloc, rubyist at my day job, many less). Mai

"second-system syndrome" sounds like exactly the opposite of what I think about py3k. (Pythonista with more than 10kloc, rubyist at my day job, many less). Mainly, I see this release as cleaning up the warts that python had accumulated. {imap, ifilter, izip, iterkeys, itervalues, iteritems, xrange} all becoming default and their non-stream counterparts ceasing to exist is a huge upgrade. Unifying new-style and old-style classes is a huge cleanup and upgrade. (Which simplifies code for newbies quite a bit, too). The move to default unicode strings is a huge upgrade. The library cleanup is a huge upgrade. The inclusion of multiprocessing (actually 2.6, but who uses that?) is a huge upgrade. I don't see any of this as "breaking random bits of code", but rather as stepping back to regroup the language into a much more coherent whole. But then, I'm in the tank for python, I freely admit.

tptacek 18y ago
I knew when I wrote "second-system syndrome" that I was going to get hammered for it, because I agree that it's not a perfect match for what they've done. Many millions of lines of Python code work in the field right now; a decent subset uses Unicode (for instance, most Win32 Python code has to). I buy that the new Unicode model is better, but I don't buy that it's so much better that a code port is worth it. The library cleanup is a major win, but they could have done that in Python 2.7. It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x.
- llimllib 18y ago
  > It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x. Yeah, I was just joking about that bit. I don't see why it would be any different for the 2.7 library have been reorganized than it is for the 3.0 library reorganization; it would have broken just as much code. And while you're breaking code, you should break the code that needs to be broken, right? And it's not just unicode, it's unicode/new style classes/iterators throughout (which I think is an underrated change). None of these could have happened without breakage, and I think it's better to clear the decks once every 15 years than it is to just grow by accretion forever. Those lines of python in the field that work are not going to stop working; python 2.x is not going to go away or go unmaintained, as you point out yourself. Writing new code will shortly become more difficult in the 2.x series, as libraries start switching to 3, but the old code will be maintainable for a long while. In order for the language to keep growing in a clean, pythonic fashion, it needed to be cleaned up a bit, and I think they did a great job of it.
  - tptacek 18y ago
    So, I agree with you. But one of Jens' subtexts is, if they're going to clear the deck every 15 years, you might hope for something more interesting than "better Unicode support". There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day.
    - llimllib 18y ago
      > There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day. that I can definitely agree with.

tptacek 18y ago

I knew when I wrote "second-system syndrome" that I was going to get hammered for it, because I agree that it's not a perfect match for what they've done. Many millions of lines of Python code work in the field right now; a decent subset uses Unicode (for instance, most Win32 Python code has to). I buy that the new Unicode model is better, but I don't buy that it's so much better that a code port is worth it. The library cleanup is a major win, but they could have done that in Python 2.7. It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x.

llimllib 18y ago
> It's hard to say multiprocessing is a huge win in 3.0, since it's already in 2.x. Yeah, I was just joking about that bit. I don't see why it would be any different for the 2.7 library have been reorganized than it is for the 3.0 library reorganization; it would have broken just as much code. And while you're breaking code, you should break the code that needs to be broken, right? And it's not just unicode, it's unicode/new style classes/iterators throughout (which I think is an underrated change). None of these could have happened without breakage, and I think it's better to clear the decks once every 15 years than it is to just grow by accretion forever. Those lines of python in the field that work are not going to stop working; python 2.x is not going to go away or go unmaintained, as you point out yourself. Writing new code will shortly become more difficult in the 2.x series, as libraries start switching to 3, but the old code will be maintainable for a long while. In order for the language to keep growing in a clean, pythonic fashion, it needed to be cleaned up a bit, and I think they did a great job of it.
- tptacek 18y ago
  So, I agree with you. But one of Jens' subtexts is, if they're going to clear the deck every 15 years, you might hope for something more interesting than "better Unicode support". There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day.
  - llimllib 18y ago
    > There's a lot of stuff that would be nice to have in Python that can't be added without a 3.x-level flag day. that I can definitely agree with.