<div dir="ltr">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.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Dec 04, 2013 at 13:29 +1100, Brianna Laugher wrote:<br>
> On 3 December 2013 18:39, holger krekel <<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>> wrote:<br>
> > Right, it seems that when we introduced @pytest.fixture we decided you can<br>
> > either use the prefix or the marker.  That could be lifted but i wonder<br>
> > if we should rather go for a different convention because pytest_funcarg__<br>
> > is not a beautiful prefix.  What do you think of pytest stripping the "__" prefix?<br>
> ><br>
> >     @pytest.fixture<br>
> >     def __foo2(monkeypatch):<br>
> >        return monkeypatch<br>
> ><br>
> > This fixture would become accessible via the "foo2" name.  Using "__foo2"<br>
> > would yield a lookup error and the error would indicate there is a "foo2"<br>
> > available.  If you don't like it, any other suggestions?<br>
><br>
> Hmm. My main concern here would be that fixture definitions are easily<br>
> 'findable' in a global search. The fixture decorator is easy to search<br>
> for, as is 'pytest_funcarg__'. Such an ugly prefix is also far easier<br>
> to google. Double underscore, not so much. The ugly prefix is also<br>
> good for backwards compat.<br>
><br>
> So, I don't really mind what happens as long as each fixture has at<br>
> least one of fixture decorator/ugly prefix.<br>
<br>
</div>Well, ok.  Pending further input, i made pytest accept pytest.fixture<br>
decorated pytest_funcarg__ prefixed functions, see<br>
<a href="https://bitbucket.org/hpk42/pytest/commits/aa1f0505a3156b9feca43cd67c5afc95622b9ac5" target="_blank">https://bitbucket.org/hpk42/pytest/commits/aa1f0505a3156b9feca43cd67c5afc95622b9ac5</a><br>
<br>
I am a bit unhappy because apart from the pylint warning it's also a<br>
real issue for beginners to write something like this::<br>
<br>
    @pytest.fixture<br>
    def somename():<br>
        return 42<br>
<br>
    def test_something():<br>
        assert somename == 42<br>
<br>
The "somename" is accessible (as a global) but is a function object.<br>
The resulting error message is irritating if you are not proficient in python.<br>
To prevent this irritation we would need to recommend a different<br>
default way of declaring the fixture and neither pytest_funcarg__NAME nor<br>
__NAME sound like we would like to suggest this as the main way in the docs.<br>
<br>
Then again, my general recommendation is to put fixture functions into<br>
conftest.py files and you then get a clean "NameError" in a test module<br>
for the above example.  The docs use the "everything contained in test module"<br>
method, though, to make it easier to present getting-started examples.<br>
Maybe it makes sense to mention this recommended conftest/test module<br>
split earlier on.<br>
<br>
best,<br>
holger<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Pytest-dev mailing list<br>
<a href="mailto:Pytest-dev@python.org">Pytest-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pytest-dev" target="_blank">https://mail.python.org/mailman/listinfo/pytest-dev</a><br>
</div></div></blockquote></div><br></div>