closes #62

The fix looks good to me, but let's try to split formatting fixes from bug fixes (in different PRs preferably).

The fix looks good to me, but let's try to split formatting fixes from bug fixes (in different PRs preferably).

Agree, this was due to error in black and I didn't want the tests to fail.

I'm OK with the changes.
Sorry, I'm a bit late. Building a green house :-) 🏡

Hello, I'm coming back to this to note a couple of things:

@jschlyter I would like us to wait for all reviewers to give a thumbs up before merging. Ideally, one should not merge their own pull-requests, but somebody else that has reviewed the changes should do it.

Secondly, it is nice to name and give credit to people that provided the fix. While the things we do are in the open and for the community and credits do not actually matter, it still is polite to keep it in mind and gives a boost for motivation for the effort that went into the analysis of the issue and the fix. At the same time this forces us to have proper commit messages that mention what was happening and how it got fixed.

Thirdly, we are not done. This is a bug that is now breaking the library. This appeared after a dependency was upgraded. People using the current-latest version of this library will still get a breakage. We should make a new release so that users can upgrade and not get bitten by this.

@c00kiemon5ter I was not aware of a review threshold > 1, hence my merge when you had approved the changes. If the policy is to require all reviewers, I'm all fine with that.

Agree on the mention part, will keep that in mind.

And yes, we should do a new release.

Presently we have no review threshold >1. So far one is enough.
I agree with @jschlyter that if more then one reviewer is assigned all should accept the change before it can be merged.