On Mon, Nov 5, 2012 at 9:30 AM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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 Mon, Nov 05, 2012 at 02:08:33AM +0000, Oscar Benjamin wrote:<br>
<br>
> There are certain cases where explicitly checking the version makes<br>
> sense. I think that Python 3 vs Python 2 is sometimes such a case.<br>
> Python 3 changes the meaning of a number of elementary aspects of<br>
> Python so that the same code can run without error but with different<br>
> semantics under the two different version series.<br></div></blockquote><div><br></div><div>... </div><div><br></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">


In any case, arguments about defensive coding style are getting<br>
off-topic. The point is that there are various ways to test for the<br>
existence of features, and adding yet another coarse-grained test<br>
"sys.py3k" doesn't gain us much (if anything).<br></blockquote><div><br></div><div>The problem is to maintain the code in the long term. Python 3 documentation already misses the things about Python 2 modules, so with implicit feature tests legacy code checks may quickly get out of control. It's not uncommon to see unwieldy projects with huge codebase of repetitive code in corporate environment where people afraid to bring down legacy stuff, because they don't know why it was inserted in the first place.</div>

<div><br></div><div>I thought of sys.py3k check as an explicit way to guard the code that should be maintained extra carefully for Python 3 compatibility, so that you can grep the source for this constant and remove all the hacks (such as bytes to string conversion) required to maintain the compatibility when the time comes to switch. Now I see that all points raised about it being too late, not sufficient (because API breakage occurs even between minor versions) are valid. The six module is an awesome alternative. Too bad it doesn't come bundled by default or as an easy "after installation" update.</div>

<div><br></div><div>The granularity of a "feature" is interesting. Previously it was from __future__ import 'feature'` for forward compatibility, but it required planning features beforehand. Now there is a need to test for a feature, which is not present in the early version, and we have only implicit ways. These ways assume that we know what a feature and its symptoms are, which is not the case when code is not yours or you have little experience with either Python 2 or 3. I hoped that `if sys.py3k` could help make code more readable, but it will be more useful to have shared 'features' module which can contain explicit checks for existing features and return False for things that are not present.</div>

<div><br></div><div>`six` is awesome though.</div>-- <br>anatoly t.<br></div></div>