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 | |