Can you provide some examples of what you mean? Just for illustration purposes, not actual an api proposal.
On Fri, May 10, 2013 at 4:06 AM, Ronny Pfannschmidt < [email protected]> wrote: > > > 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<http://mail.python.org/mailman/listinfo/pytest-dev> >
_______________________________________________ Pytest-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pytest-dev
