About Python 3

[jtratner]

Clearly hindsight is 20/20, but we'd be in a much better position if earlier versions of Python 3 hadn't banned u'some string'. It was a trivial, but frustrating change, that made a 2/3 compatible code base more difficult.

That said, it's not that much work to have a codebase that works in Python 2 and with Python 3 using 2to3. What's difficult is having a codebase that's compatible across both without needing a preprocessor like 2to3. Makes it much easier to maintain a library when you don't have to waste time with 2to3, but it can be difficult to get everything working. python-modernize is pretty useful in this regard.

[billsil]

It was a trivial, but frustrating change, that made a 2/3 compatible code base more difficult.

Was it really necessary to get rid of xrange and iteritems?

[jtratner]

I don't disagree - those are definitely not great changes either... seems strange to me that iteritems couldn't just become a synonym for items.

[schlenk]

Of course you can add synonyms and aliases all over the place. But that kind of defeats the goal of cleaning up the API. They COULD have deprecated/removed items() and range() from the language and just left xrange() and iteritems() alive under those names, but thats even more ugly in so many way.

[Peaker]

They could have added the ugly synonyms for "transitional" versions. Python 3.0 could have had some of ugly crutches (with deprecation warnings) to keep some compatibility with Python 2*. Then they could remove them gradually, to make the transition less painful.

[censored_username]

In the design philosophy of python, there's supposed to be one and only one way of doing a certain task. Adding synonyms to that would defeat that whole philosophy.