On the other hand, these backports make it easier for library authors to write single-codebase code, which is so much better than using 2to3 (it lets you actually *use* Python 3 in your development). 

Aaron Meurer

On Sat, Apr 5, 2014 at 12:19 PM, Andrew Donoho <[address removed]> wrote:

On Apauthor 5, 2014, at 09:19 , Mike <[address removed]> wrote:

Python3.3 is nice until you have to deal with bytes and unicode... sadly unicode is all over the web and the real world.

http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/

Mike,

I obviously do not know what you come across in your practice. But in my practice, I needed to go down into the guts of my Twitter library and fix its streaming behavior. I was working directly in the middle of the bytes versus str divide in the http protocol. It was incredibly easy to maintain the distinction between bytes and strings. The code was efficient, unchanged and Pythonic on both v2.7 and v3.

The author of the article you linked, the highly respected Armin Ronacher, clearly thinks unicode conversion issues are handled poorly by Python3. Not being an expert in unicode, I find that Python3 provides me what I need for processing hundreds of millions of international unicode encoded strings. I am a beneficiary of the Python3 architecture to keep unicode as simple as possible for all users. From my perspective, it looks like they made the common case easy and uncommon case possible. Looking at the recent history, it appears the core team has also updated the design in response to criticisms. The support for unicode literal prefixes (u"") in Python v3.3 is an example of the core team evolving with real use cases.

Most of the "sturm und drang" about this transition appears to come from web developers like Mr. Ronacher, the author of Flask. I hope we can hear more about your experiences, and not Mr. Ronacher's, when Aaron gives his talk. Mr. Ronacher solves some very different problems than I, and I suspect you, face. His criticisms may not apply to our use of the language. (There is also very clearly some bad blood between the author and the core committers. Judging by the tone of the piece, this is unlikely to be resolved. That is unfortunate. It reads like Mr. Ronacher has some useful criticisms of the Python3 design. Lets remember that the Python 3 core team is also the Python 2 and Python 1 core team. I'm going to spot them a bit more language design and architectural insight than I do Mr. Ronacher. The failure to get his architectural vision implemented is his failure, not the core team's. I don't know the core team. I have shared two meals with Nick Coughlan, a core team member. I found him to be quite reasonable. I suspect other members of the core team are reasonable too.)

Most of us do not actually face the issues that Mr. Ronacher does. His analysis is correct for him. Most of what he complained about in his article, I do not see on a day to day basis. I doubt many of us see these issues.

The above said, the Python2 habit of using strings as arrays of bytes is an engineering problem brought on by the evolution of the language. It has the same issues that C faced with NULL terminated strings. Python3 largely addresses those long term issues. That folks would complain about this is understandable. People complain about change. (Hell, there are probably people still complaining about the shift from Python 2.4 to 2.5 today.) Python3 will continue to evolve and improve. And people will complain. I'll probably complain. It happens with change.

Mr. Ronacher concludes with a slam on an only 3% uptake for Python3 after 5 years. As a result, he regards Python3 a failure. I have a different view.

The transition to Python3 represents the best evolution process in any software system I have ever seen. The core team has bent over backwards to bring many useful features from Python3 back into Python 2.7. That is a phenomenal amount of good practical work that makes the Python community more vital and capable. The features that they have backported, such as set comprehensions, are deeply useful. This is incredibly mature of the core team. They undermine, for the benefit of the community, the case for transitioning to Python3. 

Because of this significant backporting effort, almost every improvement to Python v2.7 over Python v2.6 derives from the Python3 effort. If you are using a Python v2.7 and later feature, you are using Python3. All of the uptake numbers for Python v2.7, in a very important sense, are also uptake numbers for Python3.

But the core team can sometimes be too accommodating. For example, I think it is a big mistake to backport the async.io stuff back to Python v2.7. It is a fundamentally new capability of the environment. If you are going to embrace async.io, then you should move up to Python3. Adding a runloop to the execution model changes everything. And it should not be constrained with downlevel requirements.

Hence, I disagree with Mr. Ronacher's assessment of the transition to Python3. He lets his emotions lead him into a faulty analysis of the true scope of migration to Python3. It has largely already happened as an informal transition to v2.7. I predict the formal transition to Python3 will accelerate when Python v2.6 is no longer the default Python on the major OS distributions.

On Apr 5, 2014, at 09:32 , Robin Levins <[address removed]> wrote:

It's worth noting that set comprehensions and dictionary comprehensions are in Python 2.7 (I use dictionary comprehensions frequently). Also, range() as a generator is available in Python 2.7 as xrange(). (I can't speak as to the others.)

Robin,

As I say above, any feature you are using in Python 2.7 that was introduced in Python3 and then backported is an example of you using Python3. The core team has just made it easier for you to migrate forward on your time schedule. I cheer them on and thank them for their mature and supportive engineering process. Even if you are not deploying on Python3 today, you should certainly run your code in that environment. It will help you improve your v2.7 code.

Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
[address removed], +1 (512)[masked], twitter.com/adonoho

Download Retweever here: <http://Retweever.com>

No risk, no art.
No art, no reward.
-- Seth Godin

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Andrew Donoho ([address removed]) from The Austin Python Meetup.
To learn more about Andrew Donoho, visit his/her member profile

To report this message or block the sender, please click here
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Aaron Meurer ([address removed]) from The Austin Python Meetup.
To learn more about Aaron Meurer, visit his/her member profile

To report this message or block the sender, please click here
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]