On Jan 19, 2014, at 19:40, Bruce Leban <bruce@leapyear.org> wrote:

On Sun, Jan 19, 2014 at 4:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote:
> On 01/19/2014 03:35 PM, Ben Finney wrote:
> >
> >In other words, those who want Python 2 to continue need to either bite
> >the bullet and move their migration to Python 3 forward
> Um, if they want Python 2 to continue, why would they migrate to Python 3?

Because you can't always get what you want. I want a pony, but since I
can't afford one or have any place to keep it, I've made do without.

I think the odds of Python getting

        from __future__ import pony

are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:

        from __future__ import everything

If that existed, I wouldn't use it. Without it, I know my 2.6+/3.3+ code will work until 3.7. With it, if 3.5 added a new future feature, my code may only work until 3.4. That's not worth it for the convenience of saving a few characters.

since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:

        range = xrange

There are only four live future features in 2.6 and 2.7, and you can fit them all into one statement that fits in 80 columns. Which you can put into your project template, and then you're done with it.

And then I usually have one more line, "from sixify import *", where sixify is a project-specific collection of imports from six. (And then the challenge is fighting to stop people from putting non-six-related things into sixify and turning it into one of those "stdafx.h" messes that every windows c++ app has.)