Hi, On 4 December 2013 15:05, lahwran <[email protected]> wrote: > perhaps pytest.fixture could return a special object that rejects all > operations, rather than the decorated function object; such that `theobject > == 5` would produce a big flashy error in theobject.__eq__ indicating you > need to actually use the fixture for this to work, maybe even with an > example. Repeat for all magic methods that make sense. this object would > maybe have a _pytest_fixture attribute, or conform to whatever protocol > already exists for detecting fixture objects, such that the only thing you > could do with such an object is check if it's a fixture and get the original > function object from somewhere inside it. Any other operation would result > in a flashy error.
This seems like a quite nice idea to me. > On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <[email protected]> wrote: >> Well, ok. Pending further input, i made pytest accept pytest.fixture >> decorated pytest_funcarg__ prefixed functions, see >> >> https://bitbucket.org/hpk42/pytest/commits/aa1f0505a3156b9feca43cd67c5afc95622b9ac5 I don't really like this change. IIRC this was considered when the decorator was introduced and the reason it was not allowed originally is because the signature is different between the different ways of defining fixtures. That can be very confusing too. My first reaction on this pylint issue was to see if this can not be fixed wit a pylint plugin. And I still think this would be nicer then the other proposals of trying to figure out how to name fixtures differently. The way of declaring fixtures right now is very nice and readable. Especially if lahwran's suggestion is implemented as that would make any mistakes obvious (and to an experience python developer they already are obvious). >> Then again, my general recommendation is to put fixture functions into >> conftest.py files and you then get a clean "NameError" in a test module >> for the above example. The docs use the "everything contained in test >> module" >> method, though, to make it easier to present getting-started examples. >> Maybe it makes sense to mention this recommended conftest/test module >> split earlier on. Personally I tend to recommend people to declare their fixtures as close to the code using it. So if a fixture is only used in one class declare it in that class. I find it easier to manage which fixtures are needed and know about the relevant ones without having to search around. Also if you have all test modules in package, like py.test, you quickly end up with colliding fixture names and a giant and hard to manage collection of fixtures in conftest.py. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ Pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
