techtonik at gmail.com
Wed Nov 7 19:35:42 CET 2012
On Mon, Nov 5, 2012 at 9:30 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Mon, Nov 05, 2012 at 02:08:33AM +0000, Oscar Benjamin wrote:
> > There are certain cases where explicitly checking the version makes
> > sense. I think that Python 3 vs Python 2 is sometimes such a case.
> > Python 3 changes the meaning of a number of elementary aspects of
> > Python so that the same code can run without error but with different
> > semantics under the two different version series.
In any case, arguments about defensive coding style are getting
> off-topic. The point is that there are various ways to test for the
> existence of features, and adding yet another coarse-grained test
> "sys.py3k" doesn't gain us much (if anything).
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.
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.
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.
`six` is awesome though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas