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