On 05/10/2013 08:30 AM, holger krekel wrote:
On Thu, May 09, 2013 at 17:17 +0200, Ronny Pfannschmidt wrote:
im -1 on the flag
Why? And wh is introducing a new "@fixturemanager" decorator which
duplicates the API better, in your oppinion?
while the same api, they have different behaviours,
im really not a fan of creating boolean flags to trigger behaviours,
i'd rather see a new api that allows more kinds of fixture
setups/teardowns/parametrizations to be implemented and implementing
the ones for function/contextmanager fixtures on top of that,
so that we get a more flexible base and clear separation of behaviour
Not sure what you are referring to here. API implementation layers
or exposed APIs?
Both actually,
i think we should have an api to implement fixture parametrization,
setup and teardown in a very flexible way (including parameter generators)
and the simple contextmanager/function convenience on top of that
however i think we should use a different api to register contextmanager
based fixtures and function result based fixtures
since for one the contract is
-> returns the set up object
and for the other the contract is
-> returns a context manager that uppon entering will create set up object
-- Ronny
Let's also see what Andreas and Bruno have to say on this api design topic.
cheers,
holger
-- Ronny
_______________________________________________
Pytest-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pytest-dev
