Drop python 2, Django<1.11 support

[rpkilby]

@carltongibson, you sure you want to drop py2k support? 😄

[codecov-io]

Codecov Report

Merging #797 into develop will decrease coverage by 0.03%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop     #797      +/-   ##
===========================================
- Coverage    97.42%   97.38%   -0.04%     
===========================================
  Files           15       15              
  Lines         1202     1149      -53     
===========================================
- Hits          1171     1119      -52     
+ Misses          31       30       -1

Impacted Files	Coverage Δ
django_filters/conf.py	97.14% <ø> (-0.08%)	⬇️
django_filters/rest_framework/backends.py	92.59% <ø> (-0.27%)	⬇️
django_filters/rest_framework/filterset.py	100% <ø> (ø)	⬆️
django_filters/__init__.py	94.44% <ø> (-0.3%)	⬇️
django_filters/rest_framework/__init__.py	100% <ø> (ø)	⬆️
django_filters/views.py	100% <ø> (ø)	⬆️
django_filters/compat.py	60% <ø> (-11.43%)	⬇️
django_filters/fields.py	100% <100%> (ø)	⬆️
django_filters/widgets.py	95.13% <100%> (-3.58%)	⬇️
django_filters/utils.py	98.19% <100%> (-0.02%)	⬇️
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7e4530a...67b3454. Read the comment docs.

[carltongibson]

I think so.

Anyone on Python 2 is much better off upgrading that that upgrading DF.

And just look at all that red!

We’ll hold off till tomorrow to decide

[durdenk]

You really want to drop python 2.7 support? Did I get it wrong?

[carltongibson]

@durdenk Yep. That's right. Do you have thoughts on that?

[rpkilby]

If we decide not to drop python 2, we can still drop the compatibility code and older versions of Django.

[durdenk]

I just checked libraries I use and saw that all of them support python3, maybe its time for me to get over with it.

[carltongibson]

@durdenk +1 🙂

I think this is the point.

There really is no need to be on Python 2 any longer. (Is there...?)

And Python 3 is such a big step up (in performance, in features, in happiness)...

Python 2 just causes us issues (with Travis etc).

If some company wanted to fund Python 2 support that would be fine. But this is a volunteer effort and I see no real reason to keep expending energy here.

[rpkilby]

I'm all in favor of dropping python 2. The maintenance isn't that much of an issue, but it is keeping us from moving forward and using all of those shiny python 3.x features.

[claytondaley]

I'd love to upgrade to PY3 but I can't pull a whole project up just to pick up bug fixes on this project. Please consider reverting this!!!

[rpkilby]

pick up bug fixes on this project.

Hi @claytondaley. These changes have been included in the v2.0.0.dev1 pre release, which includes a number of breaking changes beyond simple bug fixes. Note that v1.1 was release about a week before, which should contain most of the important fixes you might be looking for.

[carltongibson]

@claytondaley v1.1 will be the last to support Python 2. It's fully functional, and Django-Filter is mature and battle tested. It won't stop working. You're free to continue to use it.

It's worth noting that (other than those related to the move to 2.0) there exactly were 0 open issues when we made this move. There are no bug fixes to pick up.

[claytondaley]

Are you going to accept an improvement to just the 1.x branch? I need a fix for #812 and was going to assemble a proof of concept to link to the issue (when I discovered the compat issue).

[carltongibson]

Are you going to accept an improvement to just the 1.x branch?

No. This is a small project. All effort is going into the 2.0 branch from now.

I'd really suggest you take the time to upgrade to Python 3. You'll get a lot more from it than any addition you could make to Django Filter. (Or even Django for that matter.)

It's also quite easy. There really is no reason to be on Python 2 any longer.

[rpkilby]

Regardless, #812 is proposing fundamental changes to Filters (eg, migrating Filter.field_class to a model field from a form field), and would most certainly be a breaking change. That kind of breaking change would necessitate a major version bump, and would not be applicable to a 1.x bug fixing branch.

[claytondaley]

Ideally yes, but it's easy enough to workaround. field_class is only used as a callable so you can replace it with a function (that returns an instance) and locate the model.Field in its own parameter. See for yourself.