Drop support for EOL Python 2.7

[hugovk]

This PR has the objective of dropping support for EOL Python 2.7 to reduce maintenance burden, reduce use of CI resources, modernise the codebase, and allow new Python features to be freely used.

Fixes #478.

Changes

1. Stop testing 2.7
2. Update docs, python_requires and classifiers
3. Remove redundant code such as compat.py
4. Update Python syntax using https://github.com/asottile/pyupgrade ----py36-plus

Checklist

Checklist for for pull requests including new code and/or changes to existing code...

• Code
  • Includes unit tests
  • New functions have docstrings with examples that can be run with doctest
  • New functions are included in API docs
  • Docstrings include notes for any changes to API or behaviour
  • All changes documented in docs/changes.rst
• Testing
  • (Optional) Tested local against remote servers
  • Travis CI passes (unit tests run under Linux)
  • AppVeyor CI passes (unit tests run under Windows)
  • GitHub Actions CI passes (unit tests run under Linux, macOS, Windows)
  • Unit test coverage has not decreased (see Coveralls)
• Changes
  • (Optional) Just a proof of concept
  • (Optional) Work in progress
  • Ready to review
  • Ready to merge

[coveralls]

Coverage increased (+0.9%) to 92.221% when pulling 735e809 on hugovk:rm-2 into 84c7b7f on petl-developers:master.

[juarezr]

Great!
I'm wondering about what are your plans.

Should this land in a major version change? like 2.0?

Also, I would like to hear @alimanfoo about the recommended change.

[hugovk]

Should this land in a major version change? like 2.0?

Some projects don't but generally they do bump the major version and I'd tend to agree, as it's a good way to signal for users.

[juarezr]

Some considerations:

1. As stated on @alimanfoo roadmap here it would be interesting to drop old behavior like convert() and fieldmap() swallow errors silently by default #365 and this.
2. Other interesting migrations for v2.0 would be [POC] added typing to materialize (breaks py27 tests) #559 and Migrate to pytest #453. Maybe after v2.0?
3. Also, I wonder what could break within external libraries for:
   a. File formats
   b. Remote Access

[juarezr]

I think this is a great addition and the needed next step for petl.

But I wonder if also it would be possible before merging this PR:

• Make a compatibility break release, with a major version change to 2.0.
• Change all the planned breakage previously issued/reported for:
  • Troublesome behavior change like convert() and fieldmap() swallow errors silently by default #365
  • Awkward API changes
  • Any modification that can impact end-users
• Executing extensive tests with File formats, Databases, and Remote file access
• Evolve the possibility of maintaining a branch for some time to:
  • Tackling security vulnerabilities / CVE
  • Giving some time for users that can't afford to upgrade right now
• Hear the improvements that people are aiming for after the merge.
  • It's worth dropping python2.7 with no other planned improvement ?
  • Check if anyone would like to commit some effort for Migrate to pytest #453
  • Check if anyone would like to commit some time for [POC] added typing to materialize (breaks py27 tests) #559 or another feature that depends on dropping py2.x.
• Hear project founder @alimanfoo opinion.

[hugovk]

Seems this has gotten out of sync, closing and it can be revisited afresh when the above issues are resolved.

[juarezr]

Yes, Sure.

The evolution in this PR paves the road for migration.
I think there are a few additional issues to solve and we are done.