Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Python 3.4, 3.5 and 3.6 #15

merged 7 commits into from Jan 11, 2019

Add support for Python 3.4, 3.5 and 3.6 #15

merged 7 commits into from Jan 11, 2019


Copy link

@c-w c-w commented Jan 10, 2019

This pull request adds support for Python 3.4, 3.5 and 3.6 which makes the library usable on all Python 3 versions.

The main changes are:

  • Removal of dataclass in favor of namedtuple. The default argument setting for namedtuple is somewhat obscure so this is an unfortunate change. There does exist a back-port of dataclass but it only supports Python 3.6; given that the default Python version of many Linux distributions still is 3.5 I however believe it's important to be compatible farther back.

  • Replacement of variable type annotations with type comments. This is a fairly straight-forward change and some may even find the comment-style typing to be less cluster than the inline approach. The main drawback of this change is that flake8 or pylint don't recognize # type comments and therefore complain about unused typing imports which have to be silenced. Ideally this would be solved at the linter level.

  • Replacement of f-strings with string.format; small change.

  • Replacement of dictionary joining with explicit update call; less terse but arguable more explicit for less experienced Python developers.

As previously, the pull request uses Docker to run the CI. However, now the various Python versions are supported by parameterizing the base Python image. This approach is adapted from an approach I successfully used on a previous project (c-w/gutenberg).

c-w added 7 commits Jan 10, 2019
While we do use Docker to run the project's build, informing Travis that
we're a Python build has several advantages such as making Python
available on the path. This means that if we want to use other tools in
the Python eco-system post-build (e.g. coveralls for code coverage) then
we can easily make these tools work.
Script should run the tests and install should create the artefacts
necessary to run the tests.
@michaelperel michaelperel merged commit 8267f24 into michaelperel:refactor Jan 11, 2019
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants