On Thu, 20 Mar 2014 16:53:25 -0400, Ned Batchelder wrote: > On 3/20/14 4:42 PM, Marko Rauhamaa wrote: >> Ned Batchelder <n...@nedbatchelder.com>: >> >>> Plenty of people have adopted a dual-support strategy, with one code >>> base that supports both Python 2 and Python 3. The six module can help >>> a great deal with this. >> >> I wonder how easy the resulting code is to the eyes and how easy it is >> for the casual maintainer to accidentally break the delicate balance. >> In a word, I wouldn't go there. Stay with Python2 as long as you must >> and then, migrate and leave it behind. > > This is fine advice for applications, but tools, libraries, and > frameworks may want to support more than one version at the same time.
+1 Actually, even applications may want to support multiple versions. If I have a Python script that does something, I might not want to tie it to one specific version. In principle there's not much difference between "this will run under Python 2.6 and 2.7" and "this will run under Python 2.7 and 3.3". In practice, it's a little trickier to cross the 2/3 barrier than the 2.6/2.7 barrier. But it is still quite achievable, with a little extra effort. But you know that even better than I -- I take my hat off to you for supporting all the way back to Python 2.3, that is far more dedicated than I am. In my experience, such as it is, the hard part about writing code that works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions. > It's an extreme case, but the latest released version of coverage.py > supports Python 2.3 through 3.3 with one code base. To do it, there's a > compatibility layer (akin to six). Then you stay away from features > that aren't available on all versions. In a few places, you might need > to have version checks, and the code can get a little idiomatic to > continue to work. > > It's a tradeoff: you have to decide for yourself whether the effort is > worth the benefit. I was glad to be able to drop support for 2.3, 2.4, > and 2.5, and now only support 2.6-3.4 in coverage.py. Sounds like your experience agrees with mine. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
