[issue2578] Figure out what to do with unittest's redundant APIs

[Guido van Rossum]

Guido van Rossum <guido at python.org> added the comment:

>  Steve Purcell <purcell at users.sourceforge.net> added the comment:
>  Hey, I'm open to anything.  If I started writing unittest from scratch
>  knowing what I know now, I'd probably have kept the API a little
>  slimmer.  Oh, and I'd have named everthing according to Python
>  conventions; my deepest and belated apologies for that.

I think the current consensus is to start trimming the API in 3.1. We
could start documenting best practices in 2.6 and 3.0 though.

>  I think the design has held up pretty well, even if it's arguably not
>  the most pythonic.  Its familiarity to users of other xUnit frameworks
>  really does help new Pythoneers start writing tests immediately.

Though I wonder how common that use case is. Not all new Pythoneers
come from Java, you know... Many come from Perl, PHP, even C++, and
more and more come from not programming at all before.

>  And as
>  for the TestLoader stuff, it looks (and perhaps is) a bit overblown, but
>  I can't count the number of times people have asked me how to do obscure
>  or unusual things with the module and I've been able to respond with
>  something like, "just write a custom TestLoader/TestRunner".

I hope we can add more custom TestLoader/TestRunner subclasses for
some of the *common* use cases.

>  I don't intend to take unittest in any particular direction; truth be
>  told, I'm now only an occasional visitor to the land of Python, and I
>  don't think I've had commit rights since the move to subversion.  My
>  continued involvement with the unittest tickets is mainly to help
>  provide input along the lines of "we discussed this years ago, and
>  decided against it / thought it would be great".  Far be it from me to
>  stand in the way of progress -- I'd be happy to see unittest re-worked
>  in any way that makes sense.

And thanks for your continued involvement! I think the clue the
developer community can take from this is not to worry too much about
changing the original design; you don't seem to have a strong sense of
"ownership", which (in this case) sounds good to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2578>
__________________________________