chore: cleanup flake8

[henryiii]

This cleans up some flake8 things.

[jpivarski]

We're getting ready to split the Uproot repo into main, which will swap Awkward 1 for Awkward 2, and main-v4, which will be for bug-fixes to Uproot 4 (starting with 4.3.0). It's hard to maintain two branches, so I'd like to close old pull requests. Is there any part of this that you'd like to see merged into main and main-v4 or just main?

Note: this was never merged or reviewed because it was a draft. I assumed that you were still planning on adding to it, though it's been dormant for a while. If you want, we can apply it to main before the split, so that this, as it is, will apply to both Uproot 4 bug-fixes and Uproot 5.

[jpivarski]

The failing test is the one with ROOT. One of the changes in main makes tests of ROOT behavior less strict, since the way that they handle TStreamerInfo when updating a file has apparently changed.

[henryiii]

I marked it with draft because I need to solve the == None / is None problem (which is a PyROOT Python antipattern). Then I forgot about it. I can see if it can be revived.

[jpivarski]

Since it's isolated, just a few places in the codebase and all of them in tests, I think the "# noqa: E711 (ROOT null check)" comments are acceptable. They're noisy and really call attention to the fact that this is not the normal way of doing things.

Even if ROOT changes, there are versions of ROOT out there that require == None. I suppose we could require a very recent version of ROOT for the tests, though I'd rather not if it's just for this. I'd be more inclined to find another way of writing the tests! (These tests require the non-existence of a LeafCount... Maybe there's a way to do it, other than the null-pointer check.)

[henryiii]

Could it be assert not nb2.GetLeaf("nb2").GetLeafCount()? That would also trigger if GetLeafCount returned 0, is that a possibility to worry about?

[jpivarski]

Could it be assert not nb2.GetLeaf("nb2").GetLeafCount()? That would also trigger if GetLeafCount returned 0, is that a possibility to worry about?

The return value of TLeaf::GetLeafCount is typed (TLeaf*), so only checking to see if it's "falsy" would be enough.

It's a nice way out. I tend to avoid relying on truthy and falsy tests, but my reasons are undermined by cases that have a checked type.