From brianna.laugher at gmail.com  Tue Dec  3 04:51:09 2013
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Tue, 3 Dec 2013 14:51:09 +1100
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <20131126075840.GJ11363@merlinux.eu>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
Message-ID: <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>

Hi,

On 26 November 2013 18:58, holger krekel <holger at merlinux.eu> wrote:
> I use flakes and pep8 (pytest-flakes and pytest-pep8) and don't get this
> error.  What you can immediately do but which is not pretty is to use
> the old naming scheme together with a decorator:
>
>     import pytest
>
>     @pytest.fixture
>     def pytest_funcarg__somefixture(...):
>         ...
>
> This should avoid the pylint warning.

Ah, that's cool - I didn't realise that was possible.

However, it doesn't work the way you describe. :) Not sure if your
description or the code is backwards!

At the moment (pytest-2.3.5) if I have two fixtures like this:


@py.test.fixture
def pytest_funcarg__foo2(monkeypatch):
    return monkeypatch


def pytest_funcarg__foo3(monkeypatch):
    return monkeypatch


foo3 works (!). foo2 causes an assertion error on collection.

The code in parsefactories has a couple of if blocks, maybe one is inverted. :)

Don't know if this is a good idea, but you could tell if it was new
style/old style based on if the parameter was 'request' or
nothing/other fixtures.

cheers
Brianna


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

From holger at merlinux.eu  Tue Dec  3 08:39:19 2013
From: holger at merlinux.eu (holger krekel)
Date: Tue, 3 Dec 2013 07:39:19 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
Message-ID: <20131203073919.GQ32207@merlinux.eu>

On Tue, Dec 03, 2013 at 14:51 +1100, Brianna Laugher wrote:
> On 26 November 2013 18:58, holger krekel <holger at merlinux.eu> wrote:
> > I use flakes and pep8 (pytest-flakes and pytest-pep8) and don't get this
> > error.  What you can immediately do but which is not pretty is to use
> > the old naming scheme together with a decorator:
> >
> >     import pytest
> >
> >     @pytest.fixture
> >     def pytest_funcarg__somefixture(...):
> >         ...
> >
> > This should avoid the pylint warning.
> 
> Ah, that's cool - I didn't realise that was possible.
> 
> However, it doesn't work the way you describe. :) Not sure if your
> description or the code is backwards!
> 
> At the moment (pytest-2.3.5) if I have two fixtures like this:
> 
> @py.test.fixture
> def pytest_funcarg__foo2(monkeypatch):
>     return monkeypatch
> 
> 
> def pytest_funcarg__foo3(monkeypatch):
>     return monkeypatch
> 
> 
> foo3 works (!). foo2 causes an assertion error on collection.
> 
> The code in parsefactories has a couple of if blocks, maybe one is inverted. :)

Right, it seems that when we introduced @pytest.fixture we decided you can
either use the prefix or the marker.  That could be lifted but i wonder
if we should rather go for a different convention because pytest_funcarg__
is not a beautiful prefix.  What do you think of pytest stripping the "__" prefix?

    @pytest.fixture
    def __foo2(monkeypatch):
       return monkeypatch

This fixture would become accessible via the "foo2" name.  Using "__foo2"
would yield a lookup error and the error would indicate there is a "foo2"
available.  If you don't like it, any other suggestions?

> Don't know if this is a good idea, but you could tell if it was new
> style/old style based on if the parameter was 'request' or
> nothing/other fixtures.

There is no difference between old-style and @pytest.fixture(scope="function")
and the presence of "request" indicates nothing particular.

best,
holger

> cheers
> Brianna
> 
> 
> -- 
> They've just been waiting in a mountain for the right moment:
> http://modernthings.org/
> 

From brianna.laugher at gmail.com  Wed Dec  4 03:29:10 2013
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Wed, 4 Dec 2013 13:29:10 +1100
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <20131203073919.GQ32207@merlinux.eu>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
Message-ID: <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>

On 3 December 2013 18:39, holger krekel <holger at merlinux.eu> wrote:
> Right, it seems that when we introduced @pytest.fixture we decided you can
> either use the prefix or the marker.  That could be lifted but i wonder
> if we should rather go for a different convention because pytest_funcarg__
> is not a beautiful prefix.  What do you think of pytest stripping the "__" prefix?
>
>     @pytest.fixture
>     def __foo2(monkeypatch):
>        return monkeypatch
>
> This fixture would become accessible via the "foo2" name.  Using "__foo2"
> would yield a lookup error and the error would indicate there is a "foo2"
> available.  If you don't like it, any other suggestions?

Hmm. My main concern here would be that fixture definitions are easily
'findable' in a global search. The fixture decorator is easy to search
for, as is 'pytest_funcarg__'. Such an ugly prefix is also far easier
to google. Double underscore, not so much. The ugly prefix is also
good for backwards compat.

So, I don't really mind what happens as long as each fixture has at
least one of fixture decorator/ugly prefix.

cheers
Brianna


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

From holger at merlinux.eu  Wed Dec  4 07:26:55 2013
From: holger at merlinux.eu (holger krekel)
Date: Wed, 4 Dec 2013 06:26:55 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
Message-ID: <20131204062655.GU32207@merlinux.eu>

On Wed, Dec 04, 2013 at 13:29 +1100, Brianna Laugher wrote:
> On 3 December 2013 18:39, holger krekel <holger at merlinux.eu> wrote:
> > Right, it seems that when we introduced @pytest.fixture we decided you can
> > either use the prefix or the marker.  That could be lifted but i wonder
> > if we should rather go for a different convention because pytest_funcarg__
> > is not a beautiful prefix.  What do you think of pytest stripping the "__" prefix?
> >
> >     @pytest.fixture
> >     def __foo2(monkeypatch):
> >        return monkeypatch
> >
> > This fixture would become accessible via the "foo2" name.  Using "__foo2"
> > would yield a lookup error and the error would indicate there is a "foo2"
> > available.  If you don't like it, any other suggestions?
> 
> Hmm. My main concern here would be that fixture definitions are easily
> 'findable' in a global search. The fixture decorator is easy to search
> for, as is 'pytest_funcarg__'. Such an ugly prefix is also far easier
> to google. Double underscore, not so much. The ugly prefix is also
> good for backwards compat.
> 
> So, I don't really mind what happens as long as each fixture has at
> least one of fixture decorator/ugly prefix.

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 am a bit unhappy because apart from the pylint warning it's also a
real issue for beginners to write something like this::

    @pytest.fixture
    def somename():
        return 42
        
    def test_something():
        assert somename == 42

The "somename" is accessible (as a global) but is a function object.
The resulting error message is irritating if you are not proficient in python.
To prevent this irritation we would need to recommend a different
default way of declaring the fixture and neither pytest_funcarg__NAME nor
__NAME sound like we would like to suggest this as the main way in the docs.

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.

best,
holger

From lahwran at lahwran.net  Wed Dec  4 16:05:15 2013
From: lahwran at lahwran.net (lahwran)
Date: Wed, 4 Dec 2013 08:05:15 -0700
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <20131204062655.GU32207@merlinux.eu>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
Message-ID: <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>

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.


On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <holger at merlinux.eu> wrote:

> On Wed, Dec 04, 2013 at 13:29 +1100, Brianna Laugher wrote:
> > On 3 December 2013 18:39, holger krekel <holger at merlinux.eu> wrote:
> > > Right, it seems that when we introduced @pytest.fixture we decided you
> can
> > > either use the prefix or the marker.  That could be lifted but i wonder
> > > if we should rather go for a different convention because
> pytest_funcarg__
> > > is not a beautiful prefix.  What do you think of pytest stripping the
> "__" prefix?
> > >
> > >     @pytest.fixture
> > >     def __foo2(monkeypatch):
> > >        return monkeypatch
> > >
> > > This fixture would become accessible via the "foo2" name.  Using
> "__foo2"
> > > would yield a lookup error and the error would indicate there is a
> "foo2"
> > > available.  If you don't like it, any other suggestions?
> >
> > Hmm. My main concern here would be that fixture definitions are easily
> > 'findable' in a global search. The fixture decorator is easy to search
> > for, as is 'pytest_funcarg__'. Such an ugly prefix is also far easier
> > to google. Double underscore, not so much. The ugly prefix is also
> > good for backwards compat.
> >
> > So, I don't really mind what happens as long as each fixture has at
> > least one of fixture decorator/ugly prefix.
>
> 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 am a bit unhappy because apart from the pylint warning it's also a
> real issue for beginners to write something like this::
>
>     @pytest.fixture
>     def somename():
>         return 42
>
>     def test_something():
>         assert somename == 42
>
> The "somename" is accessible (as a global) but is a function object.
> The resulting error message is irritating if you are not proficient in
> python.
> To prevent this irritation we would need to recommend a different
> default way of declaring the fixture and neither pytest_funcarg__NAME nor
> __NAME sound like we would like to suggest this as the main way in the
> docs.
>
> 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.
>
> best,
> holger
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131204/05617af7/attachment.html>

From flub at devork.be  Fri Dec  6 11:07:49 2013
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 6 Dec 2013 10:07:49 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
Message-ID: <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>

Hi,

On 4 December 2013 15:05, lahwran <lahwran at lahwran.net> 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 <holger at merlinux.eu> 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

From holger at merlinux.eu  Sun Dec  8 10:40:54 2013
From: holger at merlinux.eu (holger krekel)
Date: Sun, 8 Dec 2013 09:40:54 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
Message-ID: <20131208094054.GP7196@merlinux.eu>

Hi Floris, all,

On Fri, Dec 06, 2013 at 10:07 +0000, Floris Bruynooghe wrote:
> On 4 December 2013 15:05, lahwran <lahwran at lahwran.net> 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.

Not quite sure.  It would mean that if you want to unittest 
fixture functions, it's slightly hairy.  More importantly,
i think sometimes i use (and probably others as well) direct
calling of fixture functions for other purposes already:

    @pytest.fixture
    def arg(request):
        ...

    @pytest.fixture
    def arg2(request):
        if some_condition:
           val = arg(request)
           ...

which is currently valid code.  Arguably one could use getfuncargvalue
but IIRC i had some reasons to not do it at the time. (Can't locate the
code currently).

That being sad, i am open to trying it -- so if somebody does a PR
introducing the "exploding" @pytest.fixture return value, i'd merge
it temporarily and see if there are any problems.  It would be very
nice if random errors of forgetting to specify an argument would 
result in a clear error message.

> > On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <holger at merlinux.eu> 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.

Not sure i follow.  What is different?  The only difference is that
the decorator allows to specify a caching scope, params etc.  It does
not change anything about the fixture functions own signature.

> 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).

Aiming for better pylint integration eg. through a plugin sounds like a
great plan.  And one that does not require deep pytest knowledge -- so
if someone here on the list is interested, i am willing to help design it.

> >> 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.

True as well.  Although for my 1K-10K LOC projects it's not really an issue 
yet.  Maybe some day we can think about namespacing in some way.

best,
holger

From flub at devork.be  Sun Dec  8 21:49:28 2013
From: flub at devork.be (Floris Bruynooghe)
Date: Sun, 8 Dec 2013 20:49:28 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <20131208094054.GP7196@merlinux.eu>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
 <20131208094054.GP7196@merlinux.eu>
Message-ID: <CAAWk_DyVHF10P3v6ZgduBrHP4wB52CP92eRHHA8jyu-hyLF6+Q@mail.gmail.com>

On 8 December 2013 09:40, holger krekel <holger at merlinux.eu> wrote:
>> > On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <holger at merlinux.eu> 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.
>
> Not sure i follow.  What is different?  The only difference is that
> the decorator allows to specify a caching scope, params etc.  It does
> not change anything about the fixture functions own signature.

I was assuming the old fixtures do not allow requesting other fixtures
via funcargs.  But I might well be wrong on that.


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From brianna.laugher at gmail.com  Mon Dec  9 04:22:51 2013
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Mon, 9 Dec 2013 14:22:51 +1100
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <20131208094054.GP7196@merlinux.eu>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
 <20131208094054.GP7196@merlinux.eu>
Message-ID: <CAPjwCjtkNNCr+aNwvoFfHDN=Evxd568kVdL=OJn2Pq-T1wQUEA@mail.gmail.com>

Hi,

On 8 December 2013 20:40, holger krekel <holger at merlinux.eu> wrote:
>> 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).
>
> Aiming for better pylint integration eg. through a plugin sounds like a
> great plan.  And one that does not require deep pytest knowledge -- so
> if someone here on the list is interested, i am willing to help design it.


I agree, I think a plugin is the way to go.

I have made a bit of an initial stab at a plugin:

https://bitbucket.org/pfctdayelise/pylint-pytest/

I am not sure the string building approach will get us very far, but I
just wanted to get something that would at least run (a lot of the
pylint docs are out of date).

Someone should probably run pylint over the pytest src to see what
other pylint messages are common.

cheers
Brianna

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

From holger at merlinux.eu  Mon Dec  9 07:08:30 2013
From: holger at merlinux.eu (holger krekel)
Date: Mon, 9 Dec 2013 06:08:30 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAAWk_DyVHF10P3v6ZgduBrHP4wB52CP92eRHHA8jyu-hyLF6+Q@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
 <20131208094054.GP7196@merlinux.eu>
 <CAAWk_DyVHF10P3v6ZgduBrHP4wB52CP92eRHHA8jyu-hyLF6+Q@mail.gmail.com>
Message-ID: <20131209060830.GT7196@merlinux.eu>

On Sun, Dec 08, 2013 at 20:49 +0000, Floris Bruynooghe wrote:
> On 8 December 2013 09:40, holger krekel <holger at merlinux.eu> wrote:
> >> > On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <holger at merlinux.eu> 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.
> >
> > Not sure i follow.  What is different?  The only difference is that
> > the decorator allows to specify a caching scope, params etc.  It does
> > not change anything about the fixture functions own signature.
> 
> I was assuming the old fixtures do not allow requesting other fixtures
> via funcargs.  But I might well be wrong on that.

Indeed, old pytest_funcarg__fixture already accepted other fixtures as
arguments, so no difference there.

However, i now think and agree that adding @pytest.fixture markers to
old-style pytest_funcarg__NAME fixtures is a bit backwards.  Going for
a pylint plugin probably makes more sense.  So i just backed out
the change (so now you cannot use @pytest.fixture on pytest_funcarg__NAME).

best,
holger

> 
> Regards,
> Floris
> 
> 
> -- 
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
> 

From flub at devork.be  Tue Dec 10 10:30:54 2013
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 10 Dec 2013 09:30:54 +0000
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAPjwCjtkNNCr+aNwvoFfHDN=Evxd568kVdL=OJn2Pq-T1wQUEA@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
 <20131208094054.GP7196@merlinux.eu>
 <CAPjwCjtkNNCr+aNwvoFfHDN=Evxd568kVdL=OJn2Pq-T1wQUEA@mail.gmail.com>
Message-ID: <CAAWk_DxnXpVgdYGv6c0OHu_J5nKd65xca3pLG2FxONefZ817ZA@mail.gmail.com>

Hi Brianna,

On 9 December 2013 03:22, Brianna Laugher <brianna.laugher at gmail.com> wrote:
> I agree, I think a plugin is the way to go.
>
> I have made a bit of an initial stab at a plugin:
>
> https://bitbucket.org/pfctdayelise/pylint-pytest/

I get a message saying I have no permission to access the repository
when following that URL.


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From brianna.laugher at gmail.com  Tue Dec 10 23:37:50 2013
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Wed, 11 Dec 2013 09:37:50 +1100
Subject: [pytest-dev] fixtures and pylint W0621
In-Reply-To: <CAAWk_DxnXpVgdYGv6c0OHu_J5nKd65xca3pLG2FxONefZ817ZA@mail.gmail.com>
References: <CAPjwCjsoM+88wnRexud7RzmWfJvJEf_Tbi4EJW-wu1-yuqv+bQ@mail.gmail.com>
 <20131126075840.GJ11363@merlinux.eu>
 <CAPjwCjtq+Y0z_cyXQXxqH74i24TgJs-nsQNPfP9hx0MfOySMAA@mail.gmail.com>
 <20131203073919.GQ32207@merlinux.eu>
 <CAPjwCjsRm3_pkKvxQXSy1+M3O1ZwHwXg8M9gzYNgK_aLQB9D9Q@mail.gmail.com>
 <20131204062655.GU32207@merlinux.eu>
 <CAHocxTi0-w_1Ov3_2ywexnU6PGsP4O=3TWPHaG1ycUfdBi60aQ@mail.gmail.com>
 <CAAWk_DxuAUCkPtPW8R7DSZW=z77jxLbEJ3TUUJJWry5sZ_Vs3Q@mail.gmail.com>
 <20131208094054.GP7196@merlinux.eu>
 <CAPjwCjtkNNCr+aNwvoFfHDN=Evxd568kVdL=OJn2Pq-T1wQUEA@mail.gmail.com>
 <CAAWk_DxnXpVgdYGv6c0OHu_J5nKd65xca3pLG2FxONefZ817ZA@mail.gmail.com>
Message-ID: <CAPjwCjtHzetEVzWgwUn_9m7QwyBk_oSTfE66y0r2cd0mVtjm1A@mail.gmail.com>

Sorry, I accidentally made it private - should be accessible now.

Brianna
On 10/12/2013 8:30 PM, "Floris Bruynooghe" <flub at devork.be> wrote:

> Hi Brianna,
>
> On 9 December 2013 03:22, Brianna Laugher <brianna.laugher at gmail.com>
> wrote:
> > I agree, I think a plugin is the way to go.
> >
> > I have made a bit of an initial stab at a plugin:
> >
> > https://bitbucket.org/pfctdayelise/pylint-pytest/
>
> I get a message saying I have no permission to access the repository
> when following that URL.
>
>
> Regards,
> Floris
>
>
> --
> Debian GNU/Linux -- The Power of Freedom
> www.debian.org | www.gnu.org | www.kernel.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131211/f12718c6/attachment.html>

From holger at merlinux.eu  Thu Dec 12 13:07:53 2013
From: holger at merlinux.eu (holger krekel)
Date: Thu, 12 Dec 2013 12:07:53 +0000
Subject: [pytest-dev] pytest-2.5.0: many fixes. ZERO reported bugs left.
Message-ID: <20131212120753.GN26337@merlinux.eu>

pytest-2.5.0: many fixes ... now down to ZERO reported bugs!
===========================================================================

pytest-2.5.0 is a big bug fixing release, the result of two community bug
fixing days plus numerous additional works from many people and
reporters.  The release should be fully compatible to 2.4.2, existing
plugins and test suites.  

We aim at maintaining this level of ZERO reported bugs because it's no
fun if your testing tool has bugs, is it?  Under a condition, though: 
when submitting a bug report please provide clear information about the
circumstances and a simple example which reproduces the problem.

The issue tracker is of course not empty now.  We have many remaining
"enhancement" issues which we'll hopefully can tackle in 2014 with your help.

For those who use older Python versions, please note that pytest is itself not
automatically tested anymore on python2.5 due to virtualenv, setuptools and tox
not supporting it anymore.  Manual verification shows that it 
works fine still but that might change in the future.

As usual, current docs are at 

    http://pytest.org 

and you can upgrade from pypi via::

    pip install -U pytest

Particular thanks for helping with this release go to Anatoly Bubenkoff,
Floris Bruynooghe, Marc Abramowitz, Ralph Schmitt, Ronny Pfannschmidt,
Donald Stufft, James Lan, Rob Dennis, Jason R. Coombs, Mathieu Agopian,
Virgil Dupras, Bruno Oliveira, Alex Gaynor and others.

have fun,
holger krekel


2.5.0
-----------------------------------

- dropped python2.5 from automated release testing of pytest itself 
  which means it's probably going to break soon (but still works 
  with this release we believe).

- simplified and fixed implementation for calling finalizers when
  parametrized fixtures or function arguments are involved.  finalization 
  is now performed lazily at setup time instead of in the "teardown phase".
  While this might sound odd at first, it helps to ensure that we are 
  correctly handling setup/teardown even in complex code.  User-level code
  should not be affected unless it's implementing the pytest_runtest_teardown
  hook and expecting certain fixture instances are torn down within (very
  unlikely and would have been unreliable anyway).

- PR90: add --color=yes|no|auto option to force terminal coloring 
  mode ("auto" is default).  Thanks Marc Abramowitz.

- fix issue319 - correctly show unicode in assertion errors.  Many
  thanks to Floris Bruynooghe for the complete PR.  Also means
  we depend on py>=1.4.19 now.

- fix issue396 - correctly sort and finalize class-scoped parametrized 
  tests independently from number of methods on the class.  

- refix issue323 in a better way -- parametrization should now never
  cause Runtime Recursion errors because the underlying algorithm
  for re-ordering tests per-scope/per-fixture is not recursive
  anymore (it was tail-call recursive before which could lead
  to problems for more than >966 non-function scoped parameters).

- fix issue290 - there is preliminary support now for parametrizing
  with repeated same values (sometimes useful to to test if calling 
  a second time works as with the first time).

- close issue240 - document precisely how pytest module importing
  works, discuss the two common test directory layouts, and how it 
  interacts with PEP420-namespace packages.

- fix issue246 fix finalizer order to be LIFO on independent fixtures
  depending on a parametrized higher-than-function scoped fixture. 
  (was quite some effort so please bear with the complexity of this sentence :)
  Thanks Ralph Schmitt for the precise failure example.
 
- fix issue244 by implementing special index for parameters to only use
  indices for paramentrized test ids

- fix issue287 by running all finalizers but saving the exception
  from the first failing finalizer and re-raising it so teardown will
  still have failed.  We reraise the first failing exception because
  it might be the cause for other finalizers to fail.

- fix ordering when mock.patch or other standard decorator-wrappings
  are used with test methods.  This fixues issue346 and should
  help with random "xdist" collection failures.  Thanks to
  Ronny Pfannschmidt and Donald Stufft for helping to isolate it.

- fix issue357 - special case "-k" expressions to allow for
  filtering with simple strings that are not valid python expressions.
  Examples: "-k 1.3" matches all tests parametrized with 1.3.
  "-k None" filters all tests that have "None" in their name
  and conversely "-k 'not None'". 
  Previously these examples would raise syntax errors.
  
- fix issue384 by removing the trial support code
  since the unittest compat enhancements allow
  trial to handle it on its own

- don't hide an ImportError when importing a plugin produces one.
  fixes issue375.

- fix issue275 - allow usefixtures and autouse fixtures 
  for running doctest text files.

- fix issue380 by making --resultlog only rely on longrepr instead
  of the "reprcrash" attribute which only exists sometimes.

- address issue122: allow @pytest.fixture(params=iterator) by exploding
  into a list early on.

- fix pexpect-3.0 compatibility for pytest's own tests.
  (fixes issue386)

- allow nested parametrize-value markers, thanks James Lan for the PR.

- fix unicode handling with new monkeypatch.setattr(import_path, value)
  API.  Thanks Rob Dennis.  Fixes issue371.

- fix unicode handling with junitxml, fixes issue368.

- In assertion rewriting mode on Python 2, fix the detection of coding
  cookies. See issue #330.

- make "--runxfail" turn imperative pytest.xfail calls into no ops
  (it already did neutralize pytest.mark.xfail markers)

- refine pytest / pkg_resources interactions: The AssertionRewritingHook
  PEP302 compliant loader now registers itself with setuptools/pkg_resources 
  properly so that the pkg_resources.resource_stream method works properly.
  Fixes issue366.  Thanks for the investigations and full PR to Jason R. Coombs.

- pytestconfig fixture is now session-scoped as it is the same object during the
  whole test run.  Fixes issue370. 

- avoid one surprising case of marker malfunction/confusion::
  
      @pytest.mark.some(lambda arg: ...)
      def test_function():

  would not work correctly because pytest assumes @pytest.mark.some 
  gets a function to be decorated already.  We now at least detect if this 
  arg is an lambda and thus the example will work.  Thanks Alex Gaynor
  for bringing it up.

- xfail a test on pypy that checks wrong encoding/ascii (pypy does
  not error out). fixes issue385.

- internally make varnames() deal with classes's __init__,
  although it's not needed by pytest itself atm.  Also
  fix caching.  Fixes issue376.

- fix issue221 - handle importing of namespace-package with no 
  __init__.py properly.

- refactor internal FixtureRequest handling to avoid monkeypatching.
  One of the positive user-facing effects is that the "request" object 
  can now be used in closures.

- fixed version comparison in pytest.importskip(modname, minverstring)

- fix issue377 by clarifying in the nose-compat docs that pytest
  does not duplicate the unittest-API into the "plain" namespace.

- fix verbose reporting for @mock'd test functions


From holger at merlinux.eu  Sat Dec 14 09:07:43 2013
From: holger at merlinux.eu (holger krekel)
Date: Sat, 14 Dec 2013 08:07:43 +0000
Subject: [pytest-dev] new pytest docs styling PR
Message-ID: <20131214080743.GW26337@merlinux.eu>

Hi all,

Tobias Bieniek offered a Pull Request for a new pytest doc styling.
He includes a few screenshots:

    https://github.com/hpk42/pytest/pull/8

What do you think?

best,
holger


From vladimir at keleshev.com  Sat Dec 14 11:40:10 2013
From: vladimir at keleshev.com (Vladimir Keleshev)
Date: Sat, 14 Dec 2013 11:40:10 +0100
Subject: [pytest-dev] new pytest docs styling PR
In-Reply-To: <20131214080743.GW26337@merlinux.eu>
References: <20131214080743.GW26337@merlinux.eu>
Message-ID: <137941387017610@web25m.yandex.ru>

I like it a lot.

(+) cleaner
(+) navbar on the left?more recognizable (at least for me)
(-) custom scrollbar is grabbing my attention and is annoying

?Vladimir



14.12.2013, 09:07, "holger krekel" <holger at merlinux.eu>:
> Hi all,
>
> Tobias Bieniek offered a Pull Request for a new pytest doc styling.
> He includes a few screenshots:
>
> ????https://github.com/hpk42/pytest/pull/8
>
> What do you think?
>
> best,
> holger
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From anthon at mnt.org  Sat Dec 14 12:15:00 2013
From: anthon at mnt.org (Anthon van der Neut)
Date: Sat, 14 Dec 2013 12:15:00 +0100
Subject: [pytest-dev] new pytest docs styling PR
In-Reply-To: <20131214080743.GW26337@merlinux.eu>
References: <20131214080743.GW26337@merlinux.eu>
Message-ID: <52AC3DB4.3090708@mnt.org>

The layout of the nav-bar to the left seems an improvement.
*  you would have to check if printing does away with the nav-bar
*  the nav-bar should be collapsable to a small vertical strip, so it 
doesn't leave 1/4 to 1/3 of the screen unused when scrolling down on 
long pages ( especially annoying when reading on a higher than wide 
portrait oriented monitor )

The font for the headers is difficult to read and gives an 
unprofessional Comic Sans feeling.

The page is too white for my taste, not quiet enough on the eyes

Just my ?0.01

Anthon

On 2013-12-14 09:07, holger krekel wrote:
> Hi all,
>
> Tobias Bieniek offered a Pull Request for a new pytest doc styling.
> He includes a few screenshots:
>
>      https://github.com/hpk42/pytest/pull/8
>
> What do you think?
>
> best,
> holger
>
> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>


From holger at merlinux.eu  Sat Dec 14 13:01:37 2013
From: holger at merlinux.eu (holger krekel)
Date: Sat, 14 Dec 2013 12:01:37 +0000
Subject: [pytest-dev] new pytest docs styling PR
In-Reply-To: <52AC3DB4.3090708@mnt.org>
References: <20131214080743.GW26337@merlinux.eu>
 <52AC3DB4.3090708@mnt.org>
Message-ID: <20131214120137.GZ26337@merlinux.eu>

On Sat, Dec 14, 2013 at 12:15 +0100, Anthon van der Neut wrote:
> The layout of the nav-bar to the left seems an improvement.
> *  you would have to check if printing does away with the nav-bar

yes, seems to work.

> *  the nav-bar should be collapsable to a small vertical strip, so
> it doesn't leave 1/4 to 1/3 of the screen unused when scrolling down
> on long pages ( especially annoying when reading on a higher than
> wide portrait oriented monitor )

I'll ask for it on th ePR.

> The font for the headers is difficult to read and gives an
> unprofessional Comic Sans feeling.

I think i agree.

> The page is too white for my taste, not quiet enough on the eyes

So you mean a light grey?  

Can you maybe also join commenting on the PR?

best,
holger

> Just my ?0.01
> 
> Anthon
> 
> On 2013-12-14 09:07, holger krekel wrote:
> >Hi all,
> >
> >Tobias Bieniek offered a Pull Request for a new pytest doc styling.
> >He includes a few screenshots:
> >
> >     https://github.com/hpk42/pytest/pull/8
> >
> >What do you think?
> >
> >best,
> >holger
> >
> >_______________________________________________
> >Pytest-dev mailing list
> >Pytest-dev at python.org
> >https://mail.python.org/mailman/listinfo/pytest-dev
> >
> 

From holger at merlinux.eu  Sat Dec 14 13:02:04 2013
From: holger at merlinux.eu (holger krekel)
Date: Sat, 14 Dec 2013 12:02:04 +0000
Subject: [pytest-dev] new pytest docs styling PR
In-Reply-To: <137941387017610@web25m.yandex.ru>
References: <20131214080743.GW26337@merlinux.eu>
 <137941387017610@web25m.yandex.ru>
Message-ID: <20131214120204.GA26337@merlinux.eu>

On Sat, Dec 14, 2013 at 11:40 +0100, Vladimir Keleshev wrote:
> I like it a lot.
> 
> (+) cleaner
> (+) navbar on the left?more recognizable (at least for me)
> (-) custom scrollbar is grabbing my attention and is annoying

Which custom scrollbar do you mean? 
May i suggest taht you also join the PR comments?

holger

> ?Vladimir
> 
> 
> 
> 14.12.2013, 09:07, "holger krekel" <holger at merlinux.eu>:
> > Hi all,
> >
> > Tobias Bieniek offered a Pull Request for a new pytest doc styling.
> > He includes a few screenshots:
> >
> > ????https://github.com/hpk42/pytest/pull/8
> >
> > What do you think?
> >
> > best,
> > holger
> >
> > _______________________________________________
> > Pytest-dev mailing list
> > Pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> 

From flub at devork.be  Mon Dec 16 12:05:46 2013
From: flub at devork.be (Floris Bruynooghe)
Date: Mon, 16 Dec 2013 11:05:46 +0000
Subject: [pytest-dev] regarding parametrized ids
In-Reply-To: <20131216053156.GA15666@merlinux.eu>
References: <20131216053156.GA15666@merlinux.eu>
Message-ID: <CAAWk_DxYMQAzHLoORYviGS31YSJuf0e_dPS8gvpnVMPHnQZATw@mail.gmail.com>

Hello Holger,

On 16 December 2013 05:31, holger krekel <holger at merlinux.eu> wrote:
> Hi Floris,
>
> i think the docstring is wrong: "argvalues" is not part of @fixture signature.

Oops, copied that from MetaFunc.parameterize().  Fixed it to refer to params.

> Btw, Anatoly suggests even core committers (including me) should propose
> PRs instead of committing directly for any non-trivial change.  I'd like
> to try this out for a while (probably hardest for me :).  What do you think?

I'm all for giving this a go.  But maybe we'd want to discuss some
workflow on pytest-dev, e.g. what branching style to use etc.
Personally I like mq but bitbucket's support for it is a bit poor (no
pull requests).  So far I've just created a throw-away repo per pull
request to avoid creating branches but that gets a bit cumbersome I
guess.

What would also be great is if we could aromatically have the full tox
tests run for each pull request, maybe this is possible with some
devpi interaction?  Or this is already possible with the travis setup
(but I thought that had incomplete coverage)?

I'm happy to try and help towards this and I'm pretty sure we can help
donate a vm to run tests on (we already have a cpython buildslave
running on sparc), or we might be able to get some rackspace dontated
boxes (I heard they do this for free software projects and they'll
have better connectivity)?


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From holger at merlinux.eu  Tue Dec 17 10:54:15 2013
From: holger at merlinux.eu (holger krekel)
Date: Tue, 17 Dec 2013 09:54:15 +0000
Subject: [pytest-dev] pytest-2.5.1: fixes and new home page styling
Message-ID: <20131217095415.GI15666@merlinux.eu>

pytest-2.5.1: fixes and new home page styling
===========================================================================

pytest is a mature Python testing tool with more than a 1000 tests 
against itself, passing on many different interpreters and platforms.  

The 2.5.1 release maintains the "zero-reported-bugs" promise by fixing
the three bugs reported since the last release a few days ago.  It also
features a new home page styling implemented by Tobias Bieniek, based on
the flask theme from Armin Ronacher:

    http://pytest.org

If you have anything more to improve styling and docs, 
we'd be very happy to merge further pull requests.

On the coding side, the release also contains a little enhancement to
fixture decorators allowing to directly influence generation of test
ids, thanks to Floris Bruynooghe.  Other thanks for helping with 
this release go to Anatoly Bubenkoff and Ronny Pfannschmidt.

As usual, you can upgrade from pypi via::

    pip install -U pytest

have fun and a nice remaining "bug-free" time of the year :)
holger krekel

2.5.1
-----------------------------------

- merge new documentation styling PR from Tobias Bieniek.

- fix issue403: allow parametrize of multiple same-name functions within
  a collection node.  Thanks Andreas Kloeckner and Alex Gaynor for reporting
  and analysis.

- Allow parameterized fixtures to specify the ID of the parameters by
  adding an ids argument to pytest.fixture() and pytest.yield_fixture().
  Thanks Floris Bruynooghe. 

- fix issue404 by always using the binary xml escape in the junitxml
  plugin.  Thanks Ronny Pfannschmidt.

- fix issue407: fix addoption docstring to point to argparse instead of
  optparse. Thanks Daniel D. Wright.


From schettino72 at gmail.com  Wed Dec 18 00:41:26 2013
From: schettino72 at gmail.com (Eduardo Schettino)
Date: Wed, 18 Dec 2013 12:41:26 +1300
Subject: [pytest-dev] pytest-2.5.1: fixes and new home page styling
In-Reply-To: <20131217095415.GI15666@merlinux.eu>
References: <20131217095415.GI15666@merlinux.eu>
Message-ID: <CAHSrCY110wa2x985evziS3H8TnGW8XngJnOJ+EHsykrn_U9Q8w@mail.gmail.com>

On Tue, Dec 17, 2013 at 10:54 PM, holger krekel <holger at merlinux.eu> wrote:

> pytest-2.5.1: fixes and new home page styling
> ===========================================================================
>
> The 2.5.1 release maintains the "zero-reported-bugs" promise by fixing
> the three bugs reported since the last release a few days ago.  It also
> features a new home page styling implemented by Tobias Bieniek, based on
> the flask theme from Armin Ronacher:
>
>     http://pytest.org
>
> If you have anything more to improve styling and docs,
> we'd be very happy to merge further pull requests.
>
>
About the new styling... looks good :)
but I think the lack of a "next" link at the bottom of the pages is really
annoying.

cheers,
  Eduardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131218/a446c640/attachment.html>

From holger at merlinux.eu  Wed Dec 18 08:35:02 2013
From: holger at merlinux.eu (holger krekel)
Date: Wed, 18 Dec 2013 07:35:02 +0000
Subject: [pytest-dev] pytest-2.5.1: fixes and new home page styling
In-Reply-To: <CAHSrCY110wa2x985evziS3H8TnGW8XngJnOJ+EHsykrn_U9Q8w@mail.gmail.com>
References: <20131217095415.GI15666@merlinux.eu>
 <CAHSrCY110wa2x985evziS3H8TnGW8XngJnOJ+EHsykrn_U9Q8w@mail.gmail.com>
Message-ID: <20131218073502.GO15666@merlinux.eu>

On Wed, Dec 18, 2013 at 12:41 +1300, Eduardo Schettino wrote:
> On Tue, Dec 17, 2013 at 10:54 PM, holger krekel <holger at merlinux.eu> wrote:
> 
> > pytest-2.5.1: fixes and new home page styling
> > ===========================================================================
> >
> > The 2.5.1 release maintains the "zero-reported-bugs" promise by fixing
> > the three bugs reported since the last release a few days ago.  It also
> > features a new home page styling implemented by Tobias Bieniek, based on
> > the flask theme from Armin Ronacher:
> >
> >     http://pytest.org
> >
> > If you have anything more to improve styling and docs,
> > we'd be very happy to merge further pull requests.
> >
> >
> About the new styling... looks good :)
> but I think the lack of a "next" link at the bottom of the pages is really
> annoying.

If you or someone knows how to add it back to the sphinx theme,
i'd happily accept a PR.

best,
holger

> cheers,
>   Eduardo

> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


From anton7811 at gmail.com  Tue Dec 24 19:09:56 2013
From: anton7811 at gmail.com (Anton P)
Date: Tue, 24 Dec 2013 20:09:56 +0200
Subject: [pytest-dev] How to determinate if test is skipped on
	runtest_teardown hook?
Message-ID: <CALL=tm0pjKv7jHJ2R45JkkT7v+E3TkJvSLndC6oGk5kCLspsWw@mail.gmail.com>

Hi All,

Is there is possibility to determinate if test is skipped or not on
pytest_runtest_teardown hook.
I can see skipif marker in item.keywords, but I don't know it's status.

Thank you in advance!
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131224/9fc1cb18/attachment.html>

From Michelle.Chartier at gmx.com  Sat Dec 28 00:44:12 2013
From: Michelle.Chartier at gmx.com (Michelle Chartier)
Date: Fri, 27 Dec 2013 18:44:12 -0500
Subject: [pytest-dev] Autocompletion on fixture objects as test function
 input arguments - PyCharm
Message-ID: <20131227234412.212940@gmx.com>

Hey all,

I recently got the community edition PyCharm IDE and so far like a lot of things about it (especially the ability to run pytest tests from within it). HOWEVER, I am having a problem with auto-completion on fixture functions (I realize this may not be the place to ask this question but I was hoping someone had some info that could help me or point me somewhere :) )

So, the problem: in my test function I am using a fixture object as an input argument and want to be able to see all available functions with autocompletion. To see autocompletion in Aptana, I imported the necessary fixture to the test module where my test function resides (the fixture is imported to a conftest in a package I have defined)

----------------------------------

Example:

#this test module resides in mypackag.mysubpackage.mysubsubpackage

from mypackage.mysubpackage.conftest import myobj

def test_mytest(myobj):
 myobj. (<- this is where the autocompletion should show up?)


----------------------------------


In Aptana myobj shows all the available functions with autocompletion as expected but in PyCharm (with the exact same code/folders/folder structure) it says "No suggestions."

Anyone have a similar problem or know of a solution? (I would prefer to stick with PyCharm... :) )

Thanks!
Michelle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131227/b332d13f/attachment.html>

From anton7811 at gmail.com  Mon Dec 30 09:36:07 2013
From: anton7811 at gmail.com (Anton P)
Date: Mon, 30 Dec 2013 10:36:07 +0200
Subject: [pytest-dev] How to determinate if test is skipped on
	runtest_teardown hook?
In-Reply-To: <CALL=tm0pjKv7jHJ2R45JkkT7v+E3TkJvSLndC6oGk5kCLspsWw@mail.gmail.com>
References: <CALL=tm0pjKv7jHJ2R45JkkT7v+E3TkJvSLndC6oGk5kCLspsWw@mail.gmail.com>
Message-ID: <CALL=tm2k0R6aMcje-xAP+qcRA3zzQCphvt2TEsSESHA1NwNziA@mail.gmail.com>

Has anybody any ideas about this?

Thank you!
Anton


On Tue, Dec 24, 2013 at 8:09 PM, Anton P <anton7811 at gmail.com> wrote:

> Hi All,
>
> Is there is possibility to determinate if test is skipped or not on
> pytest_runtest_teardown hook.
> I can see skipif marker in item.keywords, but I don't know it's status.
>
> Thank you in advance!
> Anton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20131230/b6b1e626/attachment.html>