First real fix: open the temp file in text mode.

This updates several Python type definitions and uses to bring us closer
to Python 3 compatibility. This includes:

* Replacing staticforward and statichere with static. These were a hack for
  old compilers and are not supported/needed anymore.
* Using Py_TYPE() instead of ob_type; ob_type is hidden in Py3.
* Replacing getattr with getters/setters. getattr is sort-of supported in
  Py3, but Py_FindMethod is not. So we just use the newer
  methods/getsetters mechanisms and start using PyType_Ready everywhere.
* Use PyVarObject_HEAD_INIT for types, since types are PyVarObject.
* Use PyMODINIT_FUNC for module initialization functions.

There are some tab/space issues in this commit. I'm set for spaces; the
source is a little schizo.

Other ports have taken advantage of the fact that Python 3 has wrappers for
the old buffer protocol, but there's a significant disadvantage: you can't
let the buffered object know when you're done with it.

Since Python 2.6 supports the new protocol, we just go ahead and move to
it.

I'm pretty sure this preserves the intent of the code. HAVE_UNICODE is now
assumed, and PyString is only used if we're not in Py3k.

Since this is the only file that uses PyUnicode, I'm going to go ahead and
#define PyUnicode and PyBytes back to PyString for 2.6, and explicitly
change out every call so I have to check them all.

Python 3 enables C's strict aliasing rules for the first time, which means
you need to be careful about the ways you reference pointers. Here, we're
using a char[4] as an INT32, so we cast between them using a union.

This commit:

* Adds Python 3 module initialization functions. I split out the main init
  of each module into a static setup_module function.
* Adds a py3.h which unifies int/long in Python 3 and unicode/bytes in
  Python 2. _imagingft.c unfortunately looks a little kludgy after this
  because it was already using PyUnicode functions, and I had to mix and
  match there manually.

With this commit, the modules all build successfully under Python 3.

What this commit does NOT do is patch all of the uses of PyArg_ParseTuple
and Py_BuildValue, which all need to be checked for proper use of bytes
and unicode codes. It also does not let selftest.py run yet, because there
are probably hundreds of issues to fix in the Python code itself.

This commit also renames some functions from "fromstring" and the like to
"frombytes". I'll probably need to come back later and update any
references to "string," here or in the docs.

I also noticed that encode allocates some data for certain codecs, but
never frees them. That would be a good bug to fix. I fixed the one where it
outright stole a pointer from Python.

This is Christoph Gohlke's test suite from his personal PIL package found
at http://www.lfd.uci.edu/~gohlke/pythonlibs/.

This is just to bring it in as a separate commit. Future commits will align
it with Pillow.

Most of the differences are in tobytes/tostring naming and expected
behavior of the bytes() constructor. The latter was usually easy to fix
with the right bytes literal.

This is a good preview of what will have to happen in the Python 3 code.

This gets the putdata test case to run correctly under 2.6/2.7. It fixes an
issue where the value 0xFFFFFFFF (which is long in old Python) isn't
recognized and putdata tries to parse it as a tuple.

The original fix comes from Christoph Gohlke. It was adapted to work in
both 2.* and 3.*.

This is from http://scary.beasts.org/security/CESA-2004-001.txt. This was
missing from Gohlke's tests. With this file, I see 79 tests and no failures
on my setup from 2.6/2.7.

callable(c) is isinstance(x, collections.Callable) in py3k.

y.has_key(x) is gone (use x in y), and keys(), values(), items(), and
range() all return views.

Some iterables needed to be packed into lists, either because the code
expected a list (such as "range(256) * 3") or because the original
collection was being modified (automatic global declarations).

The Tiff ImageFileDictionary is a special case and will be dealt with in
another commit.

This commit brings in the collections.MutableMapping mixin to provide full
dictionary support for ImageFileDictionary.

What's really going on is that map() and filter() return iterators in py3k.
I've just gone ahead and turned them all into list comprehensions, because
I find them much easier to read.

The day has arrived when Python provides an official way to handle Unicode
strings.

operator.isNumberType() and .isSequenceType() go away in py3k.

reduce() is no longer a built-in function in py3k.

Seriously, if you didn't know that, you've been in a freaking cave, man.

Py3k no longer supports unpacking tuples in the parameters.

In py3k, imports are absolute unless using the "from . import" syntax.

This commit also solves a recursive import between Image, ImageColor, and
ImagePalette by delay-importing ImagePalette in Image.

I'm not too keen on this commit because the syntax is ugly. I might go back
and prefer the prettier "from PIL import".

Backticks are no longer valid syntax for repr().

For awhile now, str == type("") and so on. So we use the appropriate int,
str, basestring, or tuple type where applicable.

After adding all the encode() calls, the PDF plugin (and a few others)
became much harder to read. This should be much easier on the eyes.

Not too convinced of the size fix. While it works against my file, I'm not
sure someone would have accidentally been an index off and not noticed.

This test includes an XPM file with transparency.

This is unnecessary now.

This fixes a build warning on 64-bit machines.

...although, you have to turn on deprecation warnings specifically in order
to get them.

…hon 2.5 is no longer supported (its support is broken in many ways in this branch); remove bundled doctest.py module (it is in stdlib since forever); remove extra stuff from tox.ini

String exceptions don't work anymore.

The Sane documentation seems to imply that these option strings contain
Latin-1 text, not byte data, so we decode it and present it to the user
that way.