On Fri, Mar 21, 2014 at 9:23 AM, Marko Rauhamaa <ma...@pacujo.net> wrote:
> Ned Batchelder <n...@nedbatchelder.com>:
>> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>>> Well, with proper care, I suppose the same code base could support perl
>>> as well. ;)
>>
>> I'm not sure how to take this comment. I feel like you are mocking my
>> choice. I wanted to make coverage.py available to as broad an audience
>> as possible, something that I think is worthwhile. Yes, there was an
>> engineering cost, but the tradeoff was worth it.
>
> I can't judge if your particular choice was the right one. My only point
> is that python2 and python3 are so far apart as to be regarded as
> independent languages.
They're definitely not independent languages. The biggest change is
str/unicode->bytes/str, and you can get part of that in Python 2.6/2.7
with "from __future__ import unicode_literals". You may still run into
problems with some functions that expect str and won't take unicode
(or vice versa), but it's easy to make code that runs across both
versions that way. Then toss in "from __future__ import
print_function" and happily use the expanded features of print, or go
for the lowest common denominator:
print("some single string")
which works happily in all versions of Python.
I've written code that runs on 2.6+/3.2+. (Or maybe it's 3.1+;
whichever version Debian Squeeze ships with.) It's pretty easy. It's
certainly a lot easier than writing code that runs as either Pike or
C++, for instance. THOSE are independent languages. (And yes, I've
written that sort of code. Had a #define block up the top to handle
some naming differences, and then restricted myself to a *really*
narrow set of common operations. Was a neat way to prove correctness,
though.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
