[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) (original) (raw)
Ben Finney ben+python at benfinney.id.au
Thu Jul 17 00:49:13 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 ]
"Guido van Rossum" <guido at python.org> writes:
Having skimmed much material about proposed changes to the venerable unitest module, I'd like to set some boundaries. PEPs that don't follow the following rules are very unlikely to be accepted.
Thanks for giving the attention to this topic and producing a pronouncement.
1. The API is not going to be renamed to PEP-8 conformance. [...]
3. I like assertEqual better than failUnlessEqual (and similar for all assert* versions in favor of their fail* alias), and I don't like that there is both assertEqual and assertEquals. But rule #1 means we have to live with the aliases. At best we can discourage the undesirables by documenting them out of existence.
These two together kill any interest I have in being PEP champion for unittest changes, or on putting effort into the changes.
Thanks, everyone, for the lively discussion.
-- \ “The way to build large Python applications is to componentize | `\ and loosely-couple the hell out of everything.” —Aahz | 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 ]