On 3 August 2012 18:37, holger krekel <hol...@merlinux.eu> wrote: > On Thu, Aug 02, 2012 at 20:03 +0000, holger krekel wrote: >> On Thu, Aug 02, 2012 at 19:47 +0100, Floris Bruynooghe wrote: >> > On 2 August 2012 18:24, holger krekel <hol...@merlinux.eu> wrote: >> > > On Thu, Aug 02, 2012 at 13:50 +0100, Floris Bruynooghe wrote: >> > >> Would it not make sense to allow this (or at least provide a clearer >> > >> error)? I still like that form because of the grep-ability (doing a >> > >> 2-line grep is much harder and would still not cover ppl doing "from >> > >> pytest import factory" etc). >> > > >> > > Grepability is an argument. Would adding a "name=..." parameter for >> > > the factory-decorator help enough? Allowing and advertising >> > > pytest_funcarg__foo feels strange to somehow taking a fresh look i think. >> > >> > I would argue the opposite, allowing the @factory decroator on >> > pytest_funcarg__* seems like a more gentle progression giving more the >> > impression that it is simply funcargs evolved. To a newcomer it might >> > otherwise look like funcargs where not thought out fully yet and make >> > them think py.test just isn't stable enough yet. >> >> But when using the factory decorator on pytest_funcarg__ named functions, >> they shall at least not be able to receive "request" anymore, right? >> (The current implementation probably allows it but i feel uneasy about it).
Yes, I think the same logic applies as with decorating setup_module with @setup: it "consumes" the function and it's old meaning is gone. The only difference here is probably that it strips pytest_funcarg__ from the name. > One more thought: What will actually happen if you grep for "def > FUNCARGNAME" - does this not usually yield the location of your factory > and very few or no false positives? Yes, and easily spotted when using grep -B1. To be fair I don't think this is a major issue. We will still find our funcargs fine just as we find any other code. The old way was just super convenient and I think that is the only reason we're making a fuss. Regards, Floris _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
