Most scientific packages already have Py3.7+ releases or are talking about it (NEP 29, scikit-learn issue). This means we should make plans on when to drop Py3.6 as well if we want to use the latest version of those packages. Additionally it allows us to use newer language features and ensures users are using a safer and faster Python. It's probably also a good idea to have a discussion on a policy going forward.

NumPy follows NEP 29:

When a project releases a new major or minor version, we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months from the anticipated release date with a minimum of 2 minor versions of Python.

This would mean that we should have dropped 3.6 last year, and 3.7 in December. Since (Python) minor versions are backwards compatible we don't actually have to make code changes, but we do have to:

• update setup.py with new minimum requirement and removing a pypi classifier
• update the continuous integration Python version matrix

And as a bonus it allows us to refactor old code with new language features, where applicable. These include:

• 3.7:
  • Data classes might simplify our core OpenML entity classes, worth a closer look.
  • Module attributes could perhaps be interesting for the extensions as described here.
  • ordered dictionaries in the language specification (as opposed to CPython implementation detail)
• 3.8:
  • the notorious walrus operator.
  • positional only parameters
• 3.10 (release later this year):
  • match statement

Of course actually using any of these features would break backwards compatibility to older Python minor versions.