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 zach.ware
Recipients ezio.melotti, michael.foord, pitrou, r.david.murray, rbcollins, serhiy.storchaka, terry.reedy, zach.ware
Date 2013-08-08.02:14:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1375928076.45.0.919599109598.issue18526@psf.upfronthosting.co.za>
In-reply-to
Content
(Apologies for the delay in replies, my available time evaporated without notice...)

Antoine Pitrou wrote:
> Does registerResource() mutate some kind of global per-process state? This
> doesn't sound like a good idea.

It's not the greatest of ideas, no; but I hadn't come up with a better one
yet :).  Robert's review has given me a couple ideas to try to avoid this,
though.

> (and even less so the "default resources", IMO: these are stdlib test
> suite-specific)

That is true, though I attempted to pick out some of the ones used by our test
suite that are most likely to be applicable elsewhere.  I had a couple misses,
though, and I'm not against removing the defaults entirely.

---

Michael Foord wrote:
> My question is, is this generally useful enough for test suites beyond the
> Python standard library. Essentially it provides a command line interface to
> specialized test skipping.

To be honest, I'm not sure.  Theoretically, I can think of several situations
where it would be useful, but I have no concrete examples aside from the Pytohn
test suite.

> I *still* feel that a generalized mechanism for adding command line options to
> the standard test runner would allow for this and a myriad of other slightly
> specialized use cases. It's hard to see how to do that cleanly without full
> blown extension machinery (which I'm in favour of and have prototyped but it
> is a *much* bigger change set)

Is your prototype available anywhere for me to get a better idea what you mean?
That could indeed be a much better approach if it is what I think it is.

---

Robert Collins wrote:
> I'll do a full review shortly, but at the conceptual level, I don't see any
> benefit in making a new SkipTest base class, other than instantly breaking
> other runners when an unknown exception is raised. SkipTest is part of the
> API. Making a new exception part of the API requires a strong reason - not
> just 'we want to show it differently' but 'we want the runner to behave
> differently.

Actually, the real reason I created the new _BaseSkip exception was to avoid an
import loop between resources.py and case.py.  I think I was trying to keep
SkipTest defined in case.py, but in retrospect it is much saner to just move
it to util.py and import from there in both other modules, and directly subclass
SkipTest for the new Resource exceptions.  I'll respond to your review on 
Rietveld and with a new patch, as time allows (hopefully before the next alpha).

---

Thanks to all three of you for your comments :)
History
Date User Action Args
2013-08-08 02:14:36zach.waresetrecipients: + zach.ware, terry.reedy, pitrou, rbcollins, ezio.melotti, r.david.murray, michael.foord, serhiy.storchaka
2013-08-08 02:14:36zach.waresetmessageid: <1375928076.45.0.919599109598.issue18526@psf.upfronthosting.co.za>
2013-08-08 02:14:36zach.warelinkissue18526 messages
2013-08-08 02:14:35zach.warecreate