Change Python version checking due conflicts with libraries that patch urllib patching

[MisterRios]

Hi there, I found a conflict with the isort library in which urllib is patched: https://github.com/timothycrosley/isort/blob/develop/isort/pie_slice.py#L135
This causes urlobject to use _qs_encode_py2 and _qs_decode_py2 functions.

In Python3, this throws a NameError: name 'unicode' is not defined as Python3 no longer has the unicode type.

Found via a Django project using spurl which has urlobject as a dependency.

[MisterRios]

I realized in e8b3b8d that versions after Python2 would not have the unicode type so it's better to check for Python2, and have everything else use the python3 methods- i.e. Theoretically a python4 would still be using the python3 methods.

[jonasvp]

Concur - checking for a stdlib attribute as a way to differentiate between Python versions seems very roundabout. Any way to get this released?

@MisterRios You might want to push this as a single commit.

[agriffis]

Since we're already importing from six, could you change this to use PY2 from there? Otherwise looks good.

[MisterRios]

@agriffis The version of six bundled here only checks for PY3- https://github.com/zacharyvoase/urlobject/blob/master/urlobject/six.py#L31

The source six does check for PY2, but it's not available in this repo- https://bitbucket.org/gutworth/six/src/8b024292064c9d2fbd7a4f352c40b261b91fd058/six.py?fileviewer=file-view-default#six.py-36

The reason I check for PY2 in particular is that only python2 will use unicode. As of Python3, and forward, there is no unicode keyword anymore. If there is ever a Python 4, and it only checks for PY3, then it will revert to using the python2 functions.

[MisterRios]

@agriffis I've inserted PY2 into the bundled six module, and imported from there. If the bundled six here is removed ever, then an import of PY2 from six would still work.

The possible future change in query_string.py would be:
from .six import PY2 -> `from six import PY2"

[agriffis]

@MisterRios Thanks, this seems like a sensible approach. If we unbundle six eventually then we'll just rely on a sufficiently recent version.

[jonasvp]

@agriffis Since the last release was a while ago - would it be possible to roll a quick point release with this commit? Our CI server (and we as well) would be extremely grateful!

[agriffis]

@jonasvp v2.4.2 now released on PyPI!