[TIP] unittest2 and the future of nose

[Michael Foord]

On 04/03/2010 22:05, C. Titus Brown wrote:
> On Thu, Mar 04, 2010 at 04:41:06PM -0500, J. Cliff Dyer wrote:
>    
>> On Thu, 2010-03-04 at 15:51 -0500, jason pellerin wrote:
>>
>>      
>>> And, crucially, it must not depend on me writing 90% of the code and
>>> reviewing all of it. To succeed, nose2 needs to be a community project
>>> -- not *my* project.
>>>
>>> Which means it's not going to happen unless enough of you folks are
>>> interested and have time to commit.
>>>
>>> What do you think?
>>>        
>> I think the bulk of the effort should be put into unittest(2).  Nose
>> came up to begin with because unittest(1) didn't do what people needed.
>> I think the best scenario would be to have a unittest that obviates the
>> need for a new nose.  Second best would be to have the new nose be as
>> thin a layer above unittest as possible.
>>      
> Michael will presumably jump in here, and I don't want to speak for him, but
> here's my understanding:
>
> unittest2 is part of the stdlib for 2.7 and 3.2+, and it's called 'unittest'.
> unittest2 is available for those who want to use the newer features in older
> versions of Python.  But it's going to be part of the stdlib.
>    
Right.
> The problem has been, and always will be, that things in the stdlib don't
> move that fast.  So your favorite feature X (be it plugins, or whatnot)
> is not going to evolve and adapt once it becomes part of the stdlib.
>
> That may be OK, of course!
>
>    
Definitely true. However supporting extensiblity in unittest(2) is a 
high priority of mine (I need to finish some other stuff first though).

I may trial it in unittest2 before bringing it into the standard library 
- so it may miss Python 2.7. Not sure about that yet, but I don't think 
there is time for me to get this completed in time for the 2.7 beta 
deadline anyway. It is important to get it right though, because as 
Titus says once it is in the standard library it is basically impossible 
to change it in backwards incompatible ways.

When I do look at extensibility I will discuss it - it is very important 
that even if it isn't compatible with existing nose extensions it meets 
the usecases of the major extension so that they *can* be reimplemented 
for unittest2. Once unittest has useful extension points I'd like to 
reimplement as much of unittest itself as possible using these extension 
points (if it can be done without disrupting backwards compatibility) so 
that existing functionality can be replaced as well as extended. All 
still to be worked out of course.

Michael

> cheers,
> --titus
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.