Officially support only 2.7 and 3.3 in Pillow 2.0.0

[aclark4life]

Any objections? 2.6 and 3.2 will likely continue to work, but it hurts my head to think about supporting them "officially".

Also for the grant work I'm doing, I'm going to test 2.6 because I said I would :-)

[kmike]

Yep, strong -1:)

Supporting 2.6 and 3.2 is easy (I'm supporting > 20 python packages that declare Python 2.6, 2.7, 3.2 and 3.3 support, and that's really not hard). These versions are widely used and not deprecated in any way: 2.6 is a default Python in current Debian and Ubuntu LTS 10.04 (EOL in 2015); Python 3.2 is a 3.x Python in latest Ubuntu LTS (12.04, EOL in 2017) and it will be default 3.x Python in upcoming Debian Wheezy.

Python 2.5 is a completely different story (it doesn't have many things that make porting easy), but 2.6 is not that different from 2.7, and so is 3.2 from 3.3.

[aclark4life]

Heh OK, noted. I'll switch the official policy back to all 4 versions. Any "real world" issues you know of to look out for? I know that 3.3 contains a significant change to 3.2 with regard to the u'' syntax:

aclark@Alexs-MacBook-Pro:~/Developer/python-imaging/Pillow/ > python3.2
Python 3.2.3 (default, Feb 11 2013, 09:34:07) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u'foo'
  File "<stdin>", line 1
    u'foo'
         ^
SyntaxError: invalid syntax
>>> 
aclark@Alexs-MacBook-Pro:~/Developer/python-imaging/Pillow/ > python3.3
Python 3.3.0 (default, Feb 11 2013, 09:36:51) 
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.24)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u'foo'
'foo'

At least we don't have to support 2.5, 3.0, or 3.1 …

[kmike]

The 'u' change is not that serious: it may be enough for small scripts to be "almost" compatible with Python 3.x, but for larger modules it usually doesn't matter.

Look: there are also 'foo' strings that have to be fixed because they are bytestrings in 2.x and unicode in 3.x. So you have to explicitly mark all 'foo' strings as b'foo' if they should be bytestrings, and u'foo' if they should be unicode (and str('foo') if they should be bytestrings under 2.x and unicode under 3.x).

But if all strings are explicitly marked with either b or u or str(), you can safely add from __future__ import unicode_literals to the top of the file and remove the "u" clutter. At this point it doesn't matter if supported Python is 3.3 or 3.2 because the code is compatible with both (and is cleaner IMHO).

Python 2.7 has some improvements in standard library (e.g unittest2 or memoryview support or collections.OrderedDict or argparse) and it also has some syntax changes borrowed from 3.x (like {1,2,3} syntax for sets) - this makes writing new code easier.

But if library already supports Python < 2.7, then it doesn't use any of these new features (this is exactly the Pillow case) so Python 2.7 provides almost nothing in terms of easier Python 3.x porting (because pre-2.7 syntax like set([1,2,3]) still works in 3.x). There are some edge cases fixed in standard library in 2.7 that may help with porting (e.g. base64 accepting bytearray as well as bytes - that works in 2.7 and in 3.x, but not in 2.6) - but these are edge cases.

There may be C API changes that I'm not aware of (I use Cython for C extensions and it provides compatibility automatically), but chances are the situation with C API in 2.7 is similar.

[kmike]

Thanks 👍

[aclark4life]

Very good info, thank you

[kmike]

..and why I mentioned bytearray:

• b'foo'[0] is bytes in Python 2.x and an integer in Python 3.x;
• bytearray(b'foo')[0] is integer in both 2.x and 3.x;
• b'foo'[0:1] is bytes in both 2.x and 3.x

this is a common gotcha for low-level libraries.