<p><br>
On Nov 6, 2012 2:12 AM, "Barry Warsaw" <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
><br>
> On Nov 05, 2012, at 06:04 PM, Nick Coghlan wrote:<br>
><br>
> >Even better (<a href="http://packages.python.org/six/#package-contents">http://packages.python.org/six/#package-contents</a>):<br>
> ><br>
> >    import six<br>
> ><br>
> >    if six.PY3:<br>
> >        # Ooh, Python 3<br>
> >    else:<br>
> >        # Not Python 3<br>
> ><br>
> >If anyone is trying to do single code base Python 2/3 support without<br>
> >relying on six, they're doing it wrong. Even bundling a copy (if you<br>
> >don't want to deal with dependency management issues) is a better idea<br>
> >than reinventing that wheel.<br>
> ><br>
> >If you *are* rolling your own (or need additional compatibility fixes<br>
> >that six doesn't provide), then all Python 2/3 compatibility hacks<br>
> >should be located in a small number of compatibility modules. They<br>
> >*shouldn't* be distributed widely throughout your codebase.<br>
><br>
> While I agree with the sentiment, and also agree that six is an excellent<br>
> package that can be very useful, I'll just point out that it's often very<br>
> possible and not at all painful to write to a single code base without using<br>
> it.  It all depends on what your code does/needs.</p>
<p>True, my own 2/3 compatible projects don't use it, but they also don't have any significant special cases for either version. I guess stick a "for non-trivial cases" qualifier in there somewhere :)</p>

<p>Cheers,<br>
Nick.<br>
 <br>
--<br>
Sent from my phone, thus the relative brevity :) </p>
<p>> Cheers,<br>
> -Barry<br>
><br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-ideas">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
><br>
</p>