This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
In-reply-to <>
> 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 :-)
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