Checks for 'not six.PY3' instead of 'six.PY2' breaks python 4.0

Multiple places in the source code there are checks involving six.PY3, like in [this example](https://github.com/kennethreitz/requests/blob/362da46e9a46da6e86e1907f03014384ab210151/requests/packages/urllib3/fields.py#L43):

    if not six.PY3 and isinstance(value, six.text_type):  # Python 2:

This will needlessly break on python 4 when it is eventually released. Instead, all checks should generally be on the value of `six.PY2`:

    if six.PY2 and isinstance(value, six.text_type):  # Python 2:

(I'm not sure that there's any good use at all for the value of `six.PY3`. It seems like it was a mistake by the six developers to include it at all, because it encourages writing code that will break on python 4. Unlike python 3, python 4 will not be backwards incompatible, but simply the version of python after 3.9, IIRC.)


There is absolutely no evidence to say that Python 4 is going to be a thing. The idea that Python rolls over the major version at '10' is not really founded on any evidence at all, and there are counter examples: for example, Python 2.7 did not become Python 2.8 when 2.7.10 was released.

In the absence for any evidence that this will happen, I think this is a nonexistent risk. Thanks for the report!

I should note as well that we are likely to drop support for Python 2 *well* before any hypothetical Python 4 comes out, at which point all of the `if PY3` will disappear in favour of just being, you know, the actual control flow of the code.

Not only would those `if PY3` or `if not PY2` conditions drop but all the handling around bytes and text would be 100x simpler.

Your choice of course, I'm just reporting what I see as an issue.

It's not just me though, and not as far fetched as you would have it either. The official "Porting Python 2 Code to Python 3" documentation [specifically warns against just this kind of code, *and* tables python 4](https://docs.python.org/3/howto/pyporting.html#use-feature-detection-instead-of-version-detection), stating:

> The problem with this code is what happens when Python 4 comes out? It would be better to treat Python 2 as the exceptional case instead of Python 3 and assume that future Python versions will be more compatible with Python 3 than Python 2

It goes on to recommend not using if-checks on the python version at all, and you may want to look into that too. Or not. :-)


> It goes on to recommend not using if-checks on the python version at all, and you may want to look into that too. Or not. :-)

That documentation was written before several libraries were written that break what would otherwise be the best practice for porting. We've dealt with them many times before. These version checks are orders of magnitude better. Please, we know what we're doing.

Just to follow up on this matter, the newly accepted [PEP 563](https://www.python.org/dev/peps/pep-0563/) specifically mentions python 4.0 following python 3.9. Seeing how historically, there has been a new python release roughly every 1.5 years, and 3.6 was released in December 2016, we can extrapolate and find that python 4.0 should release somewhere around December 2022, about 2 years after python 2.7 has been officially deprecated. The first development versions of 4.0 will appear 1.5 years before, in mid 2021. My guess is that there will still be a considerable number of python 2.7 users at that time -- it's just 3.5 years, and time flies.

But even if you do end up supporting python 2.7 until after python 4 is a thing, I no longer think this code will be a problem, because I'm fairly certain that `six` will be forced to make `six.PY3` be `True` for python 4.0 as well, in order to avoid breaking code like this.

So I agree with you that this is a non-issue, though not for the same reasons. :-)