From anton7811 at gmail.com  Mon Oct  1 13:08:40 2012
From: anton7811 at gmail.com (Anton P)
Date: Mon, 1 Oct 2012 14:08:40 +0300
Subject: [py-dev] using logging in py.test
In-Reply-To: <20120930185643.GQ27773@merlinux.eu>
References: <CALL=tm137B2XTo0+nO_Em2+9U_YVgejDpVpcPYxRceeVMj1FMA@mail.gmail.com>
	<20120930185643.GQ27773@merlinux.eu>
Message-ID: <CALL=tm2SON-KZzhyUv2S90duiQRHKuHgOVGoF5xZq3L-387x_w@mail.gmail.com>

Hi Holger,

On Sun, Sep 30, 2012 at 9:56 PM, holger krekel <holger at merlinux.eu> wrote:
> Hi Anton,
>
> On Sun, Sep 30, 2012 at 19:16 +0300, Anton P wrote:
>> Hi All,
>>
>> I'd like to use standard logging module with py.test. Messages
>> generated from test functions are visible on stdout if -s option is
>> set. But log messages generated from conftest.py or other custom
>> modules used inside test function are not visible on stdout but
>> visible in captured stdout in case -s option isn't set.
>>
>> I want to see all the messages from all modules on stdout, not only
>> from test function.
>
> An initial conftest.py file is loaded very early and pytest uses
> unconditional capturing.  This goes back to a request from the PyPy
> folks who start GCC at this stage and otherwise see lots of stuff.
> If this proves to be a problem we have to see how to make it conditional.
> Problem is that the conftest.py often add command line options and thus
> need to to be loaded before opts are parsed (and thus "-s").
> If logging is active during conftest.py import-time it will see the
> captured stream and probably record it and use it from there on.
> As the captured stream is not analyzed/used further in the case of "-s"
> it is kind of lost, loosing the logging messages.
>
> Potential solutions:
>
> - try to avoid doing calls/imports of logging during conftest.py import-time.
> - try out pytest-logging plugin to see if it helps
> - program a PYTEST_NOCAPTURE environement setting to pytest to allow switching
>   off capturing totally
>
> best,
> holger
>
> That
>> Thank you in advance!
>> -Anton
>> _______________________________________________
>> py-dev mailing list
>> py-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/py-dev
>>

Thank you for the answer.
Your clarification in py.test capture functionality helped me to
resolve my issue. So if I init logger on function level instead module
level as before, I get all messages on console. In case module is
imported only in test functions (not in conftest), I can init logger
on module level. This is acceptable for me.

BTW I forgot to write that file handler of standart python logging
module works properly. The issue only with stdout logging.

-Anton


From issues-reply at bitbucket.org  Mon Oct  1 15:43:41 2012
From: issues-reply at bitbucket.org (Ronny Pfannschmidt)
Date: Mon, 01 Oct 2012 13:43:41 -0000
Subject: [py-dev] [hpk42/pytest] traceback pruning not possible/changable
 via hooks (issue #195)
Message-ID: <a9cb0dee5ea6c274ec7f6e1e0c3148f2@bitbucket.org>

--- you can reply above this line ---

New issue 195: traceback pruning not possible/changable via hooks
https://bitbucket.org/hpk42/pytest/issue/195/traceback-pruning-not-possible-changable

Ronny Pfannschmidt:

required for the pypy conftest


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Mon Oct  1 15:44:41 2012
From: issues-reply at bitbucket.org (Ronny Pfannschmidt)
Date: Mon, 01 Oct 2012 13:44:41 -0000
Subject: [py-dev] [hpk42/pytest] error reprs not changable availiable via
	hooks (issue #196)
Message-ID: <b08cce7b697add3ef19c4337a031d0b6@bitbucket.org>

--- you can reply above this line ---

New issue 196: error reprs not changable availiable via hooks
https://bitbucket.org/hpk42/pytest/issue/196/error-reprs-not-changable-availiable-via

Ronny Pfannschmidt:

required for the pypy conftest


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Thu Oct  4 21:06:34 2012
From: issues-reply at bitbucket.org (Jason R. Coombs)
Date: Thu, 04 Oct 2012 19:06:34 -0000
Subject: [py-dev] [hpk42/pytest] Failing to parameterize leaves metafunc
 unparameterized, resulting in error (issue #197)
Message-ID: <4a2b7238a2a79640d446fcd1e3b60306@bitbucket.org>

--- you can reply above this line ---

New issue 197: Failing to parameterize leaves metafunc unparameterized, resulting in error
https://bitbucket.org/hpk42/pytest/issue/197/failing-to-parameterize-leaves-metafunc

Jason R. Coombs:

We have a test where we often want to run it against a varying number of parameters (pulled from a live environment):

{{{
@pytest.mark.parametrize(('region', 'name'),
    list(questionnaires_under_test()))
def test_questionnaire(region, name):
    ...
}}}

The function 'questionnaires_under_test' could generate 0 or more results. If it generates 0 results, simulated by this code:

{{{
@pytest.mark.parametrize(('region', 'name'), [])
def test_questionnaire(region, name):
    ...
}}}

however, the test fails with this error:

{{{
        LookupError: no factory found for argument 'region'
        available funcargs: pytestconfig, selenium, recwarn, pony_survey, monkeypatch, simple_survey, capfd, pdl_gender_survey, capsys, tmpdir
        use 'py.test --funcargs [testpath]' for help on them.
}}}

Since pytest has already had the opportunity to parameterize that function, but nothing was suitable, it would be nice if pytest could remove that test from the tests to be run and not raise the error.

I've been able to work around the issue by skipping the entire file if no questionnaires would be generated:

{{{
if not pytest.config.option.live_questionnaires:
    pytest.skip()
}}}

Another way to describe this issue, pytest allows for parameterization of 1 or more inputs, but doesn't handle 0 or more very well. It's conceivable to me that pytest could handle the null case without raising an error. If that's the case, please consider it for a future improvement.

I realize there might be some complications in how parameterization works that would make this a challenging improvement. If that's the case, it's probably not worth it.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Fri Oct  5 14:31:09 2012
From: issues-reply at bitbucket.org (Jason R. Coombs)
Date: Fri, 05 Oct 2012 12:31:09 -0000
Subject: [py-dev] [hpk42/pytest] localized conftest not run (issue #198)
Message-ID: <70f343106e6b2d8690f2b59c9a9ffd1a@bitbucket.org>

--- you can reply above this line ---

New issue 198: localized conftest not run
https://bitbucket.org/hpk42/pytest/issue/198/localized-conftest-not-run

Jason R. Coombs:

In the [[https://bitbucket.org/yougov/pmxbot|pmxbot project]], there is a pytest test suite, and within that test suite are two conftest.py files, one at tests/conftest.py and another at tests/unit/conftest.py.

{{{
PS C:\Users\jaraco\G\public\pmxbot> tree /f tests
?   conftest.py
?   __init__.py
?
????functional
?   ?   test_exceptions.py
?   ?   test_logging.py
?   ?   test_messages.py
?   ?   test_rss.py
?   ?   __init__.py
?   ?
?   ...
?
????unit
        conftest.py
        testconf.yaml
        test_commands.py
        test_karma.py
        test_quotes.py
        test_util.py
        __init__.py
}}}

These tests run fine under pytest 2.2.4, but under 2.3.dev10 and 2.3.dev17, some tests fail. Specifically, the tests that depend on the funcarg as defined in [[/yougov/pmxbot/src/85020053dd0b/tests/unit/conftest.py|tests/unit/conftest.py]] will fail because the funcarg is not defined:

{{{
PS C:\Users\jaraco\G\public\pmxbot> py.test -k MongoDBKarma -x
============================= test session starts =============================
platform win32 -- Python 2.7.3 -- pytest-2.3.0.dev17 -- C:\Python\python.exe
collected 219 items

tests\unit\test_karma.py:21: TestMongoDBKarma.test_basic_usage ERROR

=================================== ERRORS ====================================
_____________ ERROR at setup of TestMongoDBKarma.test_basic_usage _____________

    def test_basic_usage(self, mongodb_uri):
        LookupError: no factory found for argument 'mongodb_uri'
        available funcargs: pytestconfig, recwarn, monkeypatch, capfd, capsys, tmpdir
        use 'py.test --funcargs [testpath]' for help on them.

C:\Users\jaraco\G\public\pmxbot\tests\unit\test_karma.py:21
!!!!!!!!!!!!!!!!!!! Interrupted: stopping after 1 failures !!!!!!!!!!!!!!!!!!!!
================== 215 tests deselected by '-kMongoDBKarma' ===================
=================== 215 deselected, 1 error in 4.49 seconds ===================
}}}

I read the changelog for changes between 2.2 and 2.3 and I didn't see anything that seemed to indicate that this pattern is no longer supported.

Can pytest support multiple, scoped conftest.py modules? I wanted to report this as it appears to be a regression from 2.2. The changelog should probably mention it (or if it already does, highlight the impact as I've described) if it is not supported. Do you have any other suggestions?


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Fri Oct  5 23:46:30 2012
From: issues-reply at bitbucket.org (Anonymous)
Date: Fri, 05 Oct 2012 21:46:30 -0000
Subject: [py-dev] [hpk42/pytest] Marks don't pick up nested classes (issue
	#199)
Message-ID: <88d1a8cafe565f47fe0efb3bf4933a13@bitbucket.org>

--- you can reply above this line ---

New issue 199: Marks don't pick up nested classes
https://bitbucket.org/hpk42/pytest/issue/199/marks-dont-pick-up-nested-classes

Anonymous:

example:

{{{
#!python

@pytest.mark.a
class TestA:
    def test_b(self):
        assert True
    class TestC:
        def test_d(self):
            assert True
}}}

---
{{{
#!bash

$ py.test example.py -m a
}}}
only test_b is run. Not test_d


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From flub at devork.be  Sat Oct  6 00:42:11 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 5 Oct 2012 23:42:11 +0100
Subject: [py-dev] Autoactive fixtures
Message-ID: <CAAWk_Dx9u2rOVCSU2YqZdhBRkJz9=jBtcPFmGp+RJ-1AqwMV2Q@mail.gmail.com>

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.

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.

What do you think the correct behaviour should be?  I realise changing
this could be hard/ugly.

Regards,
Floris


From holger at merlinux.eu  Sat Oct  6 01:02:10 2012
From: holger at merlinux.eu (holger krekel)
Date: Fri, 5 Oct 2012 23:02:10 +0000
Subject: [py-dev] Autoactive fixtures
In-Reply-To: <CAAWk_Dx9u2rOVCSU2YqZdhBRkJz9=jBtcPFmGp+RJ-1AqwMV2Q@mail.gmail.com>
References: <CAAWk_Dx9u2rOVCSU2YqZdhBRkJz9=jBtcPFmGp+RJ-1AqwMV2Q@mail.gmail.com>
Message-ID: <20121005230210.GU27773@merlinux.eu>

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.

cheers,
holger

> Regards,
> Floris
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From flub at devork.be  Sat Oct  6 02:08:11 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 6 Oct 2012 01:08:11 +0100
Subject: [py-dev] Autoactive fixtures
In-Reply-To: <20121005230210.GU27773@merlinux.eu>
References: <CAAWk_Dx9u2rOVCSU2YqZdhBRkJz9=jBtcPFmGp+RJ-1AqwMV2Q@mail.gmail.com>
	<20121005230210.GU27773@merlinux.eu>
Message-ID: <CAAWk_DzhiQjT+8aFXkEvc_OW7SLe-nYMG7wW-t7SEsHgVCn8Hg@mail.gmail.com>

On 6 October 2012 00:02, holger krekel <holger at 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?


From holger at merlinux.eu  Sat Oct  6 08:55:07 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 6 Oct 2012 06:55:07 +0000
Subject: [py-dev] Autoactive fixtures
In-Reply-To: <CAAWk_DzhiQjT+8aFXkEvc_OW7SLe-nYMG7wW-t7SEsHgVCn8Hg@mail.gmail.com>
References: <CAAWk_Dx9u2rOVCSU2YqZdhBRkJz9=jBtcPFmGp+RJ-1AqwMV2Q@mail.gmail.com>
	<20121005230210.GU27773@merlinux.eu>
	<CAAWk_DzhiQjT+8aFXkEvc_OW7SLe-nYMG7wW-t7SEsHgVCn8Hg@mail.gmail.com>
Message-ID: <20121006065507.GV27773@merlinux.eu>

On Sat, Oct 06, 2012 at 01:08 +0100, Floris Bruynooghe wrote:
> On 6 October 2012 00:02, holger krekel <holger at 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


From issues-reply at bitbucket.org  Tue Oct  9 02:33:10 2012
From: issues-reply at bitbucket.org (astrofrog)
Date: Tue, 09 Oct 2012 00:33:10 -0000
Subject: [py-dev] [hpk42/pytest] disable the creation of the __pycache__
	directory (issue #200)
Message-ID: <e8f26cf4c547dc99c945e50e4a6f6f78@bitbucket.org>

--- you can reply above this line ---

New issue 200: disable the creation of the __pycache__ directory
https://bitbucket.org/hpk42/pytest/issue/200/disable-the-creation-of-the-__pycache__

astrofrog:

Is there a way to disable the creation of the __pycache__ directories, or cleanup these directories after testing, without installing any plugin or other packages?


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Tue Oct  9 08:40:42 2012
From: holger at merlinux.eu (holger krekel)
Date: Tue, 9 Oct 2012 06:40:42 +0000
Subject: [py-dev] [hpk42/pytest] disable the creation of the __pycache__
 directory (issue #200)
In-Reply-To: <e8f26cf4c547dc99c945e50e4a6f6f78@bitbucket.org>
References: <e8f26cf4c547dc99c945e50e4a6f6f78@bitbucket.org>
Message-ID: <20121009064042.GZ27773@merlinux.eu>

On Tue, Oct 09, 2012 at 00:33 -0000, astrofrog wrote:
> --- you can reply above this line ---
> 
> New issue 200: disable the creation of the __pycache__ directory
> https://bitbucket.org/hpk42/pytest/issue/200/disable-the-creation-of-the-__pycache__
> 
> astrofrog:
> 
> Is there a way to disable the creation of the __pycache__ directories, or cleanup these directories after testing, without installing any plugin or other packages?

Try setting the environment variable PYTHONDONTWRITEBYTECODE to some value.
This is a generic Python Interpreter setting.

best,
holger



From holger at merlinux.eu  Tue Oct  9 14:49:47 2012
From: holger at merlinux.eu (holger krekel)
Date: Tue, 9 Oct 2012 12:49:47 +0000
Subject: [py-dev] pytest-2.3 release finalization / little help appreciated
Message-ID: <20121009124947.GE27773@merlinux.eu>

Hi all,

a quick heads up: i am trying hard to finalize the pytest-2.3 release.
Help appreciated as documementation and code are starting to be up to a
release (i hope).  What you could do is:

* read http://pytest.org/dev/fixture.html and give feedback
  on readability and sense.

* try installing the release candidate with 

    pip install -i http://pypi.testrun.org -U pytest

  and see if your pytest-using project continues to work unchanged

* try out the new features and find something that is broken
  (you get a beer the next time i see you if you do find something :)

For the record, here are some decisions since the last discussions
here and on IRC a few weeks ago::

- @pytest.fixture() is now the name for defining fixture functions.
  Apart from the usual funcarg usage you can now also use a
  @pytest.mark.usefixtures(fixture1, fixture2, ...) marker 
  on classes to make a fixture function get called.

- @pytest.setup() is gone and is now an "autoactive" fixture - i.e.
  @pytest.fixture(autoactive=True).  It's not a simple spelling
  but it is recommended and expected that using default fixtures
  and refering them explicitely with a funcarg or a "usefixtures"
  markers is anyway better.
  
Catch me on IRC or here on the list for feedback or discussion.

cheers and many thanks to Floris in particular who endured a lot
of variations of the above features, helping much to evolve things
to where they currently stand.

best,

holger
  


From basti at redtoad.de  Thu Oct 11 11:47:03 2012
From: basti at redtoad.de (Sebastian Rahlf)
Date: Thu, 11 Oct 2012 11:47:03 +0200
Subject: [py-dev] Using funcargs with decorators
Message-ID: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>

Hi!

At work we use a decorator @rollback on selected test functions which
will rollback any db changes made during that test.

I've recently started using pytest's dependency injection for a few
use cases, both with @pytest.mark.parametrize(...) and the
pytest_funcarg__XXX hook.
Unfortunately, this clashes with our decorated test functions.

How can I make this work?

My first idea was using a custom marker, say @pytest.mark.rollback and
do something like:

def rollback(meth):
    """Original rollback function"""
    ...

def pytest_runtest_setup(item):
    if not isinstance(item, pytest.Function):
        return
    if hasattr(item.obj, 'rollback'):
        item = rollback(item)

Would an approach like this actually work?
Sebastian

P.S. I've posted this to stackoverflow before I remembered that there
is a mailing list
http://stackoverflow.com/questions/12836134/pytest-using-dependency-injection-with-decorators


From holger at merlinux.eu  Thu Oct 11 12:30:36 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 11 Oct 2012 10:30:36 +0000
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
Message-ID: <20121011103036.GL27773@merlinux.eu>

Hi Sebastian,

On Thu, Oct 11, 2012 at 11:47 +0200, Sebastian Rahlf wrote:
> Hi!
> 
> At work we use a decorator @rollback on selected test functions which
> will rollback any db changes made during that test.
> 
> I've recently started using pytest's dependency injection for a few
> use cases, both with @pytest.mark.parametrize(...) and the
> pytest_funcarg__XXX hook.
> Unfortunately, this clashes with our decorated test functions.
> 
> How can I make this work?
> 
> My first idea was using a custom marker, say @pytest.mark.rollback and
> do something like:
> 
> def rollback(meth):
>     """Original rollback function"""
>     ...
> 
> def pytest_runtest_setup(item):
>     if not isinstance(item, pytest.Function):
>         return
>     if hasattr(item.obj, 'rollback'):
>         item = rollback(item)
> 
> Would an approach like this actually work?

I think so - probably you need to call "rollback(item.obj") though.

> Sebastian
> 
> P.S. I've posted this to stackoverflow before I remembered that there
> is a mailing list
> http://stackoverflow.com/questions/12836134/pytest-using-dependency-injection-with-decorators

I answered there as well.

best,
holger


_______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From basti at redtoad.de  Thu Oct 11 14:44:15 2012
From: basti at redtoad.de (Sebastian Rahlf)
Date: Thu, 11 Oct 2012 14:44:15 +0200
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <20121011103036.GL27773@merlinux.eu>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
Message-ID: <CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>

Hi Holger!

>> At work we use a decorator @rollback on selected test functions which
>> will rollback any db changes made during that test.
>>
>> I've recently started using pytest's dependency injection for a few
>> use cases, both with @pytest.mark.parametrize(...) and the
>> pytest_funcarg__XXX hook.
>> Unfortunately, this clashes with our decorated test functions.
>>
>> How can I make this work?
>>
>> My first idea was using a custom marker, say @pytest.mark.rollback and
>> do something like:
>>
>> def rollback(meth):
>>     """Original rollback function"""
>>     ...
>>
>> def pytest_runtest_setup(item):
>>     if not isinstance(item, pytest.Function):
>>         return
>>     if hasattr(item.obj, 'rollback'):
>>         item = rollback(item)
>>
>> Would an approach like this actually work?
>
> I think so - probably you need to call "rollback(item.obj") though.

Thanks for your feedback. I've tried it again with the following code:

# conftest.py
import pytest
from unittests import rollback

def pytest_configure(config):
    # register an additional marker
    config.addinivalue_line("markers",
        "rollback: rollback any db changes after test")

def pytest_runtest_setup(item):
    if not isinstance(item, pytest.Function):
        return
    if hasattr(item.obj, 'rollback'):
        item.obj = rollback(item.obj)

# test_my_tests.py

import pytest

@pytest.mark.rollback
def test_rollback(monkepatch):
    # ...
    assert True

What I get is a "TypeError: test_rollback() takes exactly 1 argument (0 given)".
How can I make this work?

Cheers,
Seb.


From holger at merlinux.eu  Thu Oct 11 15:16:56 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 11 Oct 2012 13:16:56 +0000
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
Message-ID: <20121011131656.GN27773@merlinux.eu>

Hi Sebastian,

On Thu, Oct 11, 2012 at 14:44 +0200, Sebastian Rahlf wrote:
> Hi Holger!
> 
> >> At work we use a decorator @rollback on selected test functions which
> >> will rollback any db changes made during that test.
> >>
> >> I've recently started using pytest's dependency injection for a few
> >> use cases, both with @pytest.mark.parametrize(...) and the
> >> pytest_funcarg__XXX hook.
> >> Unfortunately, this clashes with our decorated test functions.
> >>
> >> How can I make this work?
> >>
> >> My first idea was using a custom marker, say @pytest.mark.rollback and
> >> do something like:
> >>
> >> def rollback(meth):
> >>     """Original rollback function"""
> >>     ...
> >>
> >> def pytest_runtest_setup(item):
> >>     if not isinstance(item, pytest.Function):
> >>         return
> >>     if hasattr(item.obj, 'rollback'):
> >>         item = rollback(item)
> >>
> >> Would an approach like this actually work?
> >
> > I think so - probably you need to call "rollback(item.obj") though.
> 
> Thanks for your feedback. I've tried it again with the following code:
> 
> # conftest.py
> import pytest
> from unittests import rollback
> 
> def pytest_configure(config):
>     # register an additional marker
>     config.addinivalue_line("markers",
>         "rollback: rollback any db changes after test")
> 
> def pytest_runtest_setup(item):
>     if not isinstance(item, pytest.Function):
>         return
>     if hasattr(item.obj, 'rollback'):
>         item.obj = rollback(item.obj)
> 
> # test_my_tests.py
> 
> import pytest
> 
> @pytest.mark.rollback
> def test_rollback(monkepatch):
>     # ...
>     assert True
> 
> What I get is a "TypeError: test_rollback() takes exactly 1 argument (0 given)".
> How can I make this work?

ah, now i get it.  You want to assign the function back.
That is indeed not going to work as pytest then sees the rollback
function (i assume you return another function from this decorator).
What is the decorator-returned function doing?  

Did you check out the transact example in
http://pytest.org/dev/fixture.html that i referenced in the
stackoverflow anwser?

best,
holger


From anto.cuni at gmail.com  Thu Oct 11 22:10:09 2012
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Thu, 11 Oct 2012 22:10:09 +0200
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <20121011131656.GN27773@merlinux.eu>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
	<20121011131656.GN27773@merlinux.eu>
Message-ID: <507727A1.9070305@gmail.com>

Hi Holger, Sebastian,

On 10/11/2012 03:16 PM, holger krekel wrote:
> ah, now i get it.  You want to assign the function back.
> That is indeed not going to work as pytest then sees the rollback
> function (i assume you return another function from this decorator).
> What is the decorator-returned function doing?  

I admit I did not follow the discussion deeply. However, if the problem is
that py.test sees the decorated function (which presumably uses *args and
**kwargs) instead of the original one, it can be solved by using the same
technique I used for enforceargs in pypy:

https://bitbucket.org/pypy/pypy/src/7f6d5c878b90/pypy/rlib/objectmodel.py#cl-170

in practice, the trick is to exec() a function def with the correct argument
list instead of just relying on *args, **kwargs. This way, py.test should be
able to find the correct signature.

ciao,
anto


From holger at merlinux.eu  Thu Oct 11 23:53:27 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 11 Oct 2012 21:53:27 +0000
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <507727A1.9070305@gmail.com>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
	<20121011131656.GN27773@merlinux.eu> <507727A1.9070305@gmail.com>
Message-ID: <20121011215327.GO27773@merlinux.eu>

Hi Anto,

On Thu, Oct 11, 2012 at 22:10 +0200, Antonio Cuni wrote:
> Hi Holger, Sebastian,
> 
> On 10/11/2012 03:16 PM, holger krekel wrote:
> > ah, now i get it.  You want to assign the function back.
> > That is indeed not going to work as pytest then sees the rollback
> > function (i assume you return another function from this decorator).
> > What is the decorator-returned function doing?  
> 
> I admit I did not follow the discussion deeply. However, if the problem is
> that py.test sees the decorated function (which presumably uses *args and
> **kwargs) instead of the original one, it can be solved by using the same
> technique I used for enforceargs in pypy:
> 
> https://bitbucket.org/pypy/pypy/src/7f6d5c878b90/pypy/rlib/objectmodel.py#cl-170
> 
> in practice, the trick is to exec() a function def with the correct argument
> list instead of just relying on *args, **kwargs. This way, py.test should be
> able to find the correct signature.

I agree that is one way to solve it.  However, if "hiding" the
function can be avoided alltogether, then it's even better.

On a sidenote, i am not sure Python's decorator design was such
a great idea.  Maybe it should have been restricted to setting attributes
(like C# and also java IIRC) and then a way to get those attributed
functions on a per-class, per-module or even global basis.

best,
holger


From anto.cuni at gmail.com  Fri Oct 12 11:11:41 2012
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Fri, 12 Oct 2012 11:11:41 +0200
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <20121011215327.GO27773@merlinux.eu>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
	<20121011131656.GN27773@merlinux.eu> <507727A1.9070305@gmail.com>
	<20121011215327.GO27773@merlinux.eu>
Message-ID: <5077DECD.3070201@gmail.com>

On 10/11/2012 11:53 PM, holger krekel wrote:
> 
> On a sidenote, i am not sure Python's decorator design was such
> a great idea.  Maybe it should have been restricted to setting attributes
> (like C# and also java IIRC) and then a way to get those attributed
> functions on a per-class, per-module or even global basis.

well, there are obviously things which you can't do by just setting
attributes, and moreover nothing would stop people to do the old "fn =
decor(fn)" trick.

I think that in general the *args, **kwargs pattern works well enough. The
only two drawbacks I can see in day-to-day usage are:

- that the name of the decorated function is different than the original one,
although nowadays we have @functools.wraps (but it's still not widely used).

- that decorators are not composable is one wraps and the other sets an
attribute: depending on the order they are applied we might set the attribute
on the wrapper or wrapped object.

For more advanced usages, it would be nice to have an automatic way to "copy"
the signature from the wrapped to the wrapper: this alone would solve both the
pypy and the OP problems.

Additional bonus: a standard way to declare (via a function attribute) that
this function object is a wrapper for this other, to be used e.g. by debuggers
to show the "correct" source code. E.g., I have a "source" command in pdb++
which breaks in case of wrappers:

@mydecor
def foo(...):
    ...

(pdb++) source foo
def mydecor(fn):
    def wrapped(*args, **kwargs):
        return fn(*args, **kwargs)
    return wrapped

ciao,
Anto


From flub at devork.be  Fri Oct 12 18:50:14 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Fri, 12 Oct 2012 17:50:14 +0100
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <5077DECD.3070201@gmail.com>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
	<20121011131656.GN27773@merlinux.eu> <507727A1.9070305@gmail.com>
	<20121011215327.GO27773@merlinux.eu> <5077DECD.3070201@gmail.com>
Message-ID: <CAAWk_DwViMCJGPYh5DAAwvuoAkC-+eyxWYby2kRLDuWaRGzx5A@mail.gmail.com>

On 12 October 2012 10:11, Antonio Cuni <anto.cuni at gmail.com> wrote:
> On 10/11/2012 11:53 PM, holger krekel wrote:
>>
>> On a sidenote, i am not sure Python's decorator design was such
>> a great idea.  Maybe it should have been restricted to setting attributes
>> (like C# and also java IIRC) and then a way to get those attributed
>> functions on a per-class, per-module or even global basis.
>
> well, there are obviously things which you can't do by just setting
> attributes, and moreover nothing would stop people to do the old "fn =
> decor(fn)" trick.
>
> I think that in general the *args, **kwargs pattern works well enough. The
> only two drawbacks I can see in day-to-day usage are:
>
> - that the name of the decorated function is different than the original one,
> although nowadays we have @functools.wraps (but it's still not widely used).
>
> - that decorators are not composable is one wraps and the other sets an
> attribute: depending on the order they are applied we might set the attribute
> on the wrapper or wrapped object.

Are these being addressed by PEP 362?  I must admit I haven't had time
to read this yet, but if functools.wraps gets updated it was my
understanding that the *args, **kwargs inspection issue should be
solved and if you can set attributes on the signature object it could
stay persistent in the face of composition of decorators?


Regards,
Floris


From issues-reply at bitbucket.org  Sat Oct 13 14:34:20 2012
From: issues-reply at bitbucket.org (Anonymous)
Date: Sat, 13 Oct 2012 12:34:20 -0000
Subject: [py-dev] [hpk42/pytest-cache] --clearcache fails if there is no
 .cache directory (issue #6)
Message-ID: <fd3a8af636d7758c4ce8831215873185@bitbucket.org>

--- you can reply above this line ---

New issue 6: --clearcache fails if there is no .cache directory
https://bitbucket.org/hpk42/pytest-cache/issue/6/clearcache-fails-if-there-is-no-cache

Anonymous:

When using the --clearcache option it fails when the .cache directory doesn't exist.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Sun Oct 14 12:15:19 2012
From: issues-reply at bitbucket.org (Sebastian Rahlf)
Date: Sun, 14 Oct 2012 10:15:19 -0000
Subject: [py-dev] [hpk42/pytest] conflicting option string(s): --fixtures
	(issue #201)
Message-ID: <186513b484f89f1fb5b73f02337e504f@bitbucket.org>

--- you can reply above this line ---

New issue 201: conflicting option string(s): --fixtures
https://bitbucket.org/hpk42/pytest/issue/201/conflicting-option-string-s-fixtures

Sebastian Rahlf:

I've tried to use the new fixtures feature of the upcoming version 2.3 and ran into this problem:

    #!pytb
    Traceback (most recent call last):
      File "/home/sebrah/.virtualenvs/tmp/bin/py.test", line 8, in <module>
        load_entry_point('pytest==2.3.0.dev23', 'console_scripts', 'py.test')()
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 473, in main
        config = _prepareconfig(args, plugins)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 463, in _prepareconfig
        pluginmanager=_pluginmanager, args=args)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 422, in __call__
        return self._docall(methods, kwargs)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 433, in _docall
        res = mc.execute()
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 351, in execute
        res = method(**kwargs)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/helpconfig.py", line 25, in pytest_cmdline_parse
        config = __multicall__.execute()
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/core.py", line 351, in execute
        res = method(**kwargs)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/config.py", line 10, in pytest_cmdline_parse
        config.parse(args)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/config.py", line 346, in parse
        args = self._parser.parse_setoption(args, self.option)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/config.py", line 72, in parse_setoption
        parsedoption, args = self.parse(args)
      File "/home/sebrah/.virtualenvs/tmp/lib/python2.7/site-packages/_pytest/config.py", line 67, in parse
        optgroup.add_options(group.options)
      File "/shared/prod/rhel6/python-2.7.1/lib/python2.7/optparse.py", line 1039, in add_options
        self.add_option(option)
      File "/shared/prod/rhel6/python-2.7.1/lib/python2.7/optparse.py", line 1020, in add_option
        self._check_conflict(option)
      File "/shared/prod/rhel6/python-2.7.1/lib/python2.7/optparse.py", line 995, in _check_conflict
        option)
    optparse.OptionConflictError: option -F/--fixtures: conflicting option string(s): --fixtures



--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From anto.cuni at gmail.com  Mon Oct 15 10:05:48 2012
From: anto.cuni at gmail.com (Antonio Cuni)
Date: Mon, 15 Oct 2012 10:05:48 +0200
Subject: [py-dev] Using funcargs with decorators
In-Reply-To: <CAAWk_DwViMCJGPYh5DAAwvuoAkC-+eyxWYby2kRLDuWaRGzx5A@mail.gmail.com>
References: <CAAQWEJ2c_UQuPGxYfVvMYm550qiga_Xb1hCKLW0WG4u4FuGPSg@mail.gmail.com>
	<20121011103036.GL27773@merlinux.eu>
	<CAAQWEJ3aZr-uHH0cbtQGtYqBLL-9LdZUQNff7ROfvLH8bowxiw@mail.gmail.com>
	<20121011131656.GN27773@merlinux.eu> <507727A1.9070305@gmail.com>
	<20121011215327.GO27773@merlinux.eu> <5077DECD.3070201@gmail.com>
	<CAAWk_DwViMCJGPYh5DAAwvuoAkC-+eyxWYby2kRLDuWaRGzx5A@mail.gmail.com>
Message-ID: <507BC3DC.9030108@gmail.com>

On 10/12/2012 06:50 PM, Floris Bruynooghe wrote:
> Are these being addressed by PEP 362?  I must admit I haven't had time
> to read this yet, but if functools.wraps gets updated it was my
> understanding that the *args, **kwargs inspection issue should be
> solved and if you can set attributes on the signature object it could
> stay persistent in the face of composition of decorators?

I was not aware of PEP 362, which seems a good step in that direction, but
indeed if functools.wraps does not update the signature automatically, it
won't be used much in practice I fear.

ciao,
Anto


From issues-reply at bitbucket.org  Fri Oct 19 06:46:49 2012
From: issues-reply at bitbucket.org (Brianna Laugher)
Date: Fri, 19 Oct 2012 04:46:49 -0000
Subject: [py-dev] [hpk42/pytest] Float numbers in parametrize are rendered
 wrongly in test name (issue #202)
Message-ID: <cf39b8a5ad6a5dedaa8fbc0c0b05969c@bitbucket.org>

--- you can reply above this line ---

New issue 202: Float numbers in parametrize are rendered wrongly in test name
https://bitbucket.org/hpk42/pytest/issue/202/float-numbers-in-parametrize-are-rendered

Brianna Laugher:

    #!python
    @py.test.mark.parametrize(("myInt", "myFloat"), [
        (1, 1.0),
        (2, 2.0),
    ])
    def test_floatsInTestNameAreStrange(myInt, myFloat):
    print
    print "myInt=", myInt
    print "myFloat=", myFloat
    assert myInt == myFloat


output:
   
    #!shell
    ===== test session starts =====
    test_foo.py:415: test_floatsInTestNameAreStrange[1-.1] 
    myInt= 1
    myFloat= 1.0
    PASSED
    test_foo.py:415: test_floatsInTestNameAreStrange[2-.3] 
    myInt= 2
    myFloat= 2.0
    PASSED


As you can see the correct values are received in the test, but for some reason 1.0 appears as ".1" in the test name, and 2.0 appears as ".3".

This is with py.test 2.2.3.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Fri Oct 19 11:44:55 2012
From: holger at merlinux.eu (holger krekel)
Date: Fri, 19 Oct 2012 09:44:55 +0000
Subject: [py-dev] pytest-2.3: improved fixtures/funcargs and unittest support
Message-ID: <20121019094455.GZ27773@merlinux.eu>

pytest-2.3: improved fixtures / better unittest integration
=============================================================================

pytest-2.3 comes with many major improvements for fixture/funcarg management
and parametrized testing in Python.  It is now easier, more efficient and
more predicatable to re-run the same tests with different fixture
instances.  Also, you can directly declare the caching "scope" of
fixtures so that dependent tests throughout your whole test suite can
re-use database or other expensive fixture objects with ease.  Lastly,
it's possible for fixture functions (formerly known as funcarg
factories) to use other fixtures, allowing for a completely modular and
re-useable fixture design.

For detailed info and tutorial-style examples, see:

    http://pytest.org/latest/fixture.html

Moreover, there is now support for using pytest fixtures/funcargs with
unittest-style suites, see here for examples:

    http://pytest.org/latest/unittest.html

Besides, more unittest-test suites are now expected to "simply work"
with pytest.

All changes are backward compatible and you should be able to continue
to run your test suites and 3rd party plugins that worked with
pytest-2.2.4.

If you are interested in the precise reasoning (including examples) of
the pytest-2.3 fixture evolution, please consult
http://pytest.org/latest/funcarg_compare.html

For general info on installation and getting started:

    http://pytest.org/latest/getting-started.html

Docs and PDF access as usual at:

    http://pytest.org

and more details for those already in the knowing of pytest can be found
in the CHANGELOG below.

Particular thanks for this release go to Floris Bruynooghe, Alex Okrushko
Carl Meyer, Ronny Pfannschmidt, Benjamin Peterson and Alex Gaynor for helping 
to get the new features right and well integrated.  Ronny and Floris
also helped to fix a number of bugs and yet more people helped by
providing bug reports.

have fun,
holger krekel


Changes between 2.2.4 and 2.3.0
-----------------------------------

- fix issue202 - better automatic names for parametrized test functions
- fix issue139 - introduce @pytest.fixture which allows direct scoping
  and parametrization of funcarg factories.  Introduce new @pytest.setup
  marker to allow the writing of setup functions which accept funcargs.
- fix issue198 - conftest fixtures were not found on windows32 in some
  circumstances with nested directory structures due to path manipulation issues
- fix issue193 skip test functions with were parametrized with empty
  parameter sets
- fix python3.3 compat, mostly reporting bits that previously depended
  on dict ordering
- introduce re-ordering of tests by resource and parametrization setup
  which takes precedence to the usual file-ordering
- fix issue185 monkeypatching time.time does not cause pytest to fail
- fix issue172 duplicate call of pytest.setup-decoratored setup_module
  functions
- fix junitxml=path construction so that if tests change the
  current working directory and the path is a relative path
  it is constructed correctly from the original current working dir.
- fix "python setup.py test" example to cause a proper "errno" return
- fix issue165 - fix broken doc links and mention stackoverflow for FAQ
- catch unicode-issues when writing failure representations
  to terminal to prevent the whole session from crashing
- fix xfail/skip confusion: a skip-mark or an imperative pytest.skip
  will now take precedence before xfail-markers because we
  can't determine xfail/xpass status in case of a skip. see also:
  http://stackoverflow.com/questions/11105828/in-py-test-when-i-explicitly-skip-a-test-that-is-marked-as-xfail-how-can-i-get

- always report installed 3rd party plugins in the header of a test run

- fix issue160: a failing setup of an xfail-marked tests should
  be reported as xfail (not xpass)

- fix issue128: show captured output when capsys/capfd are used

- fix issue179: propperly show the dependency chain of factories

- pluginmanager.register(...) now raises ValueError if the
  plugin has been already registered or the name is taken

- fix issue159: improve http://pytest.org/latest/faq.html 
  especially with respect to the "magic" history, also mention
  pytest-django, trial and unittest integration.

- make request.keywords and node.keywords writable.  All descendant
  collection nodes will see keyword values.  Keywords are dictionaries
  containing markers and other info.

- fix issue 178: xml binary escapes are now wrapped in py.xml.raw

- fix issue 176: correctly catch the builtin AssertionError
  even when we replaced AssertionError with a subclass on the
  python level

- factory discovery no longer fails with magic global callables
  that provide no sane __code__ object (mock.call for example)

- fix issue 182: testdir.inprocess_run now considers passed plugins

- fix issue 188: ensure sys.exc_info is clear on python2
                 before calling into a test

- fix issue 191: add unittest TestCase runTest method support
- fix issue 156: monkeypatch correctly handles class level descriptors

- reporting refinements:

  - pytest_report_header now receives a "startdir" so that
    you can use startdir.bestrelpath(yourpath) to show
    nice relative path

  - allow plugins to implement both pytest_report_header and 
    pytest_sessionstart (sessionstart is invoked first).

  - don't show deselected reason line if there is none

  - py.test -vv will show all of assert comparisations instead of truncating



From issues-reply at bitbucket.org  Fri Oct 19 23:17:26 2012
From: issues-reply at bitbucket.org (eduardo schettino)
Date: Fri, 19 Oct 2012 21:17:26 -0000
Subject: [py-dev] [hpk42/pytest] funcarg/fixture uses a different reference
 to object (issue #203)
Message-ID: <f219dc38b81a8a2d86f7280833c3a302@bitbucket.org>

--- you can reply above this line ---

New issue 203: funcarg/fixture uses a different reference to object
https://bitbucket.org/hpk42/pytest/issue/203/funcarg-fixture-uses-a-different-reference

eduardo schettino:

Something like this (using old funcargs) used to work on 2.2
but now fails on 2.3.

    #!python
    import pytest

    class TestClass:
        @pytest.fixture()
        def my_setup(self, request):
            self.foo = True

        def test_method1(self, my_setup):
           assert self.foo


The object instance used to run the test is different from
the instance used to calculate the value of the fixture.
So modification to "self" in the fixture are lost.





--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Sat Oct 20 14:37:35 2012
From: holger at merlinux.eu (holger krekel)
Date: Sat, 20 Oct 2012 12:37:35 +0000
Subject: [py-dev] 2.3.1: regression and freebsd fixes
In-Reply-To: <20121019094455.GZ27773@merlinux.eu>
References: <20121019094455.GZ27773@merlinux.eu>
Message-ID: <20121020123735.GC27773@merlinux.eu>


Did a quick 2.3.1 with some fixes:

- fix issue202 - regression with fixture functions/funcarg factories:  
  using "self" with class-level fixtures is now safe again and works as
  in 2.2.4.  Thanks to Eduard Schettino for the quick bug report.

- disable pexpect pytest self tests on Freebsd - thanks Koob for the 
  quick reporting

- fix/improve interactive docs with --markers

I am planning to do further quick regression-fixing minor 2.3.* releases
if neccessary - not going to announce each of them, though.

So make sure you have the newest version with e. g. "pip install -U pytest"
and keep the bug reports flowing :)

best,
holger



Changes between 2.3.0 and 2.3.1
-----------------------------------

- fix issue202 - fix regression: using "self" from fixture functions now
  works as expected (it's the same "self" instance that a test method
  which uses the fixture sees)

- skip pexpect using tests (test_pdb.py mostly) on freebsd* systems
  due to pexpect not supporting it properly (hanging)

- link to web pages from --markers output which provides help for
  pytest.mark.* usage.
On Fri, Oct 19, 2012 at 09:44 +0000, holger krekel wrote:
> pytest-2.3: improved fixtures / better unittest integration
> =============================================================================
> 
> pytest-2.3 comes with many major improvements for fixture/funcarg management
> and parametrized testing in Python.  It is now easier, more efficient and
> more predicatable to re-run the same tests with different fixture
> instances.  Also, you can directly declare the caching "scope" of
> fixtures so that dependent tests throughout your whole test suite can
> re-use database or other expensive fixture objects with ease.  Lastly,
> it's possible for fixture functions (formerly known as funcarg
> factories) to use other fixtures, allowing for a completely modular and
> re-useable fixture design.
> 
> For detailed info and tutorial-style examples, see:
> 
>     http://pytest.org/latest/fixture.html
> 
> Moreover, there is now support for using pytest fixtures/funcargs with
> unittest-style suites, see here for examples:
> 
>     http://pytest.org/latest/unittest.html
> 
> Besides, more unittest-test suites are now expected to "simply work"
> with pytest.
> 
> All changes are backward compatible and you should be able to continue
> to run your test suites and 3rd party plugins that worked with
> pytest-2.2.4.
> 
> If you are interested in the precise reasoning (including examples) of
> the pytest-2.3 fixture evolution, please consult
> http://pytest.org/latest/funcarg_compare.html
> 
> For general info on installation and getting started:
> 
>     http://pytest.org/latest/getting-started.html
> 
> Docs and PDF access as usual at:
> 
>     http://pytest.org
> 
> and more details for those already in the knowing of pytest can be found
> in the CHANGELOG below.
> 
> Particular thanks for this release go to Floris Bruynooghe, Alex Okrushko
> Carl Meyer, Ronny Pfannschmidt, Benjamin Peterson and Alex Gaynor for helping 
> to get the new features right and well integrated.  Ronny and Floris
> also helped to fix a number of bugs and yet more people helped by
> providing bug reports.
> 
> have fun,
> holger krekel
> 
> 
> Changes between 2.2.4 and 2.3.0
> -----------------------------------
> 
> - fix issue202 - better automatic names for parametrized test functions
> - fix issue139 - introduce @pytest.fixture which allows direct scoping
>   and parametrization of funcarg factories.  Introduce new @pytest.setup
>   marker to allow the writing of setup functions which accept funcargs.
> - fix issue198 - conftest fixtures were not found on windows32 in some
>   circumstances with nested directory structures due to path manipulation issues
> - fix issue193 skip test functions with were parametrized with empty
>   parameter sets
> - fix python3.3 compat, mostly reporting bits that previously depended
>   on dict ordering
> - introduce re-ordering of tests by resource and parametrization setup
>   which takes precedence to the usual file-ordering
> - fix issue185 monkeypatching time.time does not cause pytest to fail
> - fix issue172 duplicate call of pytest.setup-decoratored setup_module
>   functions
> - fix junitxml=path construction so that if tests change the
>   current working directory and the path is a relative path
>   it is constructed correctly from the original current working dir.
> - fix "python setup.py test" example to cause a proper "errno" return
> - fix issue165 - fix broken doc links and mention stackoverflow for FAQ
> - catch unicode-issues when writing failure representations
>   to terminal to prevent the whole session from crashing
> - fix xfail/skip confusion: a skip-mark or an imperative pytest.skip
>   will now take precedence before xfail-markers because we
>   can't determine xfail/xpass status in case of a skip. see also:
>   http://stackoverflow.com/questions/11105828/in-py-test-when-i-explicitly-skip-a-test-that-is-marked-as-xfail-how-can-i-get
> 
> - always report installed 3rd party plugins in the header of a test run
> 
> - fix issue160: a failing setup of an xfail-marked tests should
>   be reported as xfail (not xpass)
> 
> - fix issue128: show captured output when capsys/capfd are used
> 
> - fix issue179: propperly show the dependency chain of factories
> 
> - pluginmanager.register(...) now raises ValueError if the
>   plugin has been already registered or the name is taken
> 
> - fix issue159: improve http://pytest.org/latest/faq.html 
>   especially with respect to the "magic" history, also mention
>   pytest-django, trial and unittest integration.
> 
> - make request.keywords and node.keywords writable.  All descendant
>   collection nodes will see keyword values.  Keywords are dictionaries
>   containing markers and other info.
> 
> - fix issue 178: xml binary escapes are now wrapped in py.xml.raw
> 
> - fix issue 176: correctly catch the builtin AssertionError
>   even when we replaced AssertionError with a subclass on the
>   python level
> 
> - factory discovery no longer fails with magic global callables
>   that provide no sane __code__ object (mock.call for example)
> 
> - fix issue 182: testdir.inprocess_run now considers passed plugins
> 
> - fix issue 188: ensure sys.exc_info is clear on python2
>                  before calling into a test
> 
> - fix issue 191: add unittest TestCase runTest method support
> - fix issue 156: monkeypatch correctly handles class level descriptors
> 
> - reporting refinements:
> 
>   - pytest_report_header now receives a "startdir" so that
>     you can use startdir.bestrelpath(yourpath) to show
>     nice relative path
> 
>   - allow plugins to implement both pytest_report_header and 
>     pytest_sessionstart (sessionstart is invoked first).
> 
>   - don't show deselected reason line if there is none
> 
>   - py.test -vv will show all of assert comparisations instead of truncating
> 
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev
> 


From issues-reply at bitbucket.org  Sat Oct 20 16:28:26 2012
From: issues-reply at bitbucket.org (Alexander Schepanovski)
Date: Sat, 20 Oct 2012 14:28:26 -0000
Subject: [py-dev] [hpk42/pytest] Can't change python_files from
	pytest_cnfigure() (issue #204)
Message-ID: <e9053e2b2ecb4a25ffc5bfc6e9bb994a@bitbucket.org>

--- you can reply above this line ---

New issue 204: Can't change python_files from pytest_cnfigure()
https://bitbucket.org/hpk42/pytest/issue/204/cant-change-python_files-from

Alexander Schepanovski:

Here is my conftest.py

    #!python
    def pytest_addoption(parser):
        parser.addoption('--bench',
               action="store_true", dest="bench", default=False,
               help=("Enable benchmark mode"))

    def pytest_configure(config):
        if config.getvalue("bench"):
            config.addinivalue_line("python_files", "bench_*.py") # Problem here

and it raises AssertError.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From ralf at systemexit.de  Mon Oct 22 00:53:45 2012
From: ralf at systemexit.de (Ralf Schmitt)
Date: Mon, 22 Oct 2012 00:53:45 +0200
Subject: [py-dev] pytest-twisted 1.0
Message-ID: <874nlncu86.fsf@myhost.lan>

Hi,

I've upload pytest-twisted to pypi [1]. It's a plugin which allows to test
twisted code with pytest. The code is also available on github [2].


[1] http://pypi.python.org/pypi/pytest-twisted
[2] https://github.com/schmir/pytest-twisted

-- 
Cheers
Ralf


From issues-reply at bitbucket.org  Mon Oct 22 05:18:18 2012
From: issues-reply at bitbucket.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 22 Oct 2012 03:18:18 -0000
Subject: [py-dev] [hpk42/pytest] Test failure with Python 2.5 (issue #205)
Message-ID: <bf502a7b33f4b00a80d2cb684dc84045@bitbucket.org>

--- you can reply above this line ---

New issue 205: Test failure with Python 2.5
https://bitbucket.org/hpk42/pytest/issue/205/test-failure-with-python-25

Arfrever Frehtes Taifersar Arahesis:

This problem was introduced in pytest 2.3.0.
Results for pytest hg tip:

{{{
$ python2.5 pytest.py
==================================================================== test session starts ====================================================================
platform linux2 -- Python 2.5.6 -- pytest-2.3.2.dev2
collected 816 items / 1 errors / 1 skipped 

doc/en/example/assertion/test_failures.py .
doc/en/example/assertion/test_setup_flow_example.py ..
doc/en/example/assertion/global_testmodule_config/test_hello.py .
doc/en/example/costlysetup/sub1/test_quick.py .
doc/en/example/costlysetup/sub2/test_two.py ..
doc/en/example/py2py3/test_py2.py .
testing/acceptance_test.py ......................................x.......
testing/test_assertinterpret.py ........ss..........s......
testing/test_assertion.py s............s.ssxs.....
testing/test_capture.py ..............x....................
testing/test_collection.py ...........x...................
testing/test_config.py ........x................
testing/test_conftest.py ..............................
testing/test_core.py ...................................................
testing/test_doctest.py .........
testing/test_genscript.py .....sss
testing/test_helpconfig.py ........
testing/test_junitxml.py ......................
testing/test_mark.py ...................ss..............
testing/test_monkeypatch.py ......................
testing/test_nose.py ssssssssss
testing/test_parseopt.py ............
testing/test_pastebin.py ...
testing/test_pdb.py ....sssssss.
testing/test_pytester.py x.......
testing/test_python.py ...................................................................................................................................x........................................
testing/test_recwarn.py ........
testing/test_resultlog.py .........
testing/test_runner.py .................sssssss..ssss.......x........
testing/test_runner_xunit.py ..........
testing/test_session.py ...............
testing/test_skipping.py ...................................
testing/test_terminal.py .......s.........................s............................
testing/test_tmpdir.py ......
testing/test_unittest.py ..................sss....s.

========================================================================== ERRORS ===========================================================================
____________________________________________________ ERROR collecting doc/en/example/py2py3/test_py3.py _____________________________________________________
_pytest/python.py:352: in _importtestmodule
>           mod = self.fspath.pyimport(ensuresyspath=True)
/usr/lib64/python2.5/site-packages/py/_path/local.py:532: in pyimport
>           __import__(modname)
E             File "/tmp/pytest/doc/en/example/py2py3/test_py3.py", line 5
E               except ZeroDivisionError as e:
E                                         ^
E           SyntaxError: invalid syntax
---------------------------------------------------------------------- Captured stderr ----------------------------------------------------------------------
/tmp/pytest/doc/en/example/py2py3/test_py3.py:5: Warning: 'as' will become a reserved keyword in Python 2.6
================================================================== short test summary info ==================================================================
XFAIL testing/acceptance_test.py::TestInvocationVariants::()::test_noclass_discovery_if_not_testcase
  decide: feature or bug
XFAIL testing/test_assertion.py::test_assert_compare_truncate_longmessage
  condition: sys.version_info < (2,6)
XFAIL testing/test_capture.py::TestPerTestCapturing::()::test_capture_scope_cache
XFAIL testing/test_collection.py::TestPrunetraceback::()::test_collect_report_postprocessing
  other mechanism for adding to reporting needed
XFAIL testing/test_config.py::TestParseIni::()::test_confcutdir
  probably not needed
XFAIL testing/test_pytester.py::test_reportrecorder
  reason: internal reportrecorder tests need refactoring
XFAIL testing/test_python.py::TestAutouseDiscovery::()::test_setup_enabled_functionnode
  'enabled' feature not implemented
XFAIL testing/test_runner.py::test_runtest_in_module_ordering
SKIP [8] /tmp/pytest/_pytest/pytester.py:530: could not import 'pexpect'
SKIP [1] /tmp/pytest/testing/conftest.py:109: no suitable jython found
SKIP [10] /tmp/pytest/_pytest/skipping.py:120: condition: sys.version_info < (2,6)
SKIP [2] /tmp/pytest/_pytest/core.py:121: plugin 'xdist' is missing
SKIP [1] /tmp/pytest/testing/test_assertrewrite.py:7: could not import 'ast'
SKIP [1] /tmp/pytest/testing/conftest.py:109: no suitable pypy found
SKIP [11] /tmp/pytest/testing/test_runner.py:277: could not import 'xdist.plugin'
SKIP [10] /tmp/pytest/testing/test_nose.py:4: could not import 'nose'
SKIP [1] /tmp/pytest/_pytest/skipping.py:120: condition: sys.version_info < (2,7)
SKIP [3] /tmp/pytest/testing/test_unittest.py:271: could not import 'twisted.trial.unittest'
=============================================== 761 passed, 48 skipped, 8 xfailed, 1 error in 131.09 seconds ================================================
}}}    


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Mon Oct 22 06:32:45 2012
From: issues-reply at bitbucket.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 22 Oct 2012 04:32:45 -0000
Subject: [py-dev] [hpk42/pytest] Test failure with disabled byte-compilation
	(issue #206)
Message-ID: <85e9a4e3bb181d29e2e0ea63b4c16f79@bitbucket.org>

--- you can reply above this line ---

New issue 206: Test failure with disabled byte-compilation
https://bitbucket.org/hpk42/pytest/issue/206/test-failure-with-disabled-byte

Arfrever Frehtes Taifersar Arahesis:

1 test failure occurs when byte-compilation is disabled (e.g. using PYTHONDONTWRITEBYTECODE environmental variable). This problem was introduced in pytest 2.3.0.

Results for pytest hg tip:

    $ PYTHONDONTWRITEBYTECODE="1" python2.7 pytest.py
    ============================= test session starts ==============================
    platform linux2 -- Python 2.7.4 -- pytest-2.3.2.dev2
    collected 839 items
    
    doc/en/example/assertion/test_failures.py .
    doc/en/example/assertion/test_setup_flow_example.py ..
    doc/en/example/assertion/global_testmodule_config/test_hello.py .
    doc/en/example/costlysetup/sub1/test_quick.py .
    doc/en/example/costlysetup/sub2/test_two.py ..
    doc/en/example/py2py3/test_py2.py .
    doc/en/example/py2py3/test_py3.py .
    testing/acceptance_test.py ......................................x.......
    testing/test_assertinterpret.py ..........................s
    testing/test_assertion.py ........................
    testing/test_assertrewrite.py ...................F..
    testing/test_capture.py ..............x....................
    testing/test_collection.py ...........x...................
    testing/test_config.py ........x................
    testing/test_conftest.py ..............................
    testing/test_core.py ...................................................
    testing/test_doctest.py .........
    testing/test_genscript.py .....sss
    testing/test_helpconfig.py ........
    testing/test_junitxml.py ......................
    testing/test_mark.py ...................................
    testing/test_monkeypatch.py ......................
    testing/test_nose.py ..........
    testing/test_parseopt.py ............
    testing/test_pastebin.py ...
    testing/test_pdb.py ............
    testing/test_pytester.py x.......
    testing/test_python.py ...................................................................................................................................x........................................
    testing/test_recwarn.py ........
    testing/test_resultlog.py .........
    testing/test_runner.py .................sssssss..ssss.......x........
    testing/test_runner_xunit.py ..........
    testing/test_session.py ...............
    testing/test_skipping.py ...................................
    testing/test_terminal.py .................................s............................
    testing/test_tmpdir.py ......
    testing/test_unittest.py ...........................
    
    =================================== FAILURES ===================================
    _____________________ TestRewriteOnImport.test_pyc_vs_pyo ______________________
    
    self = <test_assertrewrite.TestRewriteOnImport instance at 0x2cb5c20>
    testdir = <TmpTestdir local('/tmp/pytest-0/testdir/test_pyc_vs_pyo0/test_pyc_vs_pyo')>
    monkeypatch = <_pytest.monkeypatch.monkeypatch instance at 0x2cb5758>
    
        @pytest.mark.skipif('"__pypy__" in sys.modules')
        def test_pyc_vs_pyo(self, testdir, monkeypatch):
            testdir.makepyfile("""
        import pytest
        def test_optimized():
            "hello"
            assert test_optimized.__doc__ is None""")
            p = py.path.local.make_numbered_dir(prefix="runpytest-", keep=None,
                                                rootdir=testdir.tmpdir)
            tmp = "--basetemp=%s" % p
            monkeypatch.setenv("PYTHONOPTIMIZE", "2")
            assert testdir.runpybin("py.test", tmp).ret == 0
            tagged = "test_pyc_vs_pyo." + PYTEST_TAG
    >       assert tagged + ".pyo" in os.listdir("__pycache__")
    E       OSError: [Errno 2] No such file or directory: '__pycache__'
    
    /tmp/pytest/testing/test_assertrewrite.py:367: OSError
    ------------------------------- Captured stdout --------------------------------
    running ['/usr/bin/python2.7', '/tmp/pytest/pytest.py', '--basetemp=/tmp/pytest-0/testdir/test_pyc_vs_pyo0/test_pyc_vs_pyo/runpytest-0'] curdir= /tmp/pytest-0/testdir/test_pyc_vs_pyo0/test_pyc_vs_pyo
    ============================= test session starts ==============================
    platform linux2 -- Python 2.7.4 -- pytest-2.3.2.dev2
    collected 1 items
    
    test_pyc_vs_pyo.py .
    
    =========================== 1 passed in 0.03 seconds ===========================
    ------------------------------- Captured stderr --------------------------------
    WARNING: assertions which are not in test modules will be ignored because assert statements are not executed by the underlying Python interpreter (are you using python -O?)
    =========================== short test summary info ============================
    XFAIL testing/acceptance_test.py::TestInvocationVariants::()::test_noclass_discovery_if_not_testcase
      decide: feature or bug
    XFAIL testing/test_capture.py::TestPerTestCapturing::()::test_capture_scope_cache
    XFAIL testing/test_collection.py::TestPrunetraceback::()::test_collect_report_postprocessing
      other mechanism for adding to reporting needed
    XFAIL testing/test_config.py::TestParseIni::()::test_confcutdir
      probably not needed
    XFAIL testing/test_pytester.py::test_reportrecorder
      reason: internal reportrecorder tests need refactoring
    XFAIL testing/test_python.py::TestAutouseDiscovery::()::test_setup_enabled_functionnode
      'enabled' feature not implemented
    XFAIL testing/test_runner.py::test_runtest_in_module_ordering
    SKIP [2] /tmp/pytest/_pytest/core.py:121: plugin 'xdist' is missing
    SKIP [11] /tmp/pytest/testing/test_runner.py:277: could not import 'xdist.plugin'
    SKIP [1] /tmp/pytest/_pytest/skipping.py:120: condition: sys.version_info >= (2,6)
    SKIP [1] /tmp/pytest/testing/conftest.py:109: no suitable jython found
    SKIP [1] /tmp/pytest/testing/conftest.py:109: no suitable pypy found
    ======== 1 failed, 815 passed, 16 skipped, 7 xfailed in 756.22 seconds =========



--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Mon Oct 22 09:05:37 2012
From: issues-reply at bitbucket.org (Ronny Pfannschmidt)
Date: Mon, 22 Oct 2012 07:05:37 -0000
Subject: [py-dev] [hpk42/pytest] remember/return returnvalues of test
	functions (issue #207)
Message-ID: <3cf9dc16becee7057941d51f6bf99e97@bitbucket.org>

--- you can reply above this line ---

New issue 207: remember/return returnvalues of test functions
https://bitbucket.org/hpk42/pytest/issue/207/remember-return-returnvalues-of-test

Ronny Pfannschmidt:

this would come in handy for things like the twisted integration,
which currently has to copy the pyfunc_call hook of pytest to get the function return values in order to block on a defered

an alternative would be to expose the "call a test function" machinery in a way that allows to use the returnvalue without copying the machinery


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Mon Oct 22 09:21:14 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 22 Oct 2012 07:21:14 +0000
Subject: [py-dev] pytest-twisted 1.0
In-Reply-To: <874nlncu86.fsf@myhost.lan>
References: <874nlncu86.fsf@myhost.lan>
Message-ID: <20121022072114.GF27773@merlinux.eu>

Hi Ralf,

On Mon, Oct 22, 2012 at 00:53 +0200, Ralf Schmitt wrote:
> Hi,
> 
> I've upload pytest-twisted to pypi [1]. It's a plugin which allows to test
> twisted code with pytest. The code is also available on github [2].
> 
> 
> [1] http://pypi.python.org/pypi/pytest-twisted
> [2] https://github.com/schmir/pytest-twisted

interesting little plugin.  On a general note, using "pytest_configure"
is not the best way to setup global state.  It's better to do this::

    @pytest.fixture(scope="session", autouse=True):
    def setup_twisted_reactor(request):
        ...
        request.addfinalizer(...)
        
This autouse-fixture (i.e. an automatically active fixture without the
need to use it as a funcarg or declare a "usefixtures") will be executed
only in processes which execute tests, so works cleaner with distributed
testing.  The pytest_configure is also called for the xdist-master
process which does not execute or collect tests at all.

If there were multiple reactors / global states you could also use
"params" to run the whole test suite multiple times with different
reactors - only one reactor / global state instance will be active at
any time. That's not possible when using pytest_configure.

best,
holger


From ralf at systemexit.de  Mon Oct 22 10:44:46 2012
From: ralf at systemexit.de (Ralf Schmitt)
Date: Mon, 22 Oct 2012 10:44:46 +0200
Subject: [py-dev] pytest-twisted 1.0
In-Reply-To: <20121022072114.GF27773@merlinux.eu> (holger krekel's message of
	"Mon, 22 Oct 2012 07:21:14 +0000")
References: <874nlncu86.fsf@myhost.lan> <20121022072114.GF27773@merlinux.eu>
Message-ID: <87r4oqc2v5.fsf@brainbot.com>

holger krekel <holger at merlinux.eu> writes:

>
> interesting little plugin.  On a general note, using "pytest_configure"
> is not the best way to setup global state.  It's better to do this::
>
>     @pytest.fixture(scope="session", autouse=True):
>     def setup_twisted_reactor(request):
>         ...
>         request.addfinalizer(...)

thanks for your comments. I'll try to implement that in the next
version. BTW, an early version of this plugin was once part of pylib :)

-- 
Cheers
Ralf


From holger at merlinux.eu  Mon Oct 22 10:58:15 2012
From: holger at merlinux.eu (holger krekel)
Date: Mon, 22 Oct 2012 08:58:15 +0000
Subject: [py-dev] pytest-twisted 1.0
In-Reply-To: <87r4oqc2v5.fsf@brainbot.com>
References: <874nlncu86.fsf@myhost.lan> <20121022072114.GF27773@merlinux.eu>
	<87r4oqc2v5.fsf@brainbot.com>
Message-ID: <20121022085815.GH27773@merlinux.eu>

On Mon, Oct 22, 2012 at 10:44 +0200, Ralf Schmitt wrote:
> holger krekel <holger at merlinux.eu> writes:
> 
> >
> > interesting little plugin.  On a general note, using "pytest_configure"
> > is not the best way to setup global state.  It's better to do this::
> >
> >     @pytest.fixture(scope="session", autouse=True):
> >     def setup_twisted_reactor(request):
> >         ...
> >         request.addfinalizer(...)
> 
> thanks for your comments. I'll try to implement that in the next
> version. BTW, an early version of this plugin was once part of pylib :)

I vaguely remember :)

holger


From issues-reply at bitbucket.org  Mon Oct 22 16:25:56 2012
From: issues-reply at bitbucket.org (Maciej Fijalkowski)
Date: Mon, 22 Oct 2012 14:25:56 -0000
Subject: [py-dev] [hpk42/pytest] py.test takes forever to print traceback on
 large files with unparseable statements (issue #208)
Message-ID: <54c2e06acf25543d763e7ae8eb819811@bitbucket.org>

--- you can reply above this line ---

New issue 208: py.test takes forever to print traceback on large files with unparseable statements
https://bitbucket.org/hpk42/pytest/issue/208/pytest-takes-forever-to-print-traceback-on

Maciej Fijalkowski:

Steps to reproduce:

hg clone https://bitbucket.org/pypy/pypy
cd pypy
hg up 39e70d282074
py.test pypy/jit/backend/llgraph -xv
see it take forever

this is the patch I'm using right now:

http://paste.pound-python.org/show/27012/

which somehow mitigates the issue (it still takes a long time, but not forever). an alternative would be to use _ast module to inspect where the statement starts and ends


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Thu Oct 25 13:53:56 2012
From: holger at merlinux.eu (holger krekel)
Date: Thu, 25 Oct 2012 11:53:56 +0000
Subject: [py-dev] pytest-2.3.2: bug fixes, unittest/trial compat, speed
Message-ID: <20121025115356.GO27773@merlinux.eu>

pytest-2.3.2: some fixes and more traceback-printing speed
===========================================================================

pytest-2.3.2 is another stabilization release with a few improvements:

- issue 205: fixes a regression with conftest detection
- issue 208/29: fixes traceback-printing speed in some bad cases
- fix teardown-ordering for parametrized setups
- fix unittest and trial compat behaviour with respect  to runTest() methods
- issue 206 and others: some improvements to packaging
- fix issue127 and others: improve some docs

See

     http://pytest.org/

for general information.  To install or upgrade pytest:

    pip install -U pytest # or
    easy_install -U pytest

best,
holger krekel


Changes between 2.3.1 and 2.3.2
-----------------------------------

- fix issue208 and fix issue29 use new py version to avoid long pauses 
  when printing tracebacks in long modules

- fix issue205 - conftests in subdirs customizing
  pytest_pycollect_makemodule and pytest_pycollect_makeitem
  now work properly

- fix teardown-ordering for parametrized setups

- fix issue127 - better documentation for pytest_addoption
  and related objects.

- fix unittest behaviour: TestCase.runtest only called if there are
  test methods defined

- improve trial support: don't collect its empty
  unittest.TestCase.runTest() method

- "python setup.py test" now works with pytest itself

- fix/improve internal/packaging related bits:

  - exception message check of test_nose.py now passes on python33 as well

  - issue206 - fix test_assertrewrite.py to work when a global
    PYTHONDONTWRITEBYTECODE=1 is present

  - add tox.ini to pytest distribution so that ignore-dirs and others config
    bits are properly distributed for maintainers who run pytest-own tests



From issues-reply at bitbucket.org  Fri Oct 26 16:32:30 2012
From: issues-reply at bitbucket.org (James Laska)
Date: Fri, 26 Oct 2012 14:32:30 -0000
Subject: [py-dev] [hpk42/pytest] ValueError: compile(): unrecognised flags
	(issue #209)
Message-ID: <3da5687c3dfb875bca84be5bb0f7c998@bitbucket.org>

--- you can reply above this line ---

New issue 209: ValueError: compile(): unrecognised flags
https://bitbucket.org/hpk42/pytest/issue/209/valueerror-compile-unrecognised-flags

James Laska:

With the 2.3.2 release, it seems pytest is now failing on my python-2.4.3 environment.  Sadly, I'm unable to upgrade python in this environment.  My environment consists of ...

* python-2.4.3
* py-1.4.11
* pytest-2.3.2

```
#!pre

# python setup.py test
running test
running egg_info
creating cloud_app_sanity.egg-info
writing cloud_app_sanity.egg-info/PKG-INFO
writing top-level names to cloud_app_sanity.egg-info/top_level.txt
writing dependency_links to cloud_app_sanity.egg-info/dependency_links.txt
writing manifest file 'cloud_app_sanity.egg-info/SOURCES.txt'
reading manifest file 'cloud_app_sanity.egg-info/SOURCES.txt'
writing manifest file 'cloud_app_sanity.egg-info/SOURCES.txt'
running build_ext
Checking .pth file support in .
/usr/bin/python -E -c pass
Searching for pytest
Reading http://cheeseshop.python.org/pypi/pytest/
Reading http://pytest.org
Reading http://cheeseshop.python.org/pypi/pytest/2.3.2
Best match: pytest 2.3.2
Downloading http://pypi.python.org/packages/source/p/pytest/pytest-2.3.2.zip
Processing pytest-2.3.2.zip
Running pytest-2.3.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-qcpd1a/pytest-2.3.2/egg-dist-tmp--9oYJ_
  File "build/bdist.linux-x86_64/egg/_pytest/assertion/rewrite.py", line 37
    PYC_EXT = ".py" + ("c" if __debug__ else "o")
                            ^
SyntaxError: invalid syntax
  File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/assertion/rewrite.py", line 37
    PYC_EXT = ".py" + ("c" if __debug__ else "o")
                            ^
SyntaxError: invalid syntax

Installed /var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg
Searching for py>=1.4.11
Reading http://cheeseshop.python.org/pypi/py/
Reading http://cheeseshop.python.org/pypi/py/1.3.4
Reading http://pylib.org
Reading http://cheeseshop.python.org/pypi/py/1.3.3
Reading http://cheeseshop.python.org/pypi/py/1.3.2
Reading http://cheeseshop.python.org/pypi/py/1.3.1
Reading http://cheeseshop.python.org/pypi/py/1.3.0
Reading http://cheeseshop.python.org/pypi/py/1.4.4
Reading http://cheeseshop.python.org/pypi/py/1.4.5
Reading http://cheeseshop.python.org/pypi/py/1.4.6
Reading http://cheeseshop.python.org/pypi/py/1.4.7
Reading http://cheeseshop.python.org/pypi/py/1.4.0
Reading http://cheeseshop.python.org/pypi/py/1.4.1
Reading http://cheeseshop.python.org/pypi/py/1.4.2
Reading http://cheeseshop.python.org/pypi/py/1.4.3
Reading http://cheeseshop.python.org/pypi/py/1.4.8
Reading http://cheeseshop.python.org/pypi/py/1.4.9
Reading http://cheeseshop.python.org/pypi/py/0.9.2
Reading http://codespeak.net/py/0.9.2/download.html
Reading http://cheeseshop.python.org/pypi/py/1.0.2
Reading http://cheeseshop.python.org/pypi/py/1.1.1
Reading http://cheeseshop.python.org/pypi/py/1.1.0
Reading http://cheeseshop.python.org/pypi/py/1.2.0
Reading http://cheeseshop.python.org/pypi/py/1.2.1
Reading http://cheeseshop.python.org/pypi/py/1.4.10
Reading http://cheeseshop.python.org/pypi/py/1.4.11
Best match: py 1.4.11
Downloading http://pypi.python.org/packages/source/p/py/py-1.4.11.zip
Processing py-1.4.11.zip
Running py-1.4.11/setup.py -q bdist_egg --dist-dir /tmp/easy_install-f1Qfss/py-1.4.11/egg-dist-tmp-zbTJjS

Installed /var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/py-1.4.11-py2.4.egg
Running: pytest -v -l --tb=native --junitxml=results/1351254011.xml --resultlog=results/1351254011.log -k audreyvm -unregister testsuite
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/main.py", line 77, in wrap_session
INTERNALERROR>     config.pluginmanager.do_configure(config)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/core.py", line 268, in do_configure
INTERNALERROR>     config.hook.pytest_configure(config=self._config)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/core.py", line 422, in __call__
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/core.py", line 433, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/core.py", line 351, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/assertion/__init__.py", line 54, in pytest_configure
INTERNALERROR>     warn_about_missing_assertion(mode)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/pytest-2.3.2-py2.4.egg/_pytest/assertion/reinterpret.py", line 22, in __init__
INTERNALERROR>     source = source.getstatement(f.lineno, assertion=True)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/py-1.4.11-py2.4.egg/py/_code/source.py", line 105, in getstatement
INTERNALERROR>     start, end = self.getstatementrange(lineno, assertion)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/py-1.4.11-py2.4.egg/py/_code/source.py", line 114, in getstatementrange
INTERNALERROR>     ast, start, end = getstatementrange_ast(lineno, self)
INTERNALERROR>   File "/var/audrey/tooling/user/KATELLO_REGISTER/cloud-app-sanity/py-1.4.11-py2.4.egg/py/_code/source.py", line 364, in getstatementrange_ast
INTERNALERROR>     astnode = compile(content, "source", "exec", 1024)  # 1024 for AST
INTERNALERROR> ValueError: compile(): unrecognised flags



```


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Fri Oct 26 22:12:03 2012
From: holger at merlinux.eu (holger krekel)
Date: Fri, 26 Oct 2012 20:12:03 +0000
Subject: [py-dev] @pytest.setup as shortcut for
	@pytest.fixture(autouse=True)?
Message-ID: <20121026201203.GR27773@merlinux.eu>

Hi,

I find myself providing examples with "autouse" fixtures and am now
wondering if to introduce a @pytest.setup(...) decorator as a shortcut
for @pytest.fixture(...,  autouse=True).  Many people are used to the
concept of "setup" functions getting automatically called so i think
naming-wise it should fit nicely.  It's slightly redundant but then
again a nice shortcut?!

best,
holger



From Ronny.Pfannschmidt at gmx.de  Fri Oct 26 22:19:50 2012
From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt)
Date: Fri, 26 Oct 2012 22:19:50 +0200
Subject: [py-dev] @pytest.setup as shortcut for
	@pytest.fixture(autouse=True)?
In-Reply-To: <20121026201203.GR27773@merlinux.eu>
References: <20121026201203.GR27773@merlinux.eu>
Message-ID: <508AF066.2070204@gmx.de>

Hi Holger,

i think just having the name setup will make people
wonder about the teardown again

if i correctly recall the name setup did
cause people to misunderstand already
(expecting a teardown of some kind)

Unfortunately i cant think of a fit short name.

Names like requirement and prerequisite come to mind,
but those are longer and don't seem to fit as well as setup

i think in this case a confusing shortcut might
be worse than having to type it explicitly

-- Ronny

On 10/26/2012 10:12 PM, holger krekel wrote:
> Hi,
>
> I find myself providing examples with "autouse" fixtures and am now
> wondering if to introduce a @pytest.setup(...) decorator as a shortcut
> for @pytest.fixture(...,  autouse=True).  Many people are used to the
> concept of "setup" functions getting automatically called so i think
> naming-wise it should fit nicely.  It's slightly redundant but then
> again a nice shortcut?!
>
> best,
> holger
>
> _______________________________________________
> py-dev mailing list
> py-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/py-dev



From issues-reply at bitbucket.org  Sat Oct 27 13:47:03 2012
From: issues-reply at bitbucket.org (evgi)
Date: Sat, 27 Oct 2012 11:47:03 -0000
Subject: [py-dev] [hpk42/pytest] mistake in the documentation version (issue
	#210)
Message-ID: <091c81625192164fcfc00b68ba447df2@bitbucket.org>

--- you can reply above this line ---

New issue 210: mistake in the documentation version
https://bitbucket.org/hpk42/pytest/issue/210/mistake-in-the-documentation-version

evgi:

The version in sphinx conf.py is 2.4.2 and not 2.3.2


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From flub at devork.be  Sun Oct 28 00:53:09 2012
From: flub at devork.be (Floris Bruynooghe)
Date: Sat, 27 Oct 2012 23:53:09 +0100
Subject: [py-dev] @pytest.setup as shortcut for
	@pytest.fixture(autouse=True)?
In-Reply-To: <508AF066.2070204@gmx.de>
References: <20121026201203.GR27773@merlinux.eu>
	<508AF066.2070204@gmx.de>
Message-ID: <CAAWk_Dz8xvYj-x4jU04z-pKqDJ++WDui2c8y8owH7E-TsWxJxA@mail.gmail.com>

On 26 October 2012 21:19, Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> wrote:
> i think just having the name setup will make people
> wonder about the teardown again
>
> if i correctly recall the name setup did
> cause people to misunderstand already
> (expecting a teardown of some kind)
>
> Unfortunately i cant think of a fit short name.

@pytest.autofixture, but I'd be -1 on that.

If the @pytest.setup shortcut is deemed required then a
@pytest.teardown shortcut could also be made for:

@pytest.setup
def generated_teardown_func(request):
    request.addfinalizer(original_teardown_func)

I have no opinion on whether such shortcuts are useful, they are more
then one way to do things which makes me think they should not exist.
But if when talking to users and many examples show such usage as
common then maybe they should be considered.  Personally I haven't
wanted a plain setup/teardown since funcargs so I tend to think they
are just people's resistance to change.

Regards,
Floris


From issues-reply at bitbucket.org  Sun Oct 28 08:05:38 2012
From: issues-reply at bitbucket.org (Alex Gaynor)
Date: Sun, 28 Oct 2012 07:05:38 -0000
Subject: [py-dev] [hpk42/pytest] using --looponfail with tests that forks
 leaves processes lieing around (issue #211)
Message-ID: <96f354d56f0e52805c119f4890e3e657@bitbucket.org>

--- you can reply above this line ---

New issue 211: using --looponfail with tests that forks leaves processes lieing around
https://bitbucket.org/hpk42/pytest/issue/211/using-looponfail-with-tests-that-forks

Alex Gaynor:

If you have a test uses `os.fork()` and run it with `--looponfail` from pytest-xdist then you will get a bunch of processes leaked. These processes just sit around waiting for a lock (as far as I can tell), and hog a bunch of RAM. I'm not sure what the right fix is, but right not it means every once in a while I have to kill all the processes to free up memory!

(This is currently observed with pytest 2.2.4.dev2 from pypy, and pytest-xdist 1.8, I'll try with newer versions once PyPy either upgrades are removes the hardcoded pytest).


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From holger at merlinux.eu  Sun Oct 28 09:46:38 2012
From: holger at merlinux.eu (holger krekel)
Date: Sun, 28 Oct 2012 08:46:38 +0000
Subject: [py-dev] @pytest.setup as shortcut for
 @pytest.fixture(autouse=True)?
In-Reply-To: <CAAWk_Dz8xvYj-x4jU04z-pKqDJ++WDui2c8y8owH7E-TsWxJxA@mail.gmail.com>
References: <20121026201203.GR27773@merlinux.eu> <508AF066.2070204@gmx.de>
	<CAAWk_Dz8xvYj-x4jU04z-pKqDJ++WDui2c8y8owH7E-TsWxJxA@mail.gmail.com>
Message-ID: <20121028084638.GT27773@merlinux.eu>

On Sat, Oct 27, 2012 at 23:53 +0100, Floris Bruynooghe wrote:
> On 26 October 2012 21:19, Ronny Pfannschmidt <Ronny.Pfannschmidt at gmx.de> wrote:
> > i think just having the name setup will make people
> > wonder about the teardown again
> >
> > if i correctly recall the name setup did
> > cause people to misunderstand already
> > (expecting a teardown of some kind)
> >
> > Unfortunately i cant think of a fit short name.
> 
> @pytest.autofixture, but I'd be -1 on that.
> 
> If the @pytest.setup shortcut is deemed required then a
> @pytest.teardown shortcut could also be made for:
> 
> @pytest.setup
> def generated_teardown_func(request):
>     request.addfinalizer(original_teardown_func)
> 
> I have no opinion on whether such shortcuts are useful, they are more
> then one way to do things which makes me think they should not exist.
> But if when talking to users and many examples show such usage as
> common then maybe they should be considered.  Personally I haven't
> wanted a plain setup/teardown since funcargs so I tend to think they
> are just people's resistance to change.

probably true and personally i have the same experience in my projects.

However, due to its unittest/nose/trial support, py.test has a bit of a
multi-paradigm approach. So i think it's sometimes ok to offer more than
one way to do things because people are really coming from different
backgrounds.  However, i think Ronny also has a point remininding how it
came to pytest.fixture instead of pytest.setup. So let's keep things how
they are for now and if anything provide examples and help to people
beginning to use them.

best,
holger

> Regards,
> Floris
> 


From issues-reply at bitbucket.org  Sun Oct 28 12:13:52 2012
From: issues-reply at bitbucket.org (Anonymous)
Date: Sun, 28 Oct 2012 11:13:52 -0000
Subject: [py-dev] [hpk42/pytest] Small documentation improvement. (issue
	#212)
Message-ID: <c4a21b9ef029921d4e1a9815a5a9d623@bitbucket.org>

--- you can reply above this line ---

New issue 212: Small documentation improvement.
https://bitbucket.org/hpk42/pytest/issue/212/small-documentation-improvement

Anonymous:

IMHO the documentation in Fixtures as Function arguments (funcargs) could be improved. As first time reader of that section I found that:
??
Here, the test_function needs the smtp fixture value
??
could be minimal :-) better understandable if it where:
??
Here, the test_ehlo function needs the smtp fixture value
??

Thanks !


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Sun Oct 28 13:19:26 2012
From: issues-reply at bitbucket.org (astrofrog)
Date: Sun, 28 Oct 2012 12:19:26 -0000
Subject: [py-dev] [hpk42/pytest] Issue with numpy arrays and
 pytest.mark.parametrize (issue #213)
Message-ID: <feac390252ebda88adffa83a8b4985f7@bitbucket.org>

--- you can reply above this line ---

New issue 213: Issue with numpy arrays and pytest.mark.parametrize
https://bitbucket.org/hpk42/pytest/issue/213/issue-with-numpy-arrays-and

astrofrog:

The following tests used to pass:

```
import pytest
import numpy as np

@pytest.mark.parametrize(('error'), [1., 'spam', np.ones((5, 5))])
def test(error):
    pass
```

but in the latest tip (5de7185c2891) I get the following exception:

```
_________________________________________________ ERROR collecting astropy/nddata/tests/test_nddata.py _________________________________________________
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/runner.py:121: in __init__
>               self.result = func()
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/main.py:366: in _memocollect
>       return self._memoizedcall('_collected', lambda: list(self.collect()))
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/main.py:287: in _memoizedcall
>           res = function()
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/main.py:366: in <lambda>
>   return self._memoizedcall('_collected', lambda: list(self.collect()))
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:348: in collect
>       return super(Module, self).collect()
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:281: in collect
>                   res = self.makeitem(name, obj)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:293: in makeitem
>           collector=self, name=name, obj=obj)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/main.py:157: in call_matching_hooks
>       return hookmethod.pcall(plugins, **kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:426: in pcall
>       return self._docall(methods, kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:433: in _docall
>           res = mc.execute()
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:351: in execute
>           res = method(**kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:185: in pytest_pycollect_makeitem
>               return list(collector._genfunctions(name, obj))
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:309: in _genfunctions
>       gentesthook.pcall(plugins, metafunc=metafunc)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:426: in pcall
>       return self._docall(methods, kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:433: in _docall
>           res = mc.execute()
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/core.py:351: in execute
>           res = method(**kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:105: in pytest_generate_tests
>           metafunc.parametrize(*marker.args, **marker.kwargs)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:687: in parametrize
>                                    scopenum)
/Users/tom/Library/Python/2.7/lib/python/site-packages/pytest-2.3.2-py2.7.egg/_pytest/python.py:601: in setmulti
>           if val == _notexists:
E           ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
```


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Wed Oct 31 02:59:21 2012
From: issues-reply at bitbucket.org (Thomas Waldmann)
Date: Wed, 31 Oct 2012 01:59:21 -0000
Subject: [py-dev] [hpk42/pytest] pytest blows up when collecting modules
 with uninspectable objects (issue #214)
Message-ID: <b098454f352b78b6e18a9d7399e1f4bc@bitbucket.org>

--- you can reply above this line ---

New issue 214: pytest blows up when collecting modules with uninspectable objects
https://bitbucket.org/hpk42/pytest/issue/214/pytest-blows-up-when-collecting-modules

Thomas Waldmann:

werkzeug/flask offers some threadlocals to comfortable access stuff like (http) request, session, (wsgi) app, etc. - those objects are special and only valid when a request is running or an app was created.

if you access them before / after they are valid, it'll raise a RuntimeError.

while collecting tests, pytest (since 2.3) accesses all module-level objects and tries to inspect them for a specific attribute, causing a RuntimeError exception when it does that on such special objects.

thus, the usual code used in about every flask app makes pytest unusable:

from flask import request, session  # <- threadlocals

a simple patch that solves the issue is attached.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Wed Oct 31 10:01:30 2012
From: issues-reply at bitbucket.org (Ronny Pfannschmidt)
Date: Wed, 31 Oct 2012 09:01:30 -0000
Subject: [py-dev] [hpk42/pytest] split up testing/test_python.py (issue #215)
Message-ID: <9dcb5eee405d9e2ce79635fb233318de@bitbucket.org>

--- you can reply above this line ---

New issue 215: split up testing/test_python.py
https://bitbucket.org/hpk42/pytest/issue/215/split-up-testing-test_pythonpy

Ronny Pfannschmidt:

3 kloc isnt managable anymore,
its goten hard to figure the right place for a test
i think we should split the file up


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.


From issues-reply at bitbucket.org  Wed Oct 31 19:25:57 2012
From: issues-reply at bitbucket.org (Anonymous)
Date: Wed, 31 Oct 2012 18:25:57 -0000
Subject: [py-dev] [hpk42/pytest] Sporadic exceptions on xdist run (issue
	#216)
Message-ID: <e4e4da86facdfaa8842a5bc71226aa5c@bitbucket.org>

--- you can reply above this line ---

New issue 216: Sporadic exceptions on xdist run
https://bitbucket.org/hpk42/pytest/issue/216/sporadic-exceptions-on-xdist-run

Anonymous:

When running with the xdist plugin and on multiple processors, I get every 2-3 runs an exception.
My system is a Debian Linux testing with the following versions:

This is py.test version 2.2.4, imported from /usr/lib/python2.7/dist-packages/pytest.pyc
setuptools registered plugins:
  pytest-xdist-1.8 at /usr/lib/python2.7/dist-packages/xdist/plugin.pyc

```
#!python

INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/main.py", line 74, in wrap_session
INTERNALERROR>     doit(config, session)
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/main.py", line 106, in _main
INTERNALERROR>     config.hook.pytest_runtestloop(session=session)
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/core.py", line 421, in __call__
INTERNALERROR>     return self._docall(methods, kwargs)
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/core.py", line 432, in _docall
INTERNALERROR>     res = mc.execute()
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/_pytest/core.py", line 350, in execute
INTERNALERROR>     res = method(**kwargs)
INTERNALERROR>   File "", line 47, in pytest_runtestloop
INTERNALERROR>   File "/usr/lib/python2.7/dist-packages/execnet/gateway_base.py", line 413, in receive
INTERNALERROR>     raise self._getremoteerror() or EOFError()
INTERNALERROR> EOFError

```

I don't really know what the cause is or what's the best method to debug this. So feel free to ask me for more info. My email is calvin AT sourceforge.net.


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.