On Thu, Jun 28, 2012 at 13:08 +0100, Floris Bruynooghe wrote: > On 28 June 2012 09:15, holger krekel <hol...@merlinux.eu> wrote: > > /me does "import this" and sees: Although practicality beats purity ... > > > > I am still fine to consider e. g. the introduction of a pytest.current > > namespace. It could lead to make setup_X methods more powerful:: > > I think it would be nice to make setup_X methods more powerful by > giving them access to resources, but it's not a deal breaker. And I'm > not a fan of pytest.current either for the same reasons you don't like > it. > > But you didn't explain why inspecting the arguments like is done for > the hooks is not viable? To me that would seem like a neat solution. > And I'm tempted to say not to bother if the only alternative is to use > someting pytest.current-like. It's certainly no regression.
It is in some sense logical to extend the funcarg-idea to setup-methods. I used to think that the scoping is a problem, but given the new node.register_factory/getresource() API it could be done somewhat sanely. It will remain a bit of a heuristic approach, though, because setup_module/class/method have traditionally not required exact names - for example, some people wrongly use: def setup_class(self): self.xyz = ... Of course this works. And I guess we could start funcarg/resource-requesting based on all previously not possible arguments. So def setup_class(xyz, tmpdir): xyz.tmpdir = tmpdir would work because the first argument does not take part in discovery. The tmpdir argument would lead to a classnode.getresource("tmpdir") call. It wouldn't matter if tmpdir is created through a pytest_funcarg__tmpdir or a register_factory() function. Do you like this? > > import pytest > > def setup_module(): # pytest accepts it to keep nose compat > > db = pytest.current.modulenode.getresource("db") > > > > The "current" namespace could be set by the respective node setup > > methods. For classes it's the same idea:: > > > > class TestClass: > > def setup_class(cls): > > cls.db = pytest.current.classnode.getresource("db") > > > > Due to the non-declarative nature of this approach, however, i don't > > see a way to rerun the testclass with multiple "db" instances. > > I don't see how all other uses don't have these issues: > > def pytest_funcarg__foo(item): > item.getresource('db') > > or > > def factory_foo(name, node): > pass > def facotry_bar(name, node): > node.getresource('foo') > .register_resource_factory('foo', factory_foo) > .register_resource_factory('bar', factory_bar) > > Don't these suffer the same problem? Or am I missing someting. The latter would work:: node.register_factory("foo", [fac1, fac2]) this makes it clear that there are two "foo" parameter values. best, holger > Regards, > Floris > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev