jdunck/python-unicodecsv — pull request #26 by blagarde (2014-01-31 10:15:33+00:00)
Title: Python3 support

Hi @jdunk,

In some of my projects, I need a Unicode CSV module that supports both Python 2 and 3:
```
import unicodecsv as csv # would work in all Python versions.
```

To achieve this, I can (sort of) currently do:
```
import sys
if sys.version_info[0] < 3:
import unicodecsv as csv
else:
import csv
```
But it's a bit ugly, and - more annoyingly! - code using the resulting `csv` might work in py2x while failing in Py3k (or the other way around).

I thought https://github.com/jdunck/python-unicodecsv/pull/20 would solve this problem, but it doesn't really. You must've seen the Python 3.2 and 3.3 test runs in your Travis builds:
https://travis-ci.org/jdunck/python-unicodecsv/builds/17442925

So the ambition of this branch is to make `unicodecsv` a drop-in replacement for the `csv` modules of both Python3 *as well as* Python2.
My hope is that this is achievable without:
a) Loosing any Python2 backwards compatibility
b) Having to resort to too much python2/3 compatibility gymnastics

Note: the `csv` API changed slightly in Py3k, so we might not be able to easily support all Python3 use cases (e.g. the `newline=` kwarg introduced in Py3k), however I expect most code calling `csv` is the same in Python 2 and 3.

### Summary
At a high level, I used the `if sys.version_info[0] < 3` trick you suggested in the above PR to make use of Py3k's `csv`.
Since `unicodecsv` already has many test cases, "all" that needs to be done is get them to work on Py3k.

### Current situation
At the moment the tests for Python 3 in `master` fail/crash for these reasons:
1. `unittest2` can't be imported
2. `StringIO` doesn't exist
3. `string.letters` is now `string.ascii_letters`
4. `doctest` expected outputs are not geared towards py3k
5. `print` as a statement doesn't exist
6. The u"..." syntax doesn't exist in 3.2

So far I have fixed all the above, and that gets about a third of the tests to pass.

The remaining ones fail because of one or more of the following general reasons:
7. Py3k incompatibilities in the `unicodecsv` testing code (e.g. changes in the API of `array`)
8. Py3k incompatibilities in the `unicodecsv` code (e.g. file object API and line ending handling) <- (these are the tricky ones!)
9. API changes for `csv` between py2x and py3x (e.g. in `TestUnicodeErrors`, use of the `errors=` kwarg)

Sorting out 7-9 is still work in progress (help welcome!).
For now, I've made a `@python3_skip` decorator to temporarily skip tests that don't yet pass. We can un-decorate them progressively as we make them Py3k-compliant.

Here is the current build result:
https://travis-ci.org/blagarde/python-unicodecsv/builds/17936810