osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files


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