Message183454
| 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:44 | pitrou | set | recipients:
+ 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:44 | pitrou | link | issue16997 messages |
| 2013年03月04日 14:01:44 | pitrou | create |
|