Python 3 support, fix #2.

[tony]

Hey how are you! Let's get this forward compatible with python 3. #2

• __future__ imports for .py files.
• Replaces some instances of filter with list comprehensions.
• Created a py2map inside of _compat to import into code, which preserves python 2.x's map behavior in python 3.
• Update README.rst for python 3 support
• Update setup.py classifier data
• Update Travis for python 3.3 support (they don't have 3.4 support yet, tox passes 3.4 for me though)
• Import reduce from functools.
• Add tox.ini file.

[maaku]

Again, any reason you're not using the standard six package, instead of reinventing the wheel in _compat? See:

https://pypi.python.org/pypi/six

[tony]

@maaku : I did back at https://github.com/monetizeio/sqlalchemy-orm-tree/pull/8#commitcomment-5747906.

The pattern used in modern python apps is to have a _compat. Even frameworks like django desire phasing out six.

http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

In this case, we don't reinvent the wheel per se, we vendorize a file apps like flask, werkzeug and jinja2 use. SQLAlchemy keeps theirs at https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/util/compat.py.

[tony]

Another observation, this looks through gh and bb for compat modules: site:github.com || site:bitbucket.org "_compat.py" || "compat.py"

It's becoming the forward-compatible best practice. The aim of modules like requests, flask, sqlalchemy is to have good looking internals. Six can get in the way of that. In addition, vendorizing a small library beats adding an external dependency.

[maaku]

Thanks for responding, and sorry I didn't see your other message in the flood of notification emails. Armin's word is good enough for me.