[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:42:28 CEST 2008
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ben Finney <ben+python at benfinney.id.au> writes:
You're proposing to give "assertRaises" a new meaning, without changing its name to "assertRaisesAndReturnExceptionIfRaises".
This might be misunderstood, so I'll make it clearer.
The name "assert raises" has a strong (and, per Guido, deliberate) association with the existing 'assert' statement. So the name makes a strong promise of what the function will do: raise an exception if the condition is false, and have no effect otherwise.
If the behaviour desired is, instead, to return a value, then that is an important part of what the function will do and needs to be reflected in the name. "catch exception" was one suggestion for a name, another might be "get exception raised".
If the idea is to have a single function that does both disparate things, then the name should definitely state that. That it would result in an overly long name is a strong indicator that the function is doing too much and should be split.
The result I'm trying to avoid by this is that of having the externally visible behaviour of functions drift from the promise made by their names. Either rename the function, or create a new one for the new functionality.
-- \ “Consider the daffodil. And while you're doing that, I'll be | `\ over here, looking through your stuff.” —Jack Handey | o_) | Ben Finney
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]