Episode #79: 15 Tips to Enhance your Github Flow
Sponsored by DigitalOcean: pythonbytes.fm/digitalocean
Brian #1: pytest 3.6.0
- Revamp the internals of the
pytest.markimplementation with correct per node handling which fixes a number of long standing bugs caused by the old design. This introduces new
Node.get_closest_mark(name)APIs. - Depricating
Node.get_marker(name). - reasons for the revamp - updating existing code to use the new APIs - Now when
@pytest.fixtureis applied more than once to the same function a
ValueErroris raised. This buggy behavior would cause surprising problems and if was working for a test suite it was mostly by accident.
- Support for Python 3.7’s builtin
breakpoint()method, - see Using the builtin breakpoint function for details. - Provided by friend of the show Anthony Shaw
monkeypatchnow supports a
context()function which acts as a context manager which undoes all patching done within the
- whitespace only diffs in failed assertions include escaped characters to be easier to read.
- plus more… see changelog
Michael #2: Hello Qt for Python
- The first Qt for Python technology preview release is almost here, and for this reason we want to give a brief example on how it will open the doors to the Python world.
- The real question is: how to access the methods of a Qt class? To simplify the process, we kept Qt APIs. (basically change -> to . in the API)
- Can it be more pythonic? “We want to include more Python flavor features to Qt for Python in the near future, but at the moment we are focusing on the TP.”
- The wheels situation: we are planning a set of wheels for Linux, macOS and Windows for 64bit and a 32bit version only for windows.
- AFAIK, this is Pyside2 reborn
Brian #3: MongoDB 4.0.0-rc0 available
- MongoDB 4.0.0-rc0, the first release candidate of MongoDB 4.0, is out and is ready for testing.
Michael #4: Pipenv review, after using it in production
- Nice summary: “The current state of python’s packaging is awful, I don’t think there’s anyone who could disagree with that. This problem is recognized and there are many attempts at trying to solve the mess. Pipenv was the first and it has gained a lot of traction, however it doesn’t sit well with everyone. And it’s also not suited for every project — like libraries.”
- The multiple environment problem: The tl;dr is — supporting multiple environments goes against Pipenv’s (therefore also Pipfile’s) philosophy of deterministic reproducible application environments. So if you want to use Pipenvfor a library, you’re out of luck. That means many projects just can not use Pipenv for their dependency managment.
- The good
- Pipfile and Pipfile.lock really are superior to requirements.txt. By a ton.
- While I disliked it at first, having flake8 and security check builtin in a single tool is great
- Installing (exclusively) from a private respository works very well. Instead of replacing a dotfile somewhere in the system, specifying the repository in Pipfile is great
- Creating a new Pipfile is very easy
- No problems introducing Pipenv to it’s new users
- No problems installing from a mixture of indexes, git repositores…
- With --sequential it is actually deterministic, as advertised
- Virtualenv is much easier to get into and understand
- Dependencies can be installed into system (e.g. in Docker) — our case.
- At no point did anyone in the team even mentioned getting rid of Pipenv — which is a lot better than it sounds
- PyCon 2018 talk about the history and future of Python packaging, including pipenv.
- Recent changes to the official wording around pipenv (removes the statement that it’s the official way of managing application dependencies)
Brian #5: 15 Tips to Enhance your Github Flow
- using github projects to prioritize issues and track progress
- using tags on issues
- using hub and git-extras on command line
- commit message standards
- scoped commits
- style standards with pre-commit hooks
- automated tests and checks on pull requests
- protect master branch
- requiring code reviews
- squash pull requests
- …. more great topics
Michael #6: Pandas goes Python 3 only
- Via Randy Olseon
- It's official: Starting January 1, 2019, pandas will drop support for #Python 2. This includes no backports of security or bug fixes.
- Basically following NumPy’s lead
- The final release before December 31, 2018 will be the last release to support Python 2. The released package will continue to be available on PyPI and through conda.
- Starting January 1, 2019, all releases will be Python 3 only.
- It’s GDPR eve, are you ready?
- Need a GDPR laugh? See https://twitter.com/nadimpatel_/status/999111866633871361
- XKCD Python Environments: https://xkcd.com/1987/