On Sat, Oct 06, 2012 at 01:08 +0100, Floris Bruynooghe wrote: > On 6 October 2012 00:02, holger krekel <hol...@merlinux.eu> wrote: > > Hi Floris, > > > > On Fri, Oct 05, 2012 at 23:42 +0100, Floris Bruynooghe wrote: > >> Hi Holger, > >> > >> One nice feature of the funcarg/setup merge into fixture is that you > >> can now return a value from an autoactive fixture and request it > >> anywhere else. I didn't think of this before but this is surprisingly > >> useful as it provides a great alternative to storing things on e.g. > >> session or item objects. > > > > Yes, i think so too. > > > >> However one issue I discovered is that is possible for a user to > >> accidentally override an autoactive fixture. If you create a fixture > >> with an identical name to the autoactive one it will be lost. I think > >> this can be problematical for plugins. > > > > Hum, indeed, we have a global namespace for fixtures and unintentionally > > shadowing plugin from project specific fixtures is easy. > > > >> What do you think the correct behaviour should be? I realise changing > >> this could be hard/ugly. > > > > Not sure it's hard. first we need an idea what to do :) > > > > Hum. We could error out on the definition of fixtures if they already exist > > - > > unless a flag aka "i know what i am doing" (e.g. override=True) is supplied. > > That would not be as nice in the normal case. I do tend to extend > funcargs quite a lot in my test suites. Although I guess it's not a > horrible thing, it would have to default to override=True when using > the backwards compatible pytest_funcarg__ syntax which then kind of > defeats the point. > > Or are you proposing to only need this for overriding autoactive fixtures?
Not proposing anything yet, just thinking. For extending, do you usually refer to the shadowed fixture by listing it as a function argument? Maybe time to continue discussing on IRC :) holger _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
