I have written before about Python tooling. However, as all software, things have changed -- and I wanted to write a new post, with my current understanding of best practices.
As of now,
pytest has achieved official victory.
Unless there are overwhelming reasons to use something else,
strongly consider using it as your test runner.
The only good reason is an existing project,
with an existing test runner --
and even there,
checking if pytest will just run your tests as is is worthwhile.
Even when using Twisted,
unless you are implementing a new reactor,
tests should be using in-memory reactors --
so the usefulness of
trial is limited.
In the static checking arena,
are both still going strong.
There are less and less reasons not to use both,
especially if starting a project from scratch.
flake8 plugin ecosystem is rich,
and it is useful to look around and see if useful things are there.
For example, the
plugin is extremely strict about coding conventions --
hard to introduce to existing code bases,
but wonderful when starting out a new one.
In the meantime,
pylint has decent static code flow analysis
which can often prevent bugs.
that Python static code analysis is hard,
and pylint is not perfect.
it will often strugle with
Last but not least,
mypy has made a showing in the field.
It supports both Python 2 an 3,
and allows annotating functions with types,
in order to find mismatches before running the code.
This is especially useful at API "boundaries",
where the unit tests tend to cross less.
tox testing system is still the golden standard in Python.
It can test complicated dependency matrixes,
and allows configuring test commands flexibly.
Its documentation is somewhat lacking, sadly --
it is often the case new tricks are only apparently after reading
someone else's tox file.
Building wheels, especially if the project has no native-code extensions, is nowadays considered standard. The best place to build wheels is in tox, when configuring a test that will build a wheel, install it, and then test against the installed wheel.
The best and most reliable way to upload wheels,
and source distributions,
to PyPI is to use
It used to be a good idea to test against the test PyPI server,
but nowadays it is best to set up a
for local testing.
When building applications,
is a great output format.
It allows a one-file install.
The future is bright --
pip 10 is slated to come out,
pyproject.toml format --
and hopefully the next post in the series will explain how to make
Jupyter for SRE
Jupyter is a tool that came out of the data science community. In science, being able to replicate experiments is of the utmost importance -- so a tool where you can "show your work" is helpful. However, being able to show your work -- have colleagues validate what you have done, repeat …read more
Write Python like an expert
Interesting text encodings (and the people who love them)
(Thanks to Tom Prince and Nelson Elhage for suggestions for improvement.)
Nowadays, almost all text will be encoded in UTF-8 -- for good reasons, it is a well thought out encoding. Some of it will be in Latin 1, AKA ISO-8859-1, which is popular in the western world. Less of it …read more
Exploration Driven Development
"It's ok to mess up your own room."
Sometime there is a problem where the design is obvious -- at least to you. Maybe it's simple. Maybe you've solved one like that many times. In those cases, just go ahead -- use Test-Driven-Development, lint your code as you're writing, and push a …read more
Brute Forcing AES
Thanks to Paul Kehrer for reviewing! Any mistakes or oversights that are left are my responsibility.
AES's maximum key size is 256 bits (there are also 128 and 192 bit versions available). Is that enough? Well, if there is a cryptographic flaw in AES (i.e., a way to recover …read more