Author pitrou
Recipients Arfrever, Julian, abingham, bfroehle, borja.ruiz, chris.jerdonek, eric.araujo, eric.snow, exarkun, ezio.melotti, flox, fperez, hpk, michael.foord, nchauvat, ncoghlan, pitrou, r.david.murray, santoso.wijaya, serhiy.storchaka, spiv, terry.reedy
Date 2013-03-04.14:01:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1843927953.9671365.1362405697443.JavaMail.root@zimbra10-e2.priv.proxad.net>
In-reply-to <1362404362.76.0.0564223555919.issue16997@psf.upfronthosting.co.za>
Content
> However, I'm wondering if it might still be possible to avoid the
> need for a thread local context to handle the combination of
> expected failures and subtests when we have access to the test
> caseby adding the annotation that I expected to be there in the
> first place.

But that would break use cases where you use @expectedFailure on a
function called by the test method, not directly on the test method
itself. I don't really care about those use cases myself, but not
breaking them is the reason I chose not to change the @expectedFailure
implementation. I'll let Michael decide :-)
History
Date User Action Args
2013-03-04 14:01:44pitrousetrecipients: + pitrou, terry.reedy, spiv, exarkun, ncoghlan, ezio.melotti, eric.araujo, Arfrever, r.david.murray, michael.foord, hpk, flox, fperez, chris.jerdonek, santoso.wijaya, nchauvat, Julian, abingham, eric.snow, serhiy.storchaka, borja.ruiz, bfroehle
2013-03-04 14:01:44pitroulinkissue16997 messages
2013-03-04 14:01:44pitroucreate