[Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files
Chris Withers
chris at withers.org
Wed May 1 09:30:01 EDT 2019
On 01/05/2019 14:22, Paul Moore wrote:
>> If people are actually using these blocks, then so be it, but it feels
>> like the people who want them to stick around are saying they're using
>> them just on the off chance they might use them, which feels like a poor
>> reason to keep a bunch of dead code around.
>
> If your argument was "this is dead code, and should be removed to help
> future maintenance", I'd have no problem with that.
Yep, that's exactly my point :-)
The dev guide shows how to run individual tests without these and
doesn't mention them at all. As someone coming back to core dev late
last year, I was left wondering whether I *should* be using them and
that created confusion for me; having only one way to do things seems
like a good thing here.
> My point was
> simply that I think that adjusting the code to make the coverage stats
> hit 100% feels like going at things the wrong way round.
Agreed, but my focus here is to get to 100% for mock so that it's clear
that all the code is there for a reason; mock is very complicated by
necessity, and having examples of why code needs to be there is what I'm
aiming for most of all.
> Is it really that difficult to simply tell coverage to ignore them? I
> thought someone had already pointed to a coveragerc file that let you
> do this.
It would be if the cpython repo had a coveragerc, but it does not.
People maintaining their own ad-hoc coverage configs seems like a pretty
bad idea.
> Personally, I don't use those blocks at all, so it doesn't matter to
> me whether they stay or go in any practical sense.
Right, that's by gut feeling here: I don't want people encountering this
mock codebase to have to wonder whether they should be running the tests
using these blocks versus the way described in the dev guide, and
stressing about what the differences might be, when there aren't any...
Chris
More information about the Python-Dev
mailing list