<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>On Jan 19, 2014, at 19:40, Bruce Leban <<a href="mailto:bruce@leapyear.org">bruce@leapyear.org</a>> wrote:</div><div><br></div><blockquote type="cite"><div dir="ltr"><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 19, 2014 at 4:06 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote:<br>
> On 01/19/2014 03:35 PM, Ben Finney wrote:<br>
> ><br>
> >In other words, those who want Python 2 to continue need to either bite<br>
> >the bullet and move their migration to Python 3 forward<br>
><br>
> Um, if they want Python 2 to continue, why would they migrate to Python 3?<br>
<br>
</div>Because you can't always get what you want. I want a pony, but since I<br>
can't afford one or have any place to keep it, I've made do without.</blockquote><div><br></div><div>I think the odds of Python getting</div><div><br></div><div> from __future__ import pony</div><div><br></div>
<div>are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:</div><div><br></div><div> from __future__ import everything</div></div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
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:</div></div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div> range = xrange</div></div></div></div></blockquote><div><br></div><div>T<span style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">here 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.</span></div><div><br></div><div>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.)</div></body></html>