Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

This is my problem to solve... I work with a lot of [non-production] crypto where byte strings are a normal way of manipulating and storing keys and other artifacts. Under Python2 I have few/no Unicode issues. With Python3's default string type being Unicode, there are a lot of subtle ways where my codes go south. Like I say, it is my problem. I will convert to Py3, but not likely before summer. Besides 2to3, any other tools/suggestions would be welcome. (Perhaps there is a Master switch to disable Unicode? ;-) Changing the subject... I say -1 on backporting more 3.x features to 2.6/2.7. As previously mentioned, leave the carrot. And best intentions aside, backports can introduce problems of their own.

On Tue, Nov 3, 2009 at 3:27 PM, Larry Bugbee <bugbee@seanet.com> wrote:
This is my problem to solve... I work with a lot of [non-production] crypto where byte strings are a normal way of manipulating and storing keys and other artifacts. Under Python2 I have few/no Unicode issues. With Python3's default string type being Unicode, there are a lot of subtle ways where my codes go south. Like I say, it is my problem.
It may be interesting for others if you posted some examples of what you are used to doing in 2.x. Maybe somebody will suggest a better way of doing it in 3.x than you have thought of. :-)
I will convert to Py3, but not likely before summer. Besides 2to3, any other tools/suggestions would be welcome. (Perhaps there is a Master switch to disable Unicode? ;-)
Yes, go back to 1.5.2. :-) -- --Guido van Rossum (python.org/~guido)

On Tue, Nov 3, 2009 at 6:27 PM, Larry Bugbee <bugbee@seanet.com> wrote:
This is my problem to solve... I work with a lot of [non-production] crypto where byte strings are a normal way of manipulating and storing keys and other artifacts. Under Python2 I have few/no Unicode issues. With Python3's default string type being Unicode, there are a lot of subtle ways where my codes go south. Like I say, it is my problem.
Interesting- I've been doing crypto in python 3 for quite some time and haven't had any issues except with getting things to play nicely with C. Any specific examples? Geremy Condra

Folks: It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the new unicode regime. I think the answer is that the payoff is just *so* low to me at this point that it doesn't even justify me taking 15 minutes to read "What's New In Python 3" or to execute 2to3 on my smallest package and see what it does. On the other hand, I'm totally committed to supporting Python 2.7, because my customers will demand it and because I expect that it will be easy. So, if you guys slip in your favorite new Python 3 feature into 2.7 and add a deprecation warning for your least favorite Python 2 misfeature, then probably within about 24 months I'll have fixed all code that uses the deprecated feature, and probably within about five years I'll consider dropping backwards-compatibility with Python 2.6 and starting to use that new feature that you added to Python 2.7. (I'm currently considering dropping Python 2.4 compatibility for the next releases of most of my code.) Regards, Zooko

2009/11/4 Zooko O'Whielacronx <zookog@gmail.com>:
On the other hand, I'm totally committed to supporting Python 2.7, because my customers will demand it and because I expect that it will be easy.
Why do you think your customers will demand 2.7 support but not 3.1 support? If I were one of your customers, I'd want 3.1 support... Paul.

On Wed, Nov 04, 2009 at 03:54:44PM -0700, Zooko O'Whielacronx wrote:
It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the new unicode regime. I think the answer is that the payoff is just *so* low to me at this point that it doesn't even justify me taking 15 minutes to read "What's New In Python 3" or to execute 2to3 on my smallest package and see what it does.
<cynical mode> You have time to read this thread but no time to read "What's New In Python 3"? </cynical mode> Personally I found porting to Python 3 a rather pleasant experience (include C extension module). I can't wait until I can drop support for Python 2.2-2.X. Regards Floris PS: I have to admit that the commerial code base I work on is still at Python 2.5, but that doesn't make me worry in any way. It'll get to Python 3 in time (it's running on 2.6 already in development). -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

At 11:27 PM 11/4/2009 +0000, Floris Bruynooghe wrote:
<cynical mode>
You have time to read this thread but no time to read "What's New In Python 3"?
</cynical mode>
Given that the average developer using tons of existing libraries on 2.x is unlikely to see any killer benefits in moving to 3.x, it's a natural attitude to have. I fought this same battle with setuptools for a long time before it sank in that people who don't perceive a need aren't going to RTFM, no matter how much time said RTFMing would save them in the long run, vs. sitting around complaining. IOW, once someone has become annoyed by the mere appearance of a necessity to deal with something that appears to be being foisted on them (whether it's setuptools or Python 3), the natural tendency is to minimize any actual work that would move in the direction of the thing they feel forced to deal with. For me, the closest thing to a killer feature in 3.x is argument type declarations, and it'd be a mild convenience at best. From a distance, many of the other changes appear like anti-features, if only because they're changing what I've been used to for twelve-plus years. (A few, like the removal of __metaclass__-in-locals support, are an active hindrance to porting.) So no, I haven't actually tried to port anything, nor have I done more than lightly skim the porting docs... looking for some reason why I'd *want* to move to Python 3. Heck, I have yet to use 2.6 to run any production code, and find some of *its* changes a bit annoying from a porting perspective. (E.g. dropping the "sets" module.) To make Py3 migration worthwhile to developers with heavy investment in the 2.x lines (and especially those supporting all the way back to 2.3 and 2.4), it'd have to have some *really* killer features. That is, be more like a Python 3000, and less like a Python 2.6 with a few bells and whistles, hampered by having to relearn some of the basic types and a soon-to-be-rebuilt standard library. Even if, in truth, the cost-benefit ratio right now *is* good for migrating to 3.x, nobody's doing a good job at promoting what those benefits are. (And it being easy to port to is NOT a benefit: nobody cares how easy it is to do something they don't see a reason to do in the first place.)

Zooko O'Whielacronx wrote:
Folks:
So, if you guys slip in your favorite new Python 3 feature into 2.7 and add a deprecation warning for your least favorite Python 2 misfeature,
Just run with the -3 flag for warnings. Also see my response to Glyph. Terry Jan Reedy

On Wed, Nov 4, 2009 at 14:54, Zooko O'Whielacronx <zookog@gmail.com> wrote:
Folks:
It occurred to me to wonder why I haven't investigated how hard it would be to make my Python packages Python-3-compatible. That's right -- I haven't even looked closely. I couldn't even tell you off the top of my head what is in Python 3 that I would have to think about except for the new unicode regime. I think the answer is that the payoff is just *so* low to me at this point that it doesn't even justify me taking 15 minutes to read "What's New In Python 3" or to execute 2to3 on my smallest package and see what it does.
But the payoff is low for you because you want an object-capabilities system and Python 3 doesn't support that kind of use (nor was Python designed to support objcap in the first place, so it's already a strained use in 2.x). -Brett
participants (9)
-
Brett Cannon
-
Floris Bruynooghe
-
geremy condra
-
Guido van Rossum
-
Larry Bugbee
-
P.J. Eby
-
Paul Moore
-
Terry Reedy
-
Zooko O'Whielacronx