Update packages

[lorddaedra]

• Add support for Python 3.9, drop support for (outdated version) Python 3.5, bump version to 2.0.0.
• Update packages.
• Change line length from 79 to 120.
• Configure flake8 exclude option.

[lorddaedra]

Also fix test test_create_one_off_charge, please, check it.

[lorddaedra]

@FPurchess @pyepye
Hello! Please, review...

[pyepye]

Hi @lorddaedra

I'm not sure this is a good idea to merge?

This will remove support for Python 3.5 but we are using any Python features which are 3.6+ only. While 3.5 is now end-of-life I don't think that means we have to stop supporting it for no reason.
This would have a knock on effect for dj-paddle as it's why Python 3.5 was chosen in the first place - It needs to support Python 3.5 for Django Django 2.1. If we remove 3.5 support the support between the 2 suddenly gets more complicated and would involve supporting several versions in parallel.

At some point we may want to use some Python 3.6+ features which is fine, but it's only at that point it's worth changing the minimum Python version we support.

Also I would very much prefer not to increase the line length. I often use several windows side by side with a ~80 character width so longer line lengths can make reading code more of a pain.

[lorddaedra]

@pyepye

My primary goal - add support for Python 3.9. Other things are just nice-to-have additions. Now I see, code is compatible with Python 3.9. At least now.

I see two points here in your comment: about Python 3.5 and about 79 line length.

About line length.
To be honestly, I do not like 120 too (but I have another reason: I like to use 160 in my projects and I use 27" display).
In general 120 is good choice for open source projects (it's popular default on GitHub, PyCharm).
In case of big mature open source project with many contributors 120 is golden mean between users of 13-15" notebooks and big displays 27-32" and more.
BUT. This project is small and I understand your role in this project and I see your contributions. 90% of commits in last year are yours. https://github.com/paddle-python/paddle-client/graphs/contributors
So I will not argue on this topic. If it is convenient for the main contributor then okay. I could revert these changes back to 79.

About Python versions
TL;DR I usually support all supported (green) and drop support for all unsupported (red) versions. It's easy rule to make world better (increase security of related project and prevent mistakes).
https://endoflife.date/python

I don't think that means we have to stop supporting it for no reason.

There are reasons not to support versions which are not supported by their maintainers.
Support for 3.5 ended 9 months ago. And last 3.6.* bugfix release was released after that date. It contain several security fixes, not available in 3.5. https://docs.python.org/release/3.6.13/whatsnew/changelog.html#security
And more and more security holes will stay open with 3.5. So we (as open source contributors) may help to prevent related damage by not supporting Python (and other software) versions, which are officially unsupported.

Sometimes developers use outdated packages because of this is a tech debt. In this case they may do not upgrade to new package versions or fork (or create support/1.0 branch in case they use git flow model) and backport fixes from master/main.

Some other reasons exists too.

• Marketing - support for old Python version and lack of support for last looks like red flag: project abandoned.
• Readability counts, dropping support for old versions allow to remove old compatibility code.
• ... and use new features (like f-strings and async, for example). It open door to async code using https://www.python-httpx.org/ for making IO requests (asyncio based code is good thing for IO tasks).

This would have a knock on effect for dj-paddle as it's why Python 3.5 was chosen in the first place - It needs to support Python 3.5 for Django Django 2.1. If we remove 3.5 support the support between the 2 suddenly gets more complicated and would involve supporting several versions in parallel.

Based on data from table on this page https://www.djangoproject.com/download/ currently supported versions are: 2.2 LTS, 3.1, 3.2 LTS. Based on release notes: Django 2.2 supports Python 3.5, 3.6, 3.7, 3.8 (as of 2.2.8), and 3.9 (as of 2.2.17). Because of Python 3.5 is already unsupported and Django 2.1 is already unsupported too, we can just drop support for Python 3.5 and Django 2.1. Also we should drop support for combination Python 3.5 with Django 2.2 and support only combinations with supported components.

It's easy rule really:

• any red component + any red component2 -> red (unsupported bundle)
• any green component + any red component2 -> red (unsupported bundle)
• any green component + any green component2 -> green (supported bundle)

Existence of any unsupported component in the bundle affect your project security level.