• Paul Tol’s notes, which gives special consideration to color-blindness. He has some visual demonstrations that picked up my own slight color-blindness.
• Cynthia Brewer’s ColorBrewer, with interactive elements so you can create your own palette for your particular needs.

Color Palette Ideas is different: palettes based on photographs, but can also be a good source for ideas.

As an update to my ancient blog post about this same topic, Adobe Color and paletton both have tools for generating palettes in lots of over-my-head ways. And Color Synth Axis is still very appealing to the geek in me, though it needs Flash, and so I fear is not long for this world...

The user’s code used mocks to simulate an OSError when trying to make temporary files (source):

with patch('tempfile._TemporaryFileWrapper') as mock_ntf:
    mock_ntf.side_effect = OSError()


Inside tempfile.NamedTemporaryFile, the error handling misses the possibility that _TemporaryFileWrapper will fail (source):

(fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
try:
    file = _io.open(fd, mode, buffering=buffering,
                    newline=newline, encoding=encoding, errors=errors)

    return _TemporaryFileWrapper(file, name, delete)
except BaseException:
    _os.unlink(name)
    _os.close(fd)
    raise


If _TemporaryFileWrapper fails, the file descriptor fd is closed, but the file object referencing it still exists. Eventually, it will be garbage collected, and the file descriptor it references will be closed again.

But file descriptors are just small integers which will be reused. The failure in bug 915 is that the file descriptor did get reused, by SQLite. When the garbage collector eventually reclaimed the file object leaked by NamedTemporaryFile, it closed a file descriptor that SQLite was using. Boom.

There are two improvements to be made here. First, the user code should be mocking public functions, not internal details of the Python stdlib. In fact, the variable is already named mock_ntf as if it had been a mock of NamedTemporaryFile at some point.

NamedTemporaryFile would be a better mock because that is the function being used by the user’s code. Mocking _TemporaryFileWrapper is relying on an internal detail of the standard library.

The other improvement is to close the leak in NamedTemporaryFile. That request is now bpo39318. As it happens, the leak had also been reported as bpo21058 and bpo26385.

Lessons learned:

• Hacker News can be helpful, in spite of the tangents about shell redirection, authorship attribution, and GitHub monoculture.
• There are always people more skilled at debugging. I had no idea you could script gdb.
• Error handling is hard to get right. Edge cases can be really subtle. Bugs can linger for years.

I named Robert Xiao at the top, but lots of people chipped in effort to help get to the bottom of this. ikanobori posted it to Hacker News in the first place. Chris Caron reported the original #915 and stuck with the process as it dragged on. Thanks everybody.

I just released coverage.py 5.0.3, with two bug fixes. There was another bug I really wanted to fix, but it has stumped me. I’m hoping someone can figure it out.

Bug #915 describes a disk I/O failure. Thanks to some help from Travis support, Chris Caron has provided instructions for reproducing it in Docker, and they work: I can generate disk I/O errors at will. What I can’t figure out is what coverage.py is doing wrong that causes the errors.

To reproduce it, start a Travis-based docker image:

cid=$(docker run -dti --privileged=true --entrypoint=/sbin/init \
    -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
    travisci/ci-sardonyx:packer-1542104228-d128723)
docker exec -it $cid /bin/bash


Then in the container, run these commands:

su - travis
git clone --branch=nedbat/debug-915 https://github.com/nedbat/apprise-api.git
cd apprise-api
source ~/virtualenv/python3.6/bin/activate
pip install tox
tox -e bad,good


This will run two tox environments, called good and bad. Bad will fail with a disk I/O error, good will succeed. The difference is that bad uses the pytest-cov plugin, good does not. Two detailed debug logs will be created: debug-good.txt and debug-bad.txt. They show what operations were executed in the SqliteDb class in coverage.py.

The Big Questions: Why does bad fail? What is it doing at the SQLite level that causes the failure? And most importantly, what can I change in coverage.py to prevent the failure?

Some observations and questions:

• If I change the last line of the steps to “tox -e good,bad” (that is, run the environments in the other order) then the error doesn’t happen. I don’t understand why that would make a difference.
• I’ve tried adding time.sleep’s to try to slow the pace of database access, but maybe in not enough places? And if this fixes it, what’s the right way to productize that change?
• I’ve tried using the detailed debug log to create a small Python program that in theory accesses the SQLite database in exactly the same way, but I haven’t managed to create the error that way. What aspect of access am I overlooking?

If you come up with answers to any of these questions, I will reward you somehow. I am also eager to chat if that would help you solve the mysteries. I can be reached on email, Twitter, as nedbat on IRC, or in Slack. Please get in touch if you have any ideas. Thanks.

While working on an issue with coverage.py 5.0, I came up with a way to show commands and their output that I think works well.

I used GitHub’s <details> support to show the commands I ran with their output in collapsible sections. I like the way it came out: you can copy all the commands, or open a section to see what happened for the command you’re interested in.

The raw markdown looks like this:

<details>
<summary>cd meltano</summary>
</details>

<details>
<summary>pip install '.[dev]'</summary>

```
Processing /private/tmp/bug881a/meltano
Collecting aenum==2.1.2
  Using cached https://files.pythonhosted.org/packages/0d/46/5b6a6c13fee40f9dfaba84de1394bfe082c0c7d95952ba0ffbd56ce3a3f7/aenum-2.1.2-py3-none-any.whl
Collecting idna==2.7
  Using cached https://files.pythonhosted.org/packages/4b/2a/0276479a4b3caeb8a8c1af2f8e4355746a97fab05a372e4a2c6a6b876165/idna-2.7-py2.py3-none-any.whl
Collecting asn1crypto==0.24.0
  Using cached https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e0a7ad7bd8ab5ed7cdc600ef7cd06222/asn1crypto-0.24.0-py2.py3-none-any.whl
(etc)
```

</details>


(The GitHub renderer was very particular about the blank lines around the <details> and <summary> tags, so be sure to include them if you try this.)

Other people have done this: after I wrote this comment, one of the newer coverage.py issues used the same technique, but with <tt> in the summaries to make them look like commands, nice. There are a few manual steps to get that result, but I’ll be refining how to produce that style more conveniently from a terminal console.

But I knew nothing about these tests. I didn’t know what subset might be useful, or even what subsets there were, so I had to try random subsets and hope for the best.

I selected random subsets with a new trick: I used the -k option (select tests by a substring of their names) using single consonants. “pytest -k b” will run only the tests with a b in their name, for example. Then I tried “-k c”, “-k d”, “-k f”, and so on. Some will run the whole test suite (“-k t” is useless because t is in every test name), but some ran usefully small collections.

This is a mindless way to select tests, but I knew nothing about this test suite, so it was a quick way to run fewer than all of them. Running “-k q” was the best (only 16 tests). Then I looked at the test names, and selected yet smaller subsets with more thought. In the end, I could reduce it to just one test that demonstrated the problem.

I’ve been through this before, so I knew what would happen: people with unpinned requirements would invisibly upgrade their coverage version, and stuff would break. Coverage.py is used by many projects, so it was inevitable.

Saturday afternoon was quiet. Sunday I heard from two people. Then Monday, people came back to work to find their continuous integration broken, and now I’m up to 11 issues to deal with.

It remains difficult to get people to provide instructions that are specific enough and detailed enough for me to see their problem. A link to your broken CI build doesn’t tell me how to do it myself. A link to your repo is confusing if you then add a commit that pins the old version of coverage to prevent the problem, forcing me to dig through your history to try to find the old commit that was broken. And so on.

Of course, this is nothing new, but it drove home again how hard it is to extract good information from distracted and annoyed users. If anyone has good examples of issue templates that get people’s attention and guide them well, point me to them!

While dealing with the issues, I came up with two new techniques, interesting enough to deserve their own blog posts:

• Fancy console output in GitHub comments
• Pytest trick: subsetting unknown suites

Needless to say, fixes are underway for a coverage.py 5.0.1 to be released soon.

Everything I said in the beta 1 announcement still holds: please try the new things!

Thanks.

I love this drawing! I’ve always been charmed by cartoonists’ ability to capture an essence in a seemingly simple drawing. Objects are reduced to stereotypes, but with some whimsy thrown in. Ben has always had this gift: to create just the right stroke to perfectly express an attitude or feeling.

Here Sleepy is snug in his bed, covered by a blanket. Even in his custom bed, he’s too long to fit, but he’s comfortable. The pillow isn’t shaped like a real pillow, but it’s exactly our cartoon Platonic ideal of a pillow.

When I first thought of getting a mascot, I wanted it to be a snake in bed, because of the literal meaning of “coverage.” But I threw the question out to Twitter to see what came up:

Looking for ideas of what a logo for coverage․py could look like. No idea is too crazy! Please RT

— Ned Batchelder (@nedbat) October 22, 2019

I got a lot of good ideas, including blanket/quilt/duvet, and a nice quick sketch of a snake holding an umbrella.

Ben liked the idea of the umbrella, so when he started sketching ideas, he started with snakes with umbrellas:

But I really wanted to see bed ideas, so he drew a snake in bed. He said snakes are usually curved, so the bed should be curved. His cartoonist’s instinct was at work:

I said, “Hmm, flip it around, and it will look like a C for coverage.” Now he was starting to warm to the idea:

Then he switched to digital media to produce a “real” drawing of the idea:

Now all the elements were there, and it was clear that this was a winner. I suggested making the sleeping cap a little more separate from the body, Ben added detail and colors, and Sleepy was done:

I can see using this picture with a slogan underneath: “Coverage.py: rest easy.”

I’ve long used Ben’s work where I can, in my presentations. The illustrations are always a fun aspect of what otherwise might be a visually monotonous slide deck:

• The ouroboros on the title slide of Python-Aware Python,
• Illustrations of developer attitudes in Getting Started Testing,
• The jellybean-counting elves in Big-O: How Code Slows as Data Grows.

Ben will be graduating soon, and setting out as a freelancer. I couldn’t be more proud of his talent. He has an Instagram and a portfolio site.

To help with that, I wanted to make a chart of the support windows for different versions of each dependency. I figured the simplest way to draw a chart like that was to make a spreadsheet. Google Sheets is enough for something like this, and makes it easy to share the result with others who need to refer to it.

To create the spreadsheet programmatically, I used the JavaScript scripting support. My program went through a few other iterations before landing on this technique, so it’s in kind of a strange form now: it’s a Python program that writes JavaScript, which you then paste into a spreadsheet and run.

It makes a nice result, the Support Windows spreadsheet:

The tree-named things at the top of the chart are the Open edX releases. Mostly the chart is used to reason about when we need to upgrade the dependencies in order for Open edX releases to stay on supported versions. The bolder rectangles are the currently used versions.

The program is here: barcalendar.py. It’s all in one file, though at least the code is organized from general to specific: first color utilities, then a generic BaseCalendar class, then a GsheetCalendar class, then the code specific to our software to draw the chart.

When I thought about writing this blog post, I wanted to clean up the program first. Split it into multiple files, refactor the version logic to make some utilities, and so on. It was easy to imagine making the code more re-usable, more of a library. But I resisted letting the perfect be the enemy of the good. This program is useful to us, it might be useful to others. Why not share it now?

The hack of writing JavaScript code to be pasted into a spreadsheet feels slightly embarrassing: shouldn’t I at least be able to use the Gsheet API from Python to do the work?

But using the Gsheet API would mean struggling with authentication, which always seems to be difficult, and I can neatly sidestep by copying and pasting JavaScript. Not to mention, refactoring is easier this way because I can save the JavaScript output and check that the refactored code didn’t change it.

So in some ways, this is a low-tech implementation of the functional programming idea that you should separate I/O from computation. My barcalendar.py does the computation, generating a JavaScript “display list”. Then Google Sheets does the “I/O” when I run the JavaScript in the spreadsheet. Nice: I’m not an authentication-avoiding chump, I’m an insightful functional programmer!

This kind of separation is sometimes called “clean architecture.” Brandon Rhodes has a detailed talk about Clean Architecture in Python.

So enjoy barcalendar.py despite its flaws (or because of its genius). It’s working well for us. If you improve it or use it, let me know.