[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) (original) (raw)

Ben Finney ben+python at benfinney.id.au
Thu Jul 17 04🔞26 CEST 2008

Andrew Bennetts <andrew-pythondev at puzzling.org> writes:

Ben Finney wrote: > Andrew Bennetts <andrew-pythondev at puzzling.org> writes: [...] > > How is returning None a feature? > > A test method having exactly one meaning is a feature. If it's > consistent across the API, the API retains a level of simplicity.

Your reply makes no sense to me. I am proposing that it should have exactly one meaning.

You're proposing to give "assertRaises" a new meaning, without changing its name to "assertRaisesAndReturnExceptionIfRaises".

The function name should say all that the function does, from the perspective of the caller. If you're proposing to have the function do extra things that aren't part of what the name says it will do, then that deserves either a rename or a new function.

It seems you have a different meaning of “meaning” than I do, which suggests that this conversation is doomed. I hope I don't sound hostile, I'm just bewildered. Your argument isn't making any sense to me.

I hope that clarifies it. The name of a thing, in Python especially, is very important; in an API, even more so. If the behaviour of the function isn't matched by the name, it's a poorly chosen name, a poorly designed function, or both.

I can of course keep using TestCase subclasses that override assertRaises to be more useful.

Why would you override that function to do something not described by the name, instead of simply adding a new method that performs this extra task you want performed?

-- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but isn't a cucumber that small called a gherkin?” | o) —_Pinky and The Brain | Ben Finney

More information about the Python-Dev mailing list