<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 19, 2015 at 11:21 AM, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><div> </div><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 dir="ltr"><div class="gmail_quote"><span><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 dir="ltr"><div>It would be nice to have a:<br><br></div><div>from __future__ import py3<br><br></div><div><span style="font-size:13px;line-height:19.5px"></span></div></div></blockquote></span></div></div></blockquote><div> </div><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 dir="ltr"><div class="gmail_quote"><span><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 dir="ltr"><div><span style="font-size:13px;line-height:19.5px">While in hindsight having a python3 __future__ statement that just turned on everything would be handy, this runs the risk of breaking code by introducing something that only works in a bugfix release and we went down that route with booleans in 2.2.1 and came to regret it.</span></div></div></blockquote></span></div></div></blockquote><div><br></div><div>That may well kill the idea then, yes.</div><div><br></div><div>Guido wrote:</div><div><blockquote 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" class="gmail_quote">It's just about these four imports, right?<span class="im"><br></span><span class="im"><span style="font-family:monospace,monospace">from __future__ import absolute_import<br></span></span><span class="im"><span style="font-family:monospace,monospace">from __future__ import division<br></span></span><span class="im"><span style="font-family:monospace,monospace">from __future__ import print_function<br></span></span><span class="im"><span style="font-family:monospace,monospace">from __future__ import unicode_literals</span></span></blockquote><div><br></div><div>yup, but that is enough to be a able to remember and type...</div><div><br></div><div>and will there be more? probably not, but .....</div><div> </div><div>But you are right, if we can redude that to a couple, maybe a smaller deal.</div><div> </div><blockquote 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" class="gmail_quote">I think the case is overblown.<br>- absolute_import is rarely an issue; the only thing it does (despite the name) is give an error message when you attempt a relative import without using a "." in the import. A linter can find this easily for you, and a little discipline plus the right example can do a lot of good here.<br></blockquote><div><br></div><div>sure -- but this one is more for the learners -- these things are confusing -- and getting something that works in one version of python but not another will be more confusing, still. </div><div><br></div><div>And much as I wish everyone would use a good linter....</div><div> <br></div><blockquote 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" class="gmail_quote">- division is important.<br>- print_function is important.<br></blockquote><div><br></div><div>so maybe those two are enough....</div><div> </div><blockquote 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" class="gmail_quote">- unicode_literals is useless IMO. It breaks some things (yes there are still APIs that don't take unicode in 2.7) and it doesn't nearly as much as what would be useful -- e.g. repr() and <stream>.readline() still return 8-bit strings. I recommend just using u-literals and abandoning Python 3.2.</blockquote><div><br></div><div>hmm -- I find myself doing an unholy mess of u"" and "". And I tried teaching an intro class where I used u"" everywhere -- the students were pretty confused about why they were typing all those u-s, particularly since it didn't seem to make any difference.</div><div><br></div><div>Sure there is breakage, but there is breakage on some of these between py2 and py3 anway -- APIs that return py2 strings on py2... So <span style="color:rgb(80,0,80);font-family:monospace,monospace">unicode_literals </span>is still useful to me.<br> </div><div>But Brett was probably right -- somethign minor but useful but only works on the very latest bug-fix release is probably an attractive nuisance more than anything else.</div><div><br></div><div>-Chris</div><div><br><br><br> </div></div></div><div><br></div>-- <br><div><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R <a href="tel:%28206%29%20526-6959" value="+12065266959" target="_blank">(206) 526-6959</a> voice<br>7600 Sand Point Way NE <a href="tel:%28206%29%20526-6329" value="+12065266329" target="_blank">(206) 526-6329</a> fax<br>Seattle, WA 98115 <a href="tel:%28206%29%20526-6317" value="+12065266317" target="_blank">(206) 526-6317</a> main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>