From oliver.schoenborn at gmail.com  Sat Mar  4 12:18:10 2017
From: oliver.schoenborn at gmail.com (oliver)
Date: Sat, 04 Mar 2017 17:18:10 +0000
Subject: [pytest-dev] possibly upsetting question on annotations
Message-ID: <CAMb+DaXnkmMt2hzPEWnwJ04AMU1-E0ZQZrSa2kgk4jDwJ=XPJg@mail.gmail.com>

Hello, I love Python annotations and I use them in all my projects where
backwards compatiblity to 2.x is not an issue, really helps with
documenting intent (and code completion in PyCharm!).

But one thing that I find really puzzling is why CPython's "Annotations
engine" can't be fixed to support referencing a name before it is defined.
For example, this leads to a runtime error:

class Foo:
    def some_meth(self, other_foo: Foo):
        pass

This seems like a wart; having to use a string is just counter-intuitive
and ugly and takes away from Python's beauty, simplicity and cleanness. As
a workaround, we define our own decorator that allows us to mark a class as
a "forward declaration for annotation", like this:

@fwd_declaration
class Foo:
    pass

Then when the actual "class Foo" definition has Foo as annotation, the Foo
is the forward-declared one, keeps the interpreter happy. So it does the
job but because it is non-standard, IDE's don't know how to make use of
this information, and it is a bit annoying to have to write.

Is there really no way that this will *ever* be fixed so we don't need to
use strings or forward declaration hack?


-- 
Oliver
My StackOverflow contributions
My CodeProject articles
My Github projects
My SourceForget.net projects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170304/b06de02d/attachment.html>

From me at the-compiler.org  Sun Mar  5 00:54:10 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Sun, 5 Mar 2017 06:54:10 +0100
Subject: [pytest-dev] possibly upsetting question on annotations
In-Reply-To: <CAMb+DaXnkmMt2hzPEWnwJ04AMU1-E0ZQZrSa2kgk4jDwJ=XPJg@mail.gmail.com>
References: <CAMb+DaXnkmMt2hzPEWnwJ04AMU1-E0ZQZrSa2kgk4jDwJ=XPJg@mail.gmail.com>
Message-ID: <20170305055410.n7gmez53aau5ib4g@tonks>

* oliver <oliver.schoenborn at gmail.com> [2017-03-04 17:18:10 +0000]:
> Is there really no way that this will *ever* be fixed so we don't need to
> use strings or forward declaration hack?

Did you mean to write this to python-dev instead of pytest-dev?

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170305/85c60adc/attachment.sig>

From oliver.schoenborn at gmail.com  Mon Mar  6 22:47:03 2017
From: oliver.schoenborn at gmail.com (oliver)
Date: Tue, 07 Mar 2017 03:47:03 +0000
Subject: [pytest-dev] possibly upsetting question on annotations
In-Reply-To: <20170305055410.n7gmez53aau5ib4g@tonks>
References: <CAMb+DaXnkmMt2hzPEWnwJ04AMU1-E0ZQZrSa2kgk4jDwJ=XPJg@mail.gmail.com>
 <20170305055410.n7gmez53aau5ib4g@tonks>
Message-ID: <CAMb+DaXEC+dbVfJ+SfwP+qM7rPOpyK-OC+WaLSZuDZNxoSkANQ@mail.gmail.com>

Ah darned it yes! Thx for letting me know.

On Sun, Mar 5, 2017, 12:54 AM Florian Bruhin <me at the-compiler.org> wrote:

> * oliver <oliver.schoenborn at gmail.com> [2017-03-04 17:18:10 +0000]:
> > Is there really no way that this will *ever* be fixed so we don't need to
> > use strings or forward declaration hack?
>
> Did you mean to write this to python-dev instead of pytest-dev?
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-- 
Oliver
My StackOverflow contributions
My CodeProject articles
My Github projects
My SourceForget.net projects
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170307/1039fb74/attachment.html>

From joel.nothman at gmail.com  Wed Mar  8 01:10:48 2017
From: joel.nothman at gmail.com (Joel Nothman)
Date: Wed, 8 Mar 2017 17:10:48 +1100
Subject: [pytest-dev] Slow startup
Message-ID: <CAAkaFLVqJTjyF9AU8mTsQct+Gys6cqjEjmi2JROCcOQbTJkOFQ@mail.gmail.com>

Hi all,

I'm very excited to finally jump on board the pytest movement.

And yet I'm getting latencies of 7+ seconds just starting up pytest (i.e.
running `mkdir empty; time pytest empty`). It seems some part of pluggy
operation is the culprit, according to a profile.

platform darwin -- Python 3.5.2, pytest-3.0.6, py-1.4.32, pluggy-0.4.0
rootdir: /Users/joel/repos/project, inifile: setup.cfg
plugins: mpl-0.7, cov-2.4.0
collected 0 items


Nothing jumps out at me as awkward in pytestdebug.log (only looking at the
log preceding pytest_collection). --trace-config produces:


setuptools registered plugins:
  pytest-mpl-0.7 at
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/pytest_mpl/plugin.py
  pytest-cov-2.4.0 at
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/pytest_cov/plugin.py
active plugins:
    skipping            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/skipping.py
    debugging           :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/debugging.py
    funcmanage          : <_pytest.fixtures.FixtureManager object at
0x10c96fda0>
    4322195272          : <_pytest.config.PytestPluginManager object at
0x1019f7748>
    terminal            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/terminal.py
    assertion           :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/assertion/__init__.py
    setupplan           :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/setupplan.py
    pytest_mpl          :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/pytest_mpl/plugin.py
    main                :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/main.py
    cacheprovider       :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/cacheprovider.py
    capture             :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/capture.py
    nose                :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/nose.py
    capturemanager      : <_pytest.capture.CaptureManager object at
0x10c94d358>
    mark                :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/mark.py
    resultlog           :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/resultlog.py
    junitxml            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/junitxml.py
    doctest             :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/doctest.py
    pytestconfig        : <_pytest.config.Config object at 0x101c08470>
    unittest            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/unittest.py
    fixtures            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/fixtures.py
    setuponly           :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/setuponly.py
    helpconfig          :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/helpconfig.py
    session             : <Session 'myproject'>
    tmpdir              :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/tmpdir.py
    terminalreporter    : <_pytest.terminal.TerminalReporter object at
0x10c95d8d0>
    monkeypatch         :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/monkeypatch.py
    pastebin            :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/pastebin.py
    pytest_cov          :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/pytest_cov/plugin.py
    recwarn             :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/recwarn.py
    freeze_support      :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/freeze_support.py
    lfplugin            : <_pytest.cacheprovider.LFPlugin object at
0x10c95d550>
    python              :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/python.py
    runner              :
/Users/joel/anaconda3/envs/scipy3k/lib/python3.5/site-packages/_pytest/runner.py

What am I doing wrong?

Thanks,

Joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170308/4cf88ff3/attachment.html>

From me at the-compiler.org  Wed Mar  8 01:14:48 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 8 Mar 2017 07:14:48 +0100
Subject: [pytest-dev] Slow startup
In-Reply-To: <CAAkaFLVqJTjyF9AU8mTsQct+Gys6cqjEjmi2JROCcOQbTJkOFQ@mail.gmail.com>
References: <CAAkaFLVqJTjyF9AU8mTsQct+Gys6cqjEjmi2JROCcOQbTJkOFQ@mail.gmail.com>
Message-ID: <20170308061448.zvmljec32awci5nr@tonks>

Hey,

* Joel Nothman <joel.nothman at gmail.com> [2017-03-08 17:10:48 +1100]:
> plugins: mpl-0.7, cov-2.4.0

Can you try if uninstalling those (or perhaps starting
with "-p no:mpl no:cov") helps?

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170308/9bd030df/attachment.sig>

From joel.nothman at gmail.com  Wed Mar  8 01:27:39 2017
From: joel.nothman at gmail.com (Joel Nothman)
Date: Wed, 8 Mar 2017 17:27:39 +1100
Subject: [pytest-dev] Slow startup
In-Reply-To: <20170308061448.zvmljec32awci5nr@tonks>
References: <CAAkaFLVqJTjyF9AU8mTsQct+Gys6cqjEjmi2JROCcOQbTJkOFQ@mail.gmail.com>
 <20170308061448.zvmljec32awci5nr@tonks>
Message-ID: <CAAkaFLUVym383pj4hjQ33wV5tTsnQHhEu8u6eGRBtjAjefC5-w@mail.gmail.com>

Thanks for the quick reply, Florian,

Yes, this helps. Overhead is reduced to 0.7s if I disable both plugins.

Keeping cov only takes about 2s.

Keeping mpl only takes about 7s.

Neither of these seems satisfactory, frankly, but I'll go take up my issue
with pytest_mpl.


On 8 March 2017 at 17:14, Florian Bruhin <me at the-compiler.org> wrote:

> Hey,
>
> * Joel Nothman <joel.nothman at gmail.com> [2017-03-08 17:10:48 +1100]:
> > plugins: mpl-0.7, cov-2.4.0
>
> Can you try if uninstalling those (or perhaps starting
> with "-p no:mpl no:cov") helps?
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170308/d65354f1/attachment.html>

From nicoddemus at gmail.com  Wed Mar  8 04:59:35 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 08 Mar 2017 09:59:35 +0000
Subject: [pytest-dev] Slow startup
In-Reply-To: <CAAkaFLUVym383pj4hjQ33wV5tTsnQHhEu8u6eGRBtjAjefC5-w@mail.gmail.com>
References: <CAAkaFLVqJTjyF9AU8mTsQct+Gys6cqjEjmi2JROCcOQbTJkOFQ@mail.gmail.com>
 <20170308061448.zvmljec32awci5nr@tonks>
 <CAAkaFLUVym383pj4hjQ33wV5tTsnQHhEu8u6eGRBtjAjefC5-w@mail.gmail.com>
Message-ID: <CA+RQFfc4Gf5M_EH3BvVPLrfHMzVwjRkSV+MjHdDv-_7j49RUYA@mail.gmail.com>

Hi Joel,

I see to you are using conda, and while that should not be a problem, could
you try the same using a fresh pytest install from PyPI for comparison?

python -m venv env
source ./env/bin/activate
pip install pytest

On Wed, Mar 8, 2017, 03:27 Joel Nothman <joel.nothman at gmail.com> wrote:

> Thanks for the quick reply, Florian,
>
> Yes, this helps. Overhead is reduced to 0.7s if I disable both plugins.
>
> Keeping cov only takes about 2s.
>
> Keeping mpl only takes about 7s.
>
> Neither of these seems satisfactory, frankly, but I'll go take up my issue
> with pytest_mpl.
>
>
> On 8 March 2017 at 17:14, Florian Bruhin <me at the-compiler.org> wrote:
>
> Hey,
>
> * Joel Nothman <joel.nothman at gmail.com> [2017-03-08 17:10:48 +1100]:
> > plugins: mpl-0.7, cov-2.4.0
>
> Can you try if uninstalling those (or perhaps starting
> with "-p no:mpl no:cov") helps?
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170308/f314d17b/attachment-0001.html>

From lele at metapensiero.it  Mon Mar 13 09:36:56 2017
From: lele at metapensiero.it (Lele Gaifax)
Date: Mon, 13 Mar 2017 14:36:56 +0100
Subject: [pytest-dev] Issue mixing skipif and parametrize
Message-ID: <87o9x5nvrb.fsf@metapensiero.it>

Hi all,

I have a parametrized test function that loads a set of cases from the
filesystem, something like

@pytest.mark.parametrize('py_code',
                         load_tests_from_directory('some_directory'))
def test_foo(py_code):
    assert some_property(py_code)

The `load_tests_from_directory()` loads Python snippets from the given
directory and basically returns their code objects (that is, the result of
`compile(snippet, 'exec')`).

Now I have a new set of snippets that are Python 3.6 only (they use
f-strings), and I would like to execute those tests only under Python 3.6+.

I tried the obvious, that is

@pytest.mark.skipif(sys.version_info < (3,6))
@pytest.mark.parametrize('py_code',
                         load_tests_from_directory('py36_specific_dir'))
def test_foo_py36_only(py_code):
    assert some_property(py_code)

but unfortunately that does not work, because the parametrization happens also
when the skipif condition is met, and thus the compile() call crash.

Is there a better alternative to recode the above like

@pytest.mark.skipif(sys.version_info < (3,6))
def test_foo_py36_only(py_code):
    for py_code in load_tests_from_directory('py36_specific_dir'):
        assert some_property(py_code)

?

Thanks in advance for any hint,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.

From nicoddemus at gmail.com  Mon Mar 13 09:47:40 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Mon, 13 Mar 2017 13:47:40 +0000
Subject: [pytest-dev] Issue mixing skipif and parametrize
In-Reply-To: <87o9x5nvrb.fsf@metapensiero.it>
References: <87o9x5nvrb.fsf@metapensiero.it>
Message-ID: <CA+RQFfc=RaXmb9P5Ndv2g6bbwScQb7WmQ5ksarOHmefGTkUQqQ@mail.gmail.com>

Hi Lele,

On Mon, Mar 13, 2017 at 10:44 AM Lele Gaifax <lele at metapensiero.it> wrote:

> Hi all,
>
> I have a parametrized test function that loads a set of cases from the
> filesystem, something like
>
> @pytest.mark.parametrize('py_code',
>                          load_tests_from_directory('some_directory'))
> def test_foo(py_code):
>     assert some_property(py_code)
>
> The `load_tests_from_directory()` loads Python snippets from the given
> directory and basically returns their code objects (that is, the result of
> `compile(snippet, 'exec')`).
>
> Now I have a new set of snippets that are Python 3.6 only (they use
> f-strings), and I would like to execute those tests only under Python 3.6+.
>
> I tried the obvious, that is
>
> @pytest.mark.skipif(sys.version_info < (3,6))
> @pytest.mark.parametrize('py_code',
>                          load_tests_from_directory('py36_specific_dir'))
> def test_foo_py36_only(py_code):
>     assert some_property(py_code)
>
> but unfortunately that does not work, because the parametrization happens
> also
> when the skipif condition is met, and thus the compile() call crash.
>
> Is there a better alternative to recode the above like
>
> @pytest.mark.skipif(sys.version_info < (3,6))
> def test_foo_py36_only(py_code):
>     for py_code in load_tests_from_directory('py36_specific_dir'):
>         assert some_property(py_code)
>
> ?
>

I think a possible workaround is implementing your own
``pytest_generate_tests`` hook, see:

http://doc.pytest.org/en/latest/parametrize.html?highlight=pytest_generate_tests#basic-pytest-generate-tests-example


HTH,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170313/1124ab41/attachment.html>

From lele at metapensiero.it  Mon Mar 13 20:47:55 2017
From: lele at metapensiero.it (Lele Gaifax)
Date: Tue, 14 Mar 2017 01:47:55 +0100
Subject: [pytest-dev] Issue mixing skipif and parametrize
In-Reply-To: <CA+RQFfc=RaXmb9P5Ndv2g6bbwScQb7WmQ5ksarOHmefGTkUQqQ@mail.gmail.com>
References: <87o9x5nvrb.fsf@metapensiero.it>
 <CA+RQFfc=RaXmb9P5Ndv2g6bbwScQb7WmQ5ksarOHmefGTkUQqQ@mail.gmail.com>
Message-ID: <87k27sof9g.fsf@metapensiero.it>

Bruno Oliveira <nicoddemus at gmail.com> writes:

> Hi Lele,
>
> I think a possible workaround is implementing your own
> ``pytest_generate_tests`` hook

Thank you Bruno, that's what I was looking for!

This is how I implemented it:

  https://github.com/lelit/metapensiero.pj/blob/fstrings/tests/conftest.py

The only thing I couldn't figure out is how I can report back some kind of
"skipped" message, some kind of XFailed status without breaking off the
generation loop (see line 69)...

Thanks again,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.

From nicoddemus at gmail.com  Mon Mar 13 20:59:54 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 14 Mar 2017 00:59:54 +0000
Subject: [pytest-dev] Issue mixing skipif and parametrize
In-Reply-To: <87k27sof9g.fsf@metapensiero.it>
References: <87o9x5nvrb.fsf@metapensiero.it>
 <CA+RQFfc=RaXmb9P5Ndv2g6bbwScQb7WmQ5ksarOHmefGTkUQqQ@mail.gmail.com>
 <87k27sof9g.fsf@metapensiero.it>
Message-ID: <CA+RQFfe5XvM9Z3pPGXS6pD=9aNEc9tEvrsuEYi6Y-CaihHc4AQ@mail.gmail.com>

On Mon, Mar 13, 2017 at 9:48 PM Lele Gaifax lele at metapensiero.it
<http://mailto:lele at metapensiero.it> wrote:


> The only thing I couldn't figure out is how I can report back some kind of
> "skipped" message, some kind of XFailed status without breaking off the
> generation loop (see line 69)...
>
parametrize is the same call executed by pytest.mark.parametrize, so all
you have to do is wrap the values you want to skip in a pytest.mark.skip()
decorator:

import pytest
def pytest_generate_tests(metafunc):
    metafunc.parametrize('x', [0, pytest.mark.skip(1)(reason='reasons'), 2])
def test_foo(x):
    pass

Here we are parametrizing with [0, 1, 2], but skipping 1. This outputs:

pytest .tmp\foo.py -q
.s.
=========================== short test summary info ===========================
SKIP [1] .tmp\foo.py:7: reasons
2 passed, 1 skipped in 0.01 seconds

More info here:
http://doc.pytest.org/en/latest/parametrize.html?highlight=parametrize#pytest-mark-parametrize-parametrizing-test-functions

Cheers,
Bruno.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170314/55292e08/attachment.html>

From lele at metapensiero.it  Tue Mar 14 04:35:18 2017
From: lele at metapensiero.it (Lele Gaifax)
Date: Tue, 14 Mar 2017 09:35:18 +0100
Subject: [pytest-dev] Issue mixing skipif and parametrize
In-Reply-To: <CA+RQFfe5XvM9Z3pPGXS6pD=9aNEc9tEvrsuEYi6Y-CaihHc4AQ@mail.gmail.com>
References: <87o9x5nvrb.fsf@metapensiero.it>
 <CA+RQFfc=RaXmb9P5Ndv2g6bbwScQb7WmQ5ksarOHmefGTkUQqQ@mail.gmail.com>
 <87k27sof9g.fsf@metapensiero.it>
 <CA+RQFfe5XvM9Z3pPGXS6pD=9aNEc9tEvrsuEYi6Y-CaihHc4AQ@mail.gmail.com>
Message-ID: <874lywfe7t.fsf@metapensiero.it>

Bruno Oliveira <nicoddemus at gmail.com> writes:

> parametrize is the same call executed by pytest.mark.parametrize, so all
> you have to do is wrap the values you want to skip in a pytest.mark.skip()
> decorator

Easy enough! :-)

Thank you,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri
real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.

From ojiidotch at gmail.com  Tue Mar 14 05:35:39 2017
From: ojiidotch at gmail.com (Jonas Obrist)
Date: Tue, 14 Mar 2017 18:35:39 +0900
Subject: [pytest-dev] Changing --last-failed and --failed-first precedence
Message-ID: <CAMS=EL2zFrVAbbpvkfNu6Oefbms5OD9mOJzL_fuWhpAhLzXR=w@mail.gmail.com>

I opened a ticket on Github [1] suggesting that the precedence of the
--last-failed and --failed-first options be changed, basically to have
--failed-first be ignored if --last-failed is also given. Currently when
both options are used, all tests are run (with failing first) as if
--last-failed was not provided. I suggest this be changed to behave as if
--failed-first was not provided.

As I said in the ticket, I'd be happy to try to write the patch for this
myself, but since this would be a changing existing behaviour, Ronny
Pfannschmidt on Github suggested I'd bring this up here first.

Jonas

[1] https://github.com/pytest-dev/pytest/issues/2308
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170314/a875193a/attachment.html>

From nicoddemus at gmail.com  Tue Mar 14 17:05:44 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 14 Mar 2017 21:05:44 +0000
Subject: [pytest-dev] pytest 3.0.7 released
Message-ID: <CA+RQFfdZyYqx9w2A4O=ckPd9Rbnm3RHaoqx7qkR=LU=gXSRMPg@mail.gmail.com>

pytest-3.0.7
============

pytest 3.0.7 has just been released to PyPI.

This is a bug-fix release, being a drop-in replacement. To upgrade::

  pip install --upgrade pytest

The full changelog is available at
http://doc.pytest.org/en/latest/changelog.html.

Thanks to all who contributed to this release, among them:

* Anthony Sottile
* Barney Gale
* Bruno Oliveira
* Florian Bruhin
* Floris Bruynooghe
* Ionel Cristian M?rie?
* Katerina Koukiou
* NODA, Kai
* Omer Hadari
* Patrick Hayes
* Ran Benita
* Ronny Pfannschmidt
* Victor Uriarte
* Vidar Tonaas Fauske
* Ville Skytt?
* fbjorn
* mbyt

Happy testing,
The pytest Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170314/9b8ad1ce/attachment.html>

From oliver at bestwalter.de  Wed Mar 15 08:47:12 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Wed, 15 Mar 2017 12:47:12 +0000
Subject: [pytest-dev] Sprint this summer?
Message-ID: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>

Hi all,

just want to get the ball rolling and ask if planning has started already
and how I can help.

This is mainly triggered by a question here:
https://github.com/tox-dev/tox/issues/485

Would it maybe be feasible to coordinate this together with the EuroPython
this year?

Cheers,
Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170315/e7cc325f/attachment.html>

From dan.nealschneider at gmail.com  Wed Mar 15 17:56:57 2017
From: dan.nealschneider at gmail.com (Dan Nealschneider)
Date: Wed, 15 Mar 2017 14:56:57 -0700
Subject: [pytest-dev] Sprint this summer?
In-Reply-To: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
References: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
Message-ID: <CAA9fXhyvmGVrE=x17c=q2S88K8cw2ZO0JGrH4_NpDYaBTGSGsw@mail.gmail.com>

I'm also curious about whether anyone else will be at PyCon US?

On Wed, Mar 15, 2017 at 5:47 AM, Oliver Bestwalter <oliver at bestwalter.de>
wrote:

> Hi all,
>
> just want to get the ball rolling and ask if planning has started already
> and how I can help.
>
> This is mainly triggered by a question here: https://github.com/tox-dev/
> tox/issues/485
>
> Would it maybe be feasible to coordinate this together with the EuroPython
> this year?
>
> Cheers,
> Oliver
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170315/c2165a84/attachment.html>

From nicoddemus at gmail.com  Thu Mar 16 16:07:57 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 16 Mar 2017 20:07:57 +0000
Subject: [pytest-dev] Sprint this summer?
In-Reply-To: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
References: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
Message-ID: <CA+RQFffCBGgjshLm20_v8M9n-mpLwhq76R=Wsd8+Vm56hRxpcQ@mail.gmail.com>

On Wed, Mar 15, 2017 at 10:16 AM Oliver Bestwalter <oliver at bestwalter.de>
wrote:

> just want to get the ball rolling and ask if planning has started already
> and how I can help.
>

AFAIK there's no planning yet. I imagine that managing a sprint is quite
some work as Holger can attest to, so it would be nice if someone from
Europe volunteered to coordinate a sprint this year.


> Would it maybe be feasible to coordinate this together with the EuroPython
> this year?
>

I don't see why not. :)

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170316/6c0fa9a5/attachment.html>

From opensource at ronnypfannschmidt.de  Fri Mar 17 05:09:26 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 17 Mar 2017 10:09:26 +0100
Subject: [pytest-dev] [proposal] big flake8 cleanup before the 3.1 release
Message-ID: <59e806c8-8f07-8d02-2dc4-a558d3afcaf9@ronnypfannschmidt.de>

Hi all,

before releasing 3.1 i would like to bring pytest up to coding standards
while not all agree on the exact rules of flake8,
i find it an insult to my eyes to that basically all tools that
don't/can't support all kinds of config files
pretty much show about half of pytest in violation all the time

what i certainly don't want to do, is start to disable code standard
enforcement on random projects,
so i want to enforce it - and that means fixing up pytest once and for all.

a good point in time would e to do it on the features branch right
before doing a release and merging back to master as it would create the
smallest merge effort.

additionally it would allow us to switch from travis for linting to a
dedicated service with better gh integration in future without
maintaining yet another massive exclude list

-- Ronny


From opensource at ronnypfannschmidt.de  Fri Mar 17 05:15:59 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 17 Mar 2017 10:15:59 +0100
Subject: [pytest-dev] Sprint this summer?
In-Reply-To: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
References: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
Message-ID: <7caf347c-3f14-92f4-8c56-034f7285e5f4@ronnypfannschmidt.de>

Hi all,

i'd love to join a sprint in some way, but i do have a kid on the way
and its due end of july.
which is also why i can't participate in planning this year and also
likely can't be there in person.

-- Ronny


On 15.03.2017 13:47, Oliver Bestwalter wrote:
> Hi all,
>
> just want to get the ball rolling and ask if planning has started
> already and how I can help.
>
> This is mainly triggered by a question here:
> https://github.com/tox-dev/tox/issues/485
>
> Would it maybe be feasible to coordinate this together with the
> EuroPython this year?
>
> Cheers,
> Oliver
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/24b0f095/attachment.html>

From mail at florian-schulze.net  Fri Mar 17 05:34:39 2017
From: mail at florian-schulze.net (Florian Schulze)
Date: Fri, 17 Mar 2017 10:34:39 +0100
Subject: [pytest-dev] [proposal] big flake8 cleanup before the 3.1
 release
In-Reply-To: <59e806c8-8f07-8d02-2dc4-a558d3afcaf9@ronnypfannschmidt.de>
References: <59e806c8-8f07-8d02-2dc4-a558d3afcaf9@ronnypfannschmidt.de>
Message-ID: <E9BF8230-82E3-48C0-B23C-7F8FBE0FC4F0@florian-schulze.net>

Hi!

Personally I disable the line length limit and keep all other warnings.

For old projects I only fix pep8 issues in code I edit in a commit. A 
massive cleanup disrupts history and especially "blame" too much IMHO.

Regards,
Florian Schulze


On 17 Mar 2017, at 10:09, Ronny Pfannschmidt wrote:

> Hi all,
>
> before releasing 3.1 i would like to bring pytest up to coding 
> standards
> while not all agree on the exact rules of flake8,
> i find it an insult to my eyes to that basically all tools that
> don't/can't support all kinds of config files
> pretty much show about half of pytest in violation all the time
>
> what i certainly don't want to do, is start to disable code standard
> enforcement on random projects,
> so i want to enforce it - and that means fixing up pytest once and for 
> all.
>
> a good point in time would e to do it on the features branch right
> before doing a release and merging back to master as it would create 
> the
> smallest merge effort.
>
> additionally it would allow us to switch from travis for linting to a
> dedicated service with better gh integration in future without
> maintaining yet another massive exclude list
>
> -- Ronny
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From nicoddemus at gmail.com  Fri Mar 17 06:48:48 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 17 Mar 2017 10:48:48 +0000
Subject: [pytest-dev] [proposal] big flake8 cleanup before the 3.1
 release
In-Reply-To: <E9BF8230-82E3-48C0-B23C-7F8FBE0FC4F0@florian-schulze.net>
References: <59e806c8-8f07-8d02-2dc4-a558d3afcaf9@ronnypfannschmidt.de>
 <E9BF8230-82E3-48C0-B23C-7F8FBE0FC4F0@florian-schulze.net>
Message-ID: <CA+RQFfd+f3UtaQzsPi7r5wqvie5c6KSqvQ4Gb+e-o8SDO_2Dqg@mail.gmail.com>

Hi,

While this kind of change is a little disruptive regarding history and
might generate conflicts in PRs, it is the kind of change that is a little
pain for a short time but brings tangible benefits in the long term, so
I'm +1 on the idea.

An idea: when doing something similar at work (recently we switched our
import-order sorting to PEP8 from a custom standard for example) we use a
fictional persona for the committer of the change as to not assign undue
"blame" to a person, so I suggest doing the same here. We can use our own
pytest's bot for that.

Cheers,
Bruno.

On Fri, Mar 17, 2017 at 6:35 AM Florian Schulze <mail at florian-schulze.net>
wrote:

Hi!

Personally I disable the line length limit and keep all other warnings.

For old projects I only fix pep8 issues in code I edit in a commit. A
massive cleanup disrupts history and especially "blame" too much IMHO.

Regards,
Florian Schulze


On 17 Mar 2017, at 10:09, Ronny Pfannschmidt wrote:

> Hi all,
>
> before releasing 3.1 i would like to bring pytest up to coding
> standards
> while not all agree on the exact rules of flake8,
> i find it an insult to my eyes to that basically all tools that
> don't/can't support all kinds of config files
> pretty much show about half of pytest in violation all the time
>
> what i certainly don't want to do, is start to disable code standard
> enforcement on random projects,
> so i want to enforce it - and that means fixing up pytest once and for
> all.
>
> a good point in time would e to do it on the features branch right
> before doing a release and merging back to master as it would create
> the
> smallest merge effort.
>
> additionally it would allow us to switch from travis for linting to a
> dedicated service with better gh integration in future without
> maintaining yet another massive exclude list
>
> -- Ronny
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
_______________________________________________
pytest-dev mailing list
pytest-dev at python.org
https://mail.python.org/mailman/listinfo/pytest-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/87454817/attachment-0001.html>

From oliver at bestwalter.de  Fri Mar 17 07:35:10 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Fri, 17 Mar 2017 11:35:10 +0000
Subject: [pytest-dev] Sprint this summer?
In-Reply-To: <7caf347c-3f14-92f4-8c56-034f7285e5f4@ronnypfannschmidt.de>
References: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
 <7caf347c-3f14-92f4-8c56-034f7285e5f4@ronnypfannschmidt.de>
Message-ID: <CAG5Cgtoedt24rgke_Jun4egy7mnoVxB7FOiSHvr-qpKUrRp28Q@mail.gmail.com>

Hello Ronny,

oh wow! congratulations then :)

Cheers
Oliver

On Fri, 17 Mar 2017 at 10:16 Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi all,
>
> i'd love to join a sprint in some way, but i do have a kid on the way and
> its due end of july.
> which is also why i can't participate in planning this year and also
> likely can't be there in person.
>
> -- Ronny
>
> On 15.03.2017 13:47, Oliver Bestwalter wrote:
>
> Hi all,
>
> just want to get the ball rolling and ask if planning has started already
> and how I can help.
>
> This is mainly triggered by a question here:
> https://github.com/tox-dev/tox/issues/485
>
> Would it maybe be feasible to coordinate this together with the EuroPython
> this year?
>
> Cheers,
> Oliver
>
>
> _______________________________________________
> pytest-dev mailing listpytest-dev at python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/804b9a11/attachment.html>

From aninhacostaribeiro at gmail.com  Fri Mar 17 07:37:16 2017
From: aninhacostaribeiro at gmail.com (Ana Ribeiro)
Date: Fri, 17 Mar 2017 08:37:16 -0300
Subject: [pytest-dev] Sprint this summer?
In-Reply-To: <CAG5Cgtoedt24rgke_Jun4egy7mnoVxB7FOiSHvr-qpKUrRp28Q@mail.gmail.com>
References: <CAG5CgtpezOM6dkV2NwV_HZ-vZWRZpLVp=CHO6Zt2uNAF4QoRYg@mail.gmail.com>
 <7caf347c-3f14-92f4-8c56-034f7285e5f4@ronnypfannschmidt.de>
 <CAG5Cgtoedt24rgke_Jun4egy7mnoVxB7FOiSHvr-qpKUrRp28Q@mail.gmail.com>
Message-ID: <CAO-2QM5ajHWwfUOewdEcjeag9ACukOiH0F7h40YJexfL2hZvaw@mail.gmail.com>

Seems a good idea! If I am around then, I'll definitely try to be there!
Congratulations Ronny!

On Mar 17, 2017 08:35, "Oliver Bestwalter" <oliver at bestwalter.de> wrote:

> Hello Ronny,
>
> oh wow! congratulations then :)
>
> Cheers
> Oliver
>
> On Fri, 17 Mar 2017 at 10:16 Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
>
>> Hi all,
>>
>> i'd love to join a sprint in some way, but i do have a kid on the way and
>> its due end of july.
>> which is also why i can't participate in planning this year and also
>> likely can't be there in person.
>>
>> -- Ronny
>>
>> On 15.03.2017 13:47, Oliver Bestwalter wrote:
>>
>> Hi all,
>>
>> just want to get the ball rolling and ask if planning has started already
>> and how I can help.
>>
>> This is mainly triggered by a question here: https://github.com/tox-dev/
>> tox/issues/485
>>
>> Would it maybe be feasible to coordinate this together with the
>> EuroPython this year?
>>
>> Cheers,
>> Oliver
>>
>>
>> _______________________________________________
>> pytest-dev mailing listpytest-dev at python.orghttps://mail.python.org/mailman/listinfo/pytest-dev
>>
>>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/d06641b0/attachment.html>

From oliver at bestwalter.de  Fri Mar 17 07:40:12 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Fri, 17 Mar 2017 11:40:12 +0000
Subject: [pytest-dev] [proposal] big flake8 cleanup before the 3.1
 release
In-Reply-To: <CA+RQFfd+f3UtaQzsPi7r5wqvie5c6KSqvQ4Gb+e-o8SDO_2Dqg@mail.gmail.com>
References: <59e806c8-8f07-8d02-2dc4-a558d3afcaf9@ronnypfannschmidt.de>
 <E9BF8230-82E3-48C0-B23C-7F8FBE0FC4F0@florian-schulze.net>
 <CA+RQFfd+f3UtaQzsPi7r5wqvie5c6KSqvQ4Gb+e-o8SDO_2Dqg@mail.gmail.com>
Message-ID: <CAG5Cgtp0eTsJf_-V9F8EW_7senEeNOJt1FLVCCa-kCDr6EeskQ@mail.gmail.com>

Hi all,

I usually have all flake8 on full throttle and let PyCharm warn me (except
for naming, I am a bit particular there I admit) and I have similar
thoughts when wondering through the tox sources. I will watch how you do it
and then maybe propose the same for tox afterwards.

Good luck,

Cheers
Oliver


On Fri, 17 Mar 2017 at 11:49 Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi,
>
> While this kind of change is a little disruptive regarding history and
> might generate conflicts in PRs, it is the kind of change that is a little
> pain for a short time but brings tangible benefits in the long term, so
> I'm +1 on the idea.
>
> An idea: when doing something similar at work (recently we switched our
> import-order sorting to PEP8 from a custom standard for example) we use a
> fictional persona for the committer of the change as to not assign undue
> "blame" to a person, so I suggest doing the same here. We can use our own
> pytest's bot for that.
>
> Cheers,
> Bruno.
>
> On Fri, Mar 17, 2017 at 6:35 AM Florian Schulze <mail at florian-schulze.net>
> wrote:
>
> Hi!
>
> Personally I disable the line length limit and keep all other warnings.
>
> For old projects I only fix pep8 issues in code I edit in a commit. A
> massive cleanup disrupts history and especially "blame" too much IMHO.
>
> Regards,
> Florian Schulze
>
>
> On 17 Mar 2017, at 10:09, Ronny Pfannschmidt wrote:
>
> > Hi all,
> >
> > before releasing 3.1 i would like to bring pytest up to coding
> > standards
> > while not all agree on the exact rules of flake8,
> > i find it an insult to my eyes to that basically all tools that
> > don't/can't support all kinds of config files
> > pretty much show about half of pytest in violation all the time
> >
> > what i certainly don't want to do, is start to disable code standard
> > enforcement on random projects,
> > so i want to enforce it - and that means fixing up pytest once and for
> > all.
> >
> > a good point in time would e to do it on the features branch right
> > before doing a release and merging back to master as it would create
> > the
> > smallest merge effort.
> >
> > additionally it would allow us to switch from travis for linting to a
> > dedicated service with better gh integration in future without
> > maintaining yet another massive exclude list
> >
> > -- Ronny
> >
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/660b9daa/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Tue Mar 21 04:54:14 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 21 Mar 2017 09:54:14 +0100
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
Message-ID: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>

Hi all,

today i noticed how pip manages its change-logs in a pretty interesting way,

they manage the fragments to be composed before a release in the folder
"news" in files named like "$ticketnumber.$changetype"
before a release those files get take out and composed into the change-log.

The fabulous tool behind that is https://github.com/hawkowl/towncrier/ -
after taking a first look at it,
i believe it should be a massive enhancement compared to what we put
ourselves trough right now.

i also would be delighted, if we used it in more projects ^^

cheers,

Ronny



From nicoddemus at gmail.com  Tue Mar 21 09:41:16 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 21 Mar 2017 13:41:16 +0000
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
Message-ID: <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>

Hi Ronny,

I definitely like the idea! I agree our current CHANGELOG maintenance could
use some improvement. :)

We could introduce it for `3.1`, what do you think?

On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi all,
>
> today i noticed how pip manages its change-logs in a pretty interesting
> way,
>
> they manage the fragments to be composed before a release in the folder
> "news" in files named like "$ticketnumber.$changetype"
> before a release those files get take out and composed into the change-log.
>
> The fabulous tool behind that is https://github.com/hawkowl/towncrier/ -
> after taking a first look at it,
> i believe it should be a massive enhancement compared to what we put
> ourselves trough right now.
>
> i also would be delighted, if we used it in more projects ^^
>
> cheers,
>
> Ronny
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170321/754789e4/attachment.html>

From opensource at ronnypfannschmidt.de  Tue Mar 21 11:29:06 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 21 Mar 2017 16:29:06 +0100
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
 <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>
Message-ID: <cd263fd5-c6d2-39ac-c74f-b966c5ddad37@ronnypfannschmidt.de>

Hi Bruno,

due to its Nature its best suited for introducing right after 3.1

after all the before bits are already in place

-- Ronny

On 21.03.2017 14:41, Bruno Oliveira wrote:
> Hi Ronny,
>
> I definitely like the idea! I agree our current CHANGELOG maintenance
> could use some improvement. :)
>
> We could introduce it for `3.1`, what do you think?
>
> On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de
> <mailto:opensource at ronnypfannschmidt.de>> wrote:
>
>     Hi all,
>
>     today i noticed how pip manages its change-logs in a pretty
>     interesting way,
>
>     they manage the fragments to be composed before a release in the folder
>     "news" in files named like "$ticketnumber.$changetype"
>     before a release those files get take out and composed into the
>     change-log.
>
>     The fabulous tool behind that is https://github.com/hawkowl/towncrier/ -
>     after taking a first look at it,
>     i believe it should be a massive enhancement compared to what we put
>     ourselves trough right now.
>
>     i also would be delighted, if we used it in more projects ^^
>
>     cheers,
>
>     Ronny
>
>
>     _______________________________________________
>     pytest-dev mailing list
>     pytest-dev at python.org <mailto:pytest-dev at python.org>
>     https://mail.python.org/mailman/listinfo/pytest-dev
>

From nicoddemus at gmail.com  Tue Mar 21 11:32:23 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 21 Mar 2017 15:32:23 +0000
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <cd263fd5-c6d2-39ac-c74f-b966c5ddad37@ronnypfannschmidt.de>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
 <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>
 <cd263fd5-c6d2-39ac-c74f-b966c5ddad37@ronnypfannschmidt.de>
Message-ID: <CA+RQFff_HG8vtjHxe=SRrHbVvoSMeWC5HR81+pm2XbWw7K4Hrg@mail.gmail.com>

Hey Ronny,

Oh you are absolutely right.

Do you know what happens with the old CHANGELOG entries btw?

Cheers,

On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi Bruno,
>
> due to its Nature its best suited for introducing right after 3.1
>
> after all the before bits are already in place
>
> -- Ronny
>
> On 21.03.2017 14:41, Bruno Oliveira wrote:
> > Hi Ronny,
> >
> > I definitely like the idea! I agree our current CHANGELOG maintenance
> > could use some improvement. :)
> >
> > We could introduce it for `3.1`, what do you think?
> >
> > On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt
> > <opensource at ronnypfannschmidt.de
> > <mailto:opensource at ronnypfannschmidt.de>> wrote:
> >
> >     Hi all,
> >
> >     today i noticed how pip manages its change-logs in a pretty
> >     interesting way,
> >
> >     they manage the fragments to be composed before a release in the
> folder
> >     "news" in files named like "$ticketnumber.$changetype"
> >     before a release those files get take out and composed into the
> >     change-log.
> >
> >     The fabulous tool behind that is
> https://github.com/hawkowl/towncrier/ -
> >     after taking a first look at it,
> >     i believe it should be a massive enhancement compared to what we put
> >     ourselves trough right now.
> >
> >     i also would be delighted, if we used it in more projects ^^
> >
> >     cheers,
> >
> >     Ronny
> >
> >
> >     _______________________________________________
> >     pytest-dev mailing list
> >     pytest-dev at python.org <mailto:pytest-dev at python.org>
> >     https://mail.python.org/mailman/listinfo/pytest-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170321/1290cedc/attachment.html>

From opensource at ronnypfannschmidt.de  Tue Mar 21 12:14:56 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Tue, 21 Mar 2017 17:14:56 +0100
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <CA+RQFff_HG8vtjHxe=SRrHbVvoSMeWC5HR81+pm2XbWw7K4Hrg@mail.gmail.com>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
 <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>
 <cd263fd5-c6d2-39ac-c74f-b966c5ddad37@ronnypfannschmidt.de>
 <CA+RQFff_HG8vtjHxe=SRrHbVvoSMeWC5HR81+pm2XbWw7K4Hrg@mail.gmail.com>
Message-ID: <4307a065-49de-be67-c86b-57baa99ef0b3@ronnypfannschmidt.de>

Hi Bruno

towncrier takes the new entries, renders them to a text and then inserts
them either at the start, or right after a special marker line

-- Ronny


On 21.03.2017 16:32, Bruno Oliveira wrote:
> Hey Ronny,
>
> Oh you are absolutely right.
>
> Do you know what happens with the old CHANGELOG entries btw? 
>
> Cheers,
>
> On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt
> <opensource at ronnypfannschmidt.de
> <mailto:opensource at ronnypfannschmidt.de>> wrote:
>
>     Hi Bruno,
>
>     due to its Nature its best suited for introducing right after 3.1
>
>     after all the before bits are already in place
>
>     -- Ronny
>
>     On 21.03.2017 14:41, Bruno Oliveira wrote:
>     > Hi Ronny,
>     >
>     > I definitely like the idea! I agree our current CHANGELOG
>     maintenance
>     > could use some improvement. :)
>     >
>     > We could introduce it for `3.1`, what do you think?
>     >
>     > On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt
>     > <opensource at ronnypfannschmidt.de
>     <mailto:opensource at ronnypfannschmidt.de>
>     > <mailto:opensource at ronnypfannschmidt.de
>     <mailto:opensource at ronnypfannschmidt.de>>> wrote:
>     >
>     >     Hi all,
>     >
>     >     today i noticed how pip manages its change-logs in a pretty
>     >     interesting way,
>     >
>     >     they manage the fragments to be composed before a release in
>     the folder
>     >     "news" in files named like "$ticketnumber.$changetype"
>     >     before a release those files get take out and composed into the
>     >     change-log.
>     >
>     >     The fabulous tool behind that is
>     https://github.com/hawkowl/towncrier/ -
>     >     after taking a first look at it,
>     >     i believe it should be a massive enhancement compared to
>     what we put
>     >     ourselves trough right now.
>     >
>     >     i also would be delighted, if we used it in more projects ^^
>     >
>     >     cheers,
>     >
>     >     Ronny
>     >
>     >
>     >     _______________________________________________
>     >     pytest-dev mailing list
>     >     pytest-dev at python.org <mailto:pytest-dev at python.org>
>     <mailto:pytest-dev at python.org <mailto:pytest-dev at python.org>>
>     >     https://mail.python.org/mailman/listinfo/pytest-dev
>     >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170321/d7bf8267/attachment.html>

From nicoddemus at gmail.com  Tue Mar 21 12:51:54 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 21 Mar 2017 16:51:54 +0000
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <4307a065-49de-be67-c86b-57baa99ef0b3@ronnypfannschmidt.de>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
 <CA+RQFffxWhwkwrZiVLRcav8gy18UdqfAZvWGpun=6GiouYhg6w@mail.gmail.com>
 <cd263fd5-c6d2-39ac-c74f-b966c5ddad37@ronnypfannschmidt.de>
 <CA+RQFff_HG8vtjHxe=SRrHbVvoSMeWC5HR81+pm2XbWw7K4Hrg@mail.gmail.com>
 <4307a065-49de-be67-c86b-57baa99ef0b3@ronnypfannschmidt.de>
Message-ID: <CA+RQFfdizXiodpSX3ns+schTJpMfK9Sj1cAzMzxsFC6uqQ=dOg@mail.gmail.com>

Sounds great then! :)

Cheers

On Tue, Mar 21, 2017 at 1:14 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Hi Bruno
>
> towncrier takes the new entries, renders them to a text and then inserts
> them either at the start, or right after a special marker line
>
> -- Ronny
>
> On 21.03.2017 16:32, Bruno Oliveira wrote:
>
> Hey Ronny,
>
> Oh you are absolutely right.
>
> Do you know what happens with the old CHANGELOG entries btw?
>
> Cheers,
>
> On Tue, Mar 21, 2017 at 12:29 PM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
>
> Hi Bruno,
>
> due to its Nature its best suited for introducing right after 3.1
>
> after all the before bits are already in place
>
> -- Ronny
>
> On 21.03.2017 14:41, Bruno Oliveira wrote:
> > Hi Ronny,
> >
> > I definitely like the idea! I agree our current CHANGELOG maintenance
> > could use some improvement. :)
> >
> > We could introduce it for `3.1`, what do you think?
> >
> > On Tue, Mar 21, 2017 at 5:54 AM Ronny Pfannschmidt
> > <opensource at ronnypfannschmidt.de
> > <mailto:opensource at ronnypfannschmidt.de>> wrote:
> >
> >     Hi all,
> >
> >     today i noticed how pip manages its change-logs in a pretty
> >     interesting way,
> >
> >     they manage the fragments to be composed before a release in the
> folder
> >     "news" in files named like "$ticketnumber.$changetype"
> >     before a release those files get take out and composed into the
> >     change-log.
> >
> >     The fabulous tool behind that is
> https://github.com/hawkowl/towncrier/ -
> >     after taking a first look at it,
> >     i believe it should be a massive enhancement compared to what we put
> >     ourselves trough right now.
> >
> >     i also would be delighted, if we used it in more projects ^^
> >
> >     cheers,
> >
> >     Ronny
> >
> >
> >     _______________________________________________
> >     pytest-dev mailing list
> >     pytest-dev at python.org <mailto:pytest-dev at python.org>
> >     https://mail.python.org/mailman/listinfo/pytest-dev
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170321/f1db06d8/attachment.html>

From nicoddemus at gmail.com  Wed Mar 22 11:34:43 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 22 Mar 2017 15:34:43 +0000
Subject: [pytest-dev] Travis auto-cancellation enabled
Message-ID: <CA+RQFffR6K8hJwZO+8bCQfmUphFz5UYXpNNhd-SmDfoZXvVPhg@mail.gmail.com>

Hi everyone,

Travis introduced "auto-cancellation", meaning that if a new commit is
pushed to a branch or PR, any queued builds for the previous commit in that
branch or PR is cancelled automatically.

I think this is a great idea as it avoids building older commits which are
probably no longer relevant.

More information here:
https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation

I decided to go ahead and enable this as I believe it is a win-win
situation, but if somebody disagrees please let me know.

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170322/eaf6b641/attachment-0001.html>

From nicoddemus at gmail.com  Fri Mar 24 14:07:33 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 24 Mar 2017 18:07:33 +0000
Subject: [pytest-dev] Mozilla Open Source Support
In-Reply-To: <20170227104319.366b5896@krusty.ws.whq.gocept.com>
References: <20170220224154.6fa55b58@alpha>
 <D8D05C4E-586A-4055-BAF0-5AD2DDCD2A3D@mozilla.com>
 <DFD7E118-E92A-4E69-87A2-046C7B6FD7B9@hackebrot.de>
 <20170227104319.366b5896@krusty.ws.whq.gocept.com>
Message-ID: <CA+RQFfcpMQ_hyE=9uzC+6zY_naJ88t6EhokC3JyupukLNcDPtw@mail.gmail.com>

Hi all,

Has any work on creating a "pytest" like organization moved forward? That
would be great in terms of making it easy to get sponsorship from any
number of means.

Cheers,
Bruno.

On Mon, Feb 27, 2017 at 6:43 AM Thomas Lotze <thomas at thomas-lotze.de> wrote:

> Hi Raphael,
>
> thank you for your reply. Given the number of diverse concerns you confirm
> or raise (previous plannings for funding the work on docs, the handling of
> finances, the project's reputation etc), it first of all becomes pretty
> clear that I'm not going to rush anything now before the impending deadline
> of this round of MOSS awards.
>
> Even though I was thinking of development work, I wouldn't object to
> helping with the documentation. So my suggestion is to use the time until
> the next round to clarify the financial stuff (I wouldn't think it's
> necessary to set up a dedicated legal entity for this, but let's discuss
> that with people who have done more of these things before), and then pick
> up on the existing plans for documentation work and see who's willing to
> join and what it would make sense to include in the proposal. (I could
> imagine that some development stuff can be added which e.g. contributes to
> the user experience, while still keeping the objective of the proposal
> well-defined.)
>
> I'll get back to the list about this in the next days. Thank you again for
> putting the subject of the awards in a better perspective!
>
> Cheers,
> Thomas
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170324/b6034c2e/attachment.html>

From oliver at bestwalter.de  Mon Mar 27 16:42:59 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Mon, 27 Mar 2017 20:42:59 +0000
Subject: [pytest-dev] Suggestion: EuroPython pytest/tox/devpi helpdesk
Message-ID: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>

Hi all,

EuroPython is on the horizon and they have a new thing (or at least new for
me) called "helpdesk"

> Helpdesk / 10 slots

> Helpdesks are a great way to share your experience on a technology, by
offering to help people answering their questions and solving their
practical problems. You can run a helpdesk by yourself or with colleagues
and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
the morning and 1.5 hours in the afternoon. People looking for help will
sign up for a 30 minute slot and talk to you. There is no specific
preparation needed; you just need to be proficient in the technology you
run the helpdesk for.

see: https://ep2017.europython.eu/en/call-for-proposals/

I would be interested to try this and volunteer to help with questions
about tox mainly. Would anybody else interested in that kind of thing? If
we find a handful of people that would want to do that, we could have a
tox/pytest/devpi helpdesk :)

Cheers,
Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170327/5a8efc2d/attachment.html>

From genml+pytest-dev at thequod.de  Mon Mar 27 16:52:06 2017
From: genml+pytest-dev at thequod.de (Daniel Hahler)
Date: Mon, 27 Mar 2017 22:52:06 +0200
Subject: [pytest-dev] Travis auto-cancellation enabled
In-Reply-To: <CA+RQFffR6K8hJwZO+8bCQfmUphFz5UYXpNNhd-SmDfoZXvVPhg@mail.gmail.com>
References: <CA+RQFffR6K8hJwZO+8bCQfmUphFz5UYXpNNhd-SmDfoZXvVPhg@mail.gmail.com>
Message-ID: <f8027e09-bf61-0ea1-4454-c39d2725c92b@thequod.de>

On 22.03.2017 16:34, Bruno Oliveira wrote:

> More information here: https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation
> 
> I decided to go ahead and enable this as I believe it is a win-win situation, but if somebody disagrees please let me know.

It is OK for me.

Just a btw: I've found it useful to push e.g. HEAD~2, HEAD~1 and HEAD (if they are meant to be kept separate) after each other, so that I can be sure that git-bisect would not break if they get merged as-is (when Travis/GitHub marks them all green).

As for canceling queued builds, "git commit --amend" and force-pushing also causes jobs to fail when trying to clone the previous merge (but then jobs might be running already, of course).


Cheers,
Daniel.

From flub at devork.be  Tue Mar 28 02:44:58 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 28 Mar 2017 08:44:58 +0200
Subject: [pytest-dev] [proposal] using towncrier for merge-friendly
 changelog management
In-Reply-To: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
References: <9c6958e0-14bc-81c7-b220-35a3a08bcf0c@ronnypfannschmidt.de>
Message-ID: <CAAWk_DyGS0wvSNiOt5_=SusVhO5LrkNy0AXEHfYRkukGaVpNzw@mail.gmail.com>

This gets a big +1 from me, it would be great to have this done more easily.

On 21 Mar 2017 8:54 a.m., "Ronny Pfannschmidt" <
opensource at ronnypfannschmidt.de> wrote:

> Hi all,
>
> today i noticed how pip manages its change-logs in a pretty interesting
> way,
>
> they manage the fragments to be composed before a release in the folder
> "news" in files named like "$ticketnumber.$changetype"
> before a release those files get take out and composed into the change-log.
>
> The fabulous tool behind that is https://github.com/hawkowl/towncrier/ -
> after taking a first look at it,
> i believe it should be a massive enhancement compared to what we put
> ourselves trough right now.
>
> i also would be delighted, if we used it in more projects ^^
>
> cheers,
>
> Ronny
>
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170328/8dfe95a7/attachment.html>

From flub at devork.be  Tue Mar 28 02:49:39 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Tue, 28 Mar 2017 08:49:39 +0200
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
Message-ID: <CAAWk_Dx=Fp955=Pefb0MSYHi2HJw+MbYcaRY=626A41aMSFieg@mail.gmail.com>

This does sound like a good idea. I don't know yet if I'll be able to
attend EuroPython this year but would certainly like to help out with this
if I do.

Would you like to propose it?

On 27 Mar 2017 9:43 p.m., "Oliver Bestwalter" <oliver at bestwalter.de> wrote:

> Hi all,
>
> EuroPython is on the horizon and they have a new thing (or at least new
> for me) called "helpdesk"
>
> > Helpdesk / 10 slots
>
> > Helpdesks are a great way to share your experience on a technology, by
> offering to help people answering their questions and solving their
> practical problems. You can run a helpdesk by yourself or with colleagues
> and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
> the morning and 1.5 hours in the afternoon. People looking for help will
> sign up for a 30 minute slot and talk to you. There is no specific
> preparation needed; you just need to be proficient in the technology you
> run the helpdesk for.
>
> see: https://ep2017.europython.eu/en/call-for-proposals/
>
> I would be interested to try this and volunteer to help with questions
> about tox mainly. Would anybody else interested in that kind of thing? If
> we find a handful of people that would want to do that, we could have a
> tox/pytest/devpi helpdesk :)
>
> Cheers,
> Oliver
>
> _______________________________________________
> tox-dev mailing list
> tox-dev at python.org
> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170328/efa29394/attachment.html>

From dhunt at mozilla.com  Tue Mar 28 04:21:56 2017
From: dhunt at mozilla.com (Dave Hunt)
Date: Tue, 28 Mar 2017 09:21:56 +0100
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
Message-ID: <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>

I?m thinking of coming to EuroPython, and would be happy to spend some time at the helpdesk. My particular area of expertise would be the plugins I maintain, but I?m sure I can also answer some pytest/tox/devpi queries too.

Cheers,
Dave

> On 27 Mar 2017, at 21:42, Oliver Bestwalter <oliver at bestwalter.de> wrote:
> 
> Hi all,
> 
> EuroPython is on the horizon and they have a new thing (or at least new for me) called "helpdesk"
> 
> > Helpdesk / 10 slots
> 
> > Helpdesks are a great way to share your experience on a technology, by offering to help people answering their questions and solving their practical problems. You can run a helpdesk by yourself or with colleagues and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in the morning and 1.5 hours in the afternoon. People looking for help will sign up for a 30 minute slot and talk to you. There is no specific preparation needed; you just need to be proficient in the technology you run the helpdesk for.
> 
> see: https://ep2017.europython.eu/en/call-for-proposals/ <https://ep2017.europython.eu/en/call-for-proposals/>
> 
> I would be interested to try this and volunteer to help with questions about tox mainly. Would anybody else interested in that kind of thing? If we find a handful of people that would want to do that, we could have a tox/pytest/devpi helpdesk :)
> 
> Cheers,
> Oliver
> _______________________________________________
> tox-dev mailing list
> tox-dev at python.org
> https://mail.python.org/mm3/mailman3/lists/tox-dev.python.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170328/40cd7731/attachment-0001.html>

From holger at merlinux.eu  Wed Mar 29 10:30:21 2017
From: holger at merlinux.eu (holger krekel)
Date: Wed, 29 Mar 2017 16:30:21 +0200
Subject: [pytest-dev] doc/docs.pytest.org now proper with https
Message-ID: <20170329143021.2dxgyiivq25biadc@merlinux.eu>

Thanks to Florian Schulze who instantiated an nginx/letsencrypt
proxy on the planet.pytest.org pytest now serves ssl directly
(https://docs.pytest.org ) directly by proxying and reverse-proxying 
to readthedocs.org.  But we need an email admin address -- i can
create a "pytest-admin at pytest.org" alias which forwards to a 
couple of committers and we could also mention it in the
contacts page. Makes sense?
holger


From opensource at ronnypfannschmidt.de  Wed Mar 29 11:20:32 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 29 Mar 2017 17:20:32 +0200
Subject: [pytest-dev] doc/docs.pytest.org now proper with https
In-Reply-To: <20170329143021.2dxgyiivq25biadc@merlinux.eu>
References: <20170329143021.2dxgyiivq25biadc@merlinux.eu>
Message-ID: <b5876120-06c4-5d92-e241-2df39c429c73@ronnypfannschmidt.de>

+1


On 29.03.2017 16:30, holger krekel wrote:
> Thanks to Florian Schulze who instantiated an nginx/letsencrypt
> proxy on the planet.pytest.org pytest now serves ssl directly
> (https://docs.pytest.org ) directly by proxying and reverse-proxying 
> to readthedocs.org.  But we need an email admin address -- i can
> create a "pytest-admin at pytest.org" alias which forwards to a 
> couple of committers and we could also mention it in the
> contacts page. Makes sense?
> holger
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev


From nicoddemus at gmail.com  Wed Mar 29 11:35:32 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 29 Mar 2017 15:35:32 +0000
Subject: [pytest-dev] doc/docs.pytest.org now proper with https
In-Reply-To: <b5876120-06c4-5d92-e241-2df39c429c73@ronnypfannschmidt.de>
References: <20170329143021.2dxgyiivq25biadc@merlinux.eu>
 <b5876120-06c4-5d92-e241-2df39c429c73@ronnypfannschmidt.de>
Message-ID: <CA+RQFfc1pX47F_wAsFiPa9+_TbYP+bwnv2dBetbHNbDPB8fqyg@mail.gmail.com>

Sounds good!

On Wed, Mar 29, 2017 at 12:27 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> +1
>
>
> On 29.03.2017 16:30, holger krekel wrote:
> > Thanks to Florian Schulze who instantiated an nginx/letsencrypt
> > proxy on the planet.pytest.org pytest now serves ssl directly
> > (https://docs.pytest.org ) directly by proxying and reverse-proxying
> > to readthedocs.org.  But we need an email admin address -- i can
> > create a "pytest-admin at pytest.org" alias which forwards to a
> > couple of committers and we could also mention it in the
> > contacts page. Makes sense?
> > holger
> >
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170329/1a65f3f7/attachment.html>

From holger at merlinux.eu  Wed Mar 29 15:34:23 2017
From: holger at merlinux.eu (holger krekel)
Date: Wed, 29 Mar 2017 21:34:23 +0200
Subject: [pytest-dev] doc/docs.pytest.org now proper with https
In-Reply-To: <CA+RQFfc1pX47F_wAsFiPa9+_TbYP+bwnv2dBetbHNbDPB8fqyg@mail.gmail.com>
References: <20170329143021.2dxgyiivq25biadc@merlinux.eu>
 <b5876120-06c4-5d92-e241-2df39c429c73@ronnypfannschmidt.de>
 <CA+RQFfc1pX47F_wAsFiPa9+_TbYP+bwnv2dBetbHNbDPB8fqyg@mail.gmail.com>
Message-ID: <20170329193423.m3phpjq7zzldcd33@merlinux.eu>

On Wed, Mar 29, 2017 at 15:35 +0000, Bruno Oliveira wrote:
> Sounds good!

pytest-admin at pytest.org now points to a few people including the ones
who replied here :)
holger


> 
> On Wed, Mar 29, 2017 at 12:27 PM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
> 
> > +1
> >
> >
> > On 29.03.2017 16:30, holger krekel wrote:
> > > Thanks to Florian Schulze who instantiated an nginx/letsencrypt
> > > proxy on the planet.pytest.org pytest now serves ssl directly
> > > (https://docs.pytest.org ) directly by proxying and reverse-proxying
> > > to readthedocs.org.  But we need an email admin address -- i can
> > > create a "pytest-admin at pytest.org" alias which forwards to a
> > > couple of committers and we could also mention it in the
> > > contacts page. Makes sense?
> > > holger
> > >
> > > _______________________________________________
> > > pytest-dev mailing list
> > > pytest-dev at python.org
> > > https://mail.python.org/mailman/listinfo/pytest-dev
> >
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> >

From nicoddemus at gmail.com  Thu Mar 30 12:12:30 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 30 Mar 2017 16:12:30 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
Message-ID: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>

Hi all,

We are about to land on the features branch an implementation of the
proposal outlined by Florian Bruhin (
https://github.com/pytest-dev/pytest/issues/1830) where we introduce a
small helper to facilitate writing parametrized tests that sometimes raise
an error for an input parameter and sometimes don?t:

@pytest.mark.parametrize('inp, expectation', [
    (-1, pytest.raises(ValueError)),
    (3.5, pytest.raises(TypeError)),
    (5, pytest.does_not_raise),
    (10, pytest.does_not_raise),
])def test_bar(inp, expectation):
    with expectation:
        validate_positive_integer(inp)

The pytest.does_not_raise helper actually does nothing, is meant solely to
help writing this type of parametrized test.

The PR is at https://github.com/pytest-dev/pytest/pull/2339 and is ready
for merging, but this email is about *how to name it* since we had some
debate about it.

We have this proposals so far:

   - pytest.does_not_raise;
   - pytest.not_raises;
   - pytest.wont_raise;

So we would like to ask for opinions here because nailing down the name is
important.

*Another question* is if someone sees a problem in making it a singleton
like in the example above, or if we should force users instantiate it each
time: pytest.does_not_raise().

Cheers,
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170330/ae15d901/attachment.html>

From me at the-compiler.org  Thu Mar 30 12:50:50 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 30 Mar 2017 18:50:50 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
Message-ID: <20170330165050.4pdn5kcscecv322u@hooch>

Hi,

On Thu, Mar 30, 2017 at 04:12:30PM +0000, Bruno Oliveira wrote:
>    - pytest.does_not_raise;

I like that name - seems like proper English to me, while the others
don't.

> *Another question* is if someone sees a problem in making it a singleton
> like in the example above, or if we should force users instantiate it each
> time: pytest.does_not_raise().

Fine by me, I don't really have an opinion on this though.

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/

From opensource at ronnypfannschmidt.de  Thu Mar 30 13:38:55 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Thu, 30 Mar 2017 19:38:55 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170330165050.4pdn5kcscecv322u@hooch>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330165050.4pdn5kcscecv322u@hooch>
Message-ID: <38b1676f-c32e-472d-3878-434d92e5dad2@ronnypfannschmidt.de>

Hi,

after reading, i consider the naming of "does_not_raise" much more to
the point than "wont_raise" (my original wish),
so thanks a lot for pointing out that variant :)

i would prefer a singleton.

Cheers,
Ronny


On 30.03.2017 18:50, Florian Bruhin wrote:
> Hi,
>
> On Thu, Mar 30, 2017 at 04:12:30PM +0000, Bruno Oliveira wrote:
>>    - pytest.does_not_raise;
> I like that name - seems like proper English to me, while the others
> don't.
>
>> *Another question* is if someone sees a problem in making it a singleton
>> like in the example above, or if we should force users instantiate it each
>> time: pytest.does_not_raise().
> Fine by me, I don't really have an opinion on this though.
>
> Florian
>


From holger at merlinux.eu  Thu Mar 30 15:32:39 2017
From: holger at merlinux.eu (holger krekel)
Date: Thu, 30 Mar 2017 21:32:39 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
Message-ID: <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>

On Thu, Mar 30, 2017 at 16:12 +0000, Bruno Oliveira wrote:
> Hi all,
> 
> We are about to land on the features branch an implementation of the
> proposal outlined by Florian Bruhin (
> https://github.com/pytest-dev/pytest/issues/1830) where we introduce a
> small helper to facilitate writing parametrized tests that sometimes raise
> an error for an input parameter and sometimes don?t:
> 
> @pytest.mark.parametrize('inp, expectation', [
>     (-1, pytest.raises(ValueError)),
>     (3.5, pytest.raises(TypeError)),
>     (5, pytest.does_not_raise),
>     (10, pytest.does_not_raise),
> ])def test_bar(inp, expectation):
>     with expectation:
>         validate_positive_integer(inp)
> 
> The pytest.does_not_raise helper actually does nothing, is meant solely to
> help writing this type of parametrized test.

It's a bit odd to introduce a new helper just for this particular case.
After skimming https://github.com/pytest-dev/pytest/issues/1830 
i'd prefer the mentioned pytest.raises(None) solution which lets through all exceptions
of the dependent code block.  Adding an example to the pytest docs and extending
the pytest.raises help string and implementation would be enough IMO.
By contrast, adding a new helper feels like unneccessary clutter of 
the pytest.* namespace. The above would then be:

 @pytest.mark.parametrize('inp, expectation', [
     (-1, ValueError),
     (3.5, TypeError),
     (5, None),
     (10, None)])
 def test_bar(inp, expectation):
     with pytest.raises(expectation):
         validate_positive_integer(inp)

where the parametrization is shorter and if one does not know
what pytest.raises(None) means one could find it easily in the
doc string or the pytest docs.

holger

From nicoddemus at gmail.com  Thu Mar 30 17:03:45 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 30 Mar 2017 21:03:45 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
Message-ID: <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>

On Thu, Mar 30, 2017 at 4:32 PM holger krekel <holger at merlinux.eu> wrote:

> It's a bit odd to introduce a new helper just for this particular case.
> After skimming https://github.com/pytest-dev/pytest/issues/1830
> i'd prefer the mentioned pytest.raises(None) solution which lets through
> all exceptions
> of the dependent code block.  Adding an example to the pytest docs and
> extending
> the pytest.raises help string and implementation would be enough IMO.
> By contrast, adding a new helper feels like unneccessary clutter of
> the pytest.* namespace. The above would then be:
>
>  @pytest.mark.parametrize('inp, expectation', [
>      (-1, ValueError),
>      (3.5, TypeError),
>      (5, None),
>      (10, None)])
>  def test_bar(inp, expectation):
>      with pytest.raises(expectation):
>          validate_positive_integer(inp)
>
> where the parametrization is shorter and if one does not know
> what pytest.raises(None) means one could find it easily in the
> doc string or the pytest docs.
>

I agree. Does anybody else still prefers the original proposal?

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170330/3062a594/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Thu Mar 30 17:08:06 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Thu, 30 Mar 2017 23:08:06 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
Message-ID: <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>

I do because we make something a "magical god function" again, more of the rant tommorow.

Gn8, Ronny

Am 30. M?rz 2017 23:03:45 MESZ schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>On Thu, Mar 30, 2017 at 4:32 PM holger krekel <holger at merlinux.eu>
>wrote:
>
>> It's a bit odd to introduce a new helper just for this particular
>case.
>> After skimming https://github.com/pytest-dev/pytest/issues/1830
>> i'd prefer the mentioned pytest.raises(None) solution which lets
>through
>> all exceptions
>> of the dependent code block.  Adding an example to the pytest docs
>and
>> extending
>> the pytest.raises help string and implementation would be enough IMO.
>> By contrast, adding a new helper feels like unneccessary clutter of
>> the pytest.* namespace. The above would then be:
>>
>>  @pytest.mark.parametrize('inp, expectation', [
>>      (-1, ValueError),
>>      (3.5, TypeError),
>>      (5, None),
>>      (10, None)])
>>  def test_bar(inp, expectation):
>>      with pytest.raises(expectation):
>>          validate_positive_integer(inp)
>>
>> where the parametrization is shorter and if one does not know
>> what pytest.raises(None) means one could find it easily in the
>> doc string or the pytest docs.
>>
>
>I agree. Does anybody else still prefers the original proposal?
>
>Cheers,
>Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170330/c05e023e/attachment.html>

From opensource at ronnypfannschmidt.de  Thu Mar 30 17:08:06 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Thu, 30 Mar 2017 23:08:06 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
Message-ID: <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>

I do because we make something a "magical god function" again, more of the rant tommorow.

Gn8, Ronny

Am 30. M?rz 2017 23:03:45 MESZ schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>On Thu, Mar 30, 2017 at 4:32 PM holger krekel <holger at merlinux.eu>
>wrote:
>
>> It's a bit odd to introduce a new helper just for this particular
>case.
>> After skimming https://github.com/pytest-dev/pytest/issues/1830
>> i'd prefer the mentioned pytest.raises(None) solution which lets
>through
>> all exceptions
>> of the dependent code block.  Adding an example to the pytest docs
>and
>> extending
>> the pytest.raises help string and implementation would be enough IMO.
>> By contrast, adding a new helper feels like unneccessary clutter of
>> the pytest.* namespace. The above would then be:
>>
>>  @pytest.mark.parametrize('inp, expectation', [
>>      (-1, ValueError),
>>      (3.5, TypeError),
>>      (5, None),
>>      (10, None)])
>>  def test_bar(inp, expectation):
>>      with pytest.raises(expectation):
>>          validate_positive_integer(inp)
>>
>> where the parametrization is shorter and if one does not know
>> what pytest.raises(None) means one could find it easily in the
>> doc string or the pytest docs.
>>
>
>I agree. Does anybody else still prefers the original proposal?
>
>Cheers,
>Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170330/c05e023e/attachment-0001.html>

From holger at merlinux.eu  Thu Mar 30 17:36:36 2017
From: holger at merlinux.eu (holger krekel)
Date: Thu, 30 Mar 2017 23:36:36 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
Message-ID: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>

On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:
> I do because we make something a "magical god function" again, more of the rant tommorow.

God functions or objects are usually ones that do many different things.
Here, "pytest.raises" deals with the dependent code block's exception 
raising behaviour -- allowing None (to signal: no exception expected) 
does not change or much extend this functionality.

holger




> Gn8, Ronny
> 
> Am 30. M?rz 2017 23:03:45 MESZ schrieb Bruno Oliveira <nicoddemus at gmail.com>:
> >On Thu, Mar 30, 2017 at 4:32 PM holger krekel <holger at merlinux.eu>
> >wrote:
> >
> >> It's a bit odd to introduce a new helper just for this particular
> >case.
> >> After skimming https://github.com/pytest-dev/pytest/issues/1830
> >> i'd prefer the mentioned pytest.raises(None) solution which lets
> >through
> >> all exceptions
> >> of the dependent code block.  Adding an example to the pytest docs
> >and
> >> extending
> >> the pytest.raises help string and implementation would be enough IMO.
> >> By contrast, adding a new helper feels like unneccessary clutter of
> >> the pytest.* namespace. The above would then be:
> >>
> >>  @pytest.mark.parametrize('inp, expectation', [
> >>      (-1, ValueError),
> >>      (3.5, TypeError),
> >>      (5, None),
> >>      (10, None)])
> >>  def test_bar(inp, expectation):
> >>      with pytest.raises(expectation):
> >>          validate_positive_integer(inp)
> >>
> >> where the parametrization is shorter and if one does not know
> >> what pytest.raises(None) means one could find it easily in the
> >> doc string or the pytest docs.
> >>
> >
> >I agree. Does anybody else still prefers the original proposal?
> >
> >Cheers,
> >Bruno.

From mail at florian-schulze.net  Fri Mar 31 02:13:28 2017
From: mail at florian-schulze.net (Florian Schulze)
Date: Fri, 31 Mar 2017 08:13:28 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
Message-ID: <4614C930-301B-4EB9-A6B8-A120A26E15E9@florian-schulze.net>

On 30 Mar 2017, at 23:36, holger krekel wrote:

> On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:
>> I do because we make something a "magical god function" again, more 
>> of the rant tommorow.
>
> God functions or objects are usually ones that do many different 
> things.
> Here, "pytest.raises" deals with the dependent code block's exception
> raising behaviour -- allowing None (to signal: no exception expected)
> does not change or much extend this functionality.

I think it also reads well. Which exceptions are expected to be raised? 
None.

Regards,
Florian Schulze

From vince.reuter at gmail.com  Fri Mar 31 03:26:37 2017
From: vince.reuter at gmail.com (Vince Reuter)
Date: Fri, 31 Mar 2017 03:26:37 -0400
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <4614C930-301B-4EB9-A6B8-A120A26E15E9@florian-schulze.net>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <4614C930-301B-4EB9-A6B8-A120A26E15E9@florian-schulze.net>
Message-ID: <CA+CGCHZBGJyMxf0XbLfJrSAaFaq=y1sa5H_TP1bbgMA+pBzR1w@mail.gmail.com>

Strictly from a user perspective here, but assertRaises(None) seems most
clear & intuitive.

On Fri, Mar 31, 2017 at 2:13 AM, Florian Schulze <mail at florian-schulze.net>
wrote:

> On 30 Mar 2017, at 23:36, holger krekel wrote:
>
> On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:
>>
>>> I do because we make something a "magical god function" again, more of
>>> the rant tommorow.
>>>
>>
>> God functions or objects are usually ones that do many different things.
>> Here, "pytest.raises" deals with the dependent code block's exception
>> raising behaviour -- allowing None (to signal: no exception expected)
>> does not change or much extend this functionality.
>>
>
> I think it also reads well. Which exceptions are expected to be raised?
> None.
>
> Regards,
> Florian Schulze
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170331/d62cb3e3/attachment-0001.html>

From opensource at ronnypfannschmidt.de  Fri Mar 31 03:55:53 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Fri, 31 Mar 2017 09:55:53 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
Message-ID: <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>

Hi Holger,

what we do here is to add support for "inverted behavior" to a function!

this is a direct increase in inner complexity that looks easy on the
outside, but is not all all simple on the inside

its changes like that that ensure maintenance pain in future,

in reference, just take a look at marks,

that get copied around between different classes on a inheritance tree
and are a major mess to fix because of the sheer amount of easy changes
that being them to where they are now

same goes for the mess with fixture declaration that double as object
caches braking
while trying to introduce multi-skoped fixtures.

I am increasingly hostile to "easy" things that have a larger cost in
inner complexity,
because we don't have full time employees to deal with the fallout.

And the needless increase in complexity directly devalues the time i
spend volunteering
(because fixing finer details gets so much harder when complexity increases)

And with a Kid on the way i'm no longer willing to take those kinds of
blows in personal time at least.

-- Ronny


On 30.03.2017 23:36, holger krekel wrote:
> On Thu, Mar 30, 2017 at 23:08 +0200, Ronny Pfannschmidt wrote:
>> I do because we make something a "magical god function" again, more of the rant tommorow.
> God functions or objects are usually ones that do many different things.
> Here, "pytest.raises" deals with the dependent code block's exception 
> raising behaviour -- allowing None (to signal: no exception expected) 
> does not change or much extend this functionality.
>
> holger
>
>
>
>
>> Gn8, Ronny
>>
>> Am 30. M?rz 2017 23:03:45 MESZ schrieb Bruno Oliveira <nicoddemus at gmail.com>:
>>> On Thu, Mar 30, 2017 at 4:32 PM holger krekel <holger at merlinux.eu>
>>> wrote:
>>>
>>>> It's a bit odd to introduce a new helper just for this particular
>>> case.
>>>> After skimming https://github.com/pytest-dev/pytest/issues/1830
>>>> i'd prefer the mentioned pytest.raises(None) solution which lets
>>> through
>>>> all exceptions
>>>> of the dependent code block.  Adding an example to the pytest docs
>>> and
>>>> extending
>>>> the pytest.raises help string and implementation would be enough IMO.
>>>> By contrast, adding a new helper feels like unneccessary clutter of
>>>> the pytest.* namespace. The above would then be:
>>>>
>>>>  @pytest.mark.parametrize('inp, expectation', [
>>>>      (-1, ValueError),
>>>>      (3.5, TypeError),
>>>>      (5, None),
>>>>      (10, None)])
>>>>  def test_bar(inp, expectation):
>>>>      with pytest.raises(expectation):
>>>>          validate_positive_integer(inp)
>>>>
>>>> where the parametrization is shorter and if one does not know
>>>> what pytest.raises(None) means one could find it easily in the
>>>> doc string or the pytest docs.
>>>>
>>> I agree. Does anybody else still prefers the original proposal?
>>>
>>> Cheers,
>>> Bruno.



From holger at merlinux.eu  Fri Mar 31 04:30:59 2017
From: holger at merlinux.eu (holger krekel)
Date: Fri, 31 Mar 2017 10:30:59 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
Message-ID: <20170331083059.b7mekieurttsqj2t@merlinux.eu>

Hi Ronny,

On Fri, Mar 31, 2017 at 09:55 +0200, Ronny Pfannschmidt wrote:
> Hi Holger,
> 
> what we do here is to add support for "inverted behavior" to a function!
> 
> this is a direct increase in inner complexity that looks easy on the
> outside, but is not all all simple on the inside

The complexity of pytest.raises stems from its 10 years history of
supporting exception-control interactions with the dependent code block
and especially the grown ways to specify the code blocks -- as a string,
as function with args and finally through a context manager.  

Now, allowing None to mean "no exception expected" is not changing the
meaning of the "expected_exception" argument like string-func-contextmanager
did for the rest of the pytest.raises arguments.

> its changes like that that ensure maintenance pain in future,
> 
> in reference, just take a look at marks,
> 
> that get copied around between different classes on a inheritance tree
> and are a major mess to fix because of the sheer amount of easy changes
> that being them to where they are now

i never considered marks easy and some early decisions lead to later
complexity, agreed.  And let's not talk of the wonderful collection tree ...
 
> same goes for the mess with fixture declaration that double as object
> caches braking
> while trying to introduce multi-skoped fixtures.
> 
> I am increasingly hostile to "easy" things that have a larger cost in
> inner complexity,
> because we don't have full time employees to deal with the fallout.
> 
> And the needless increase in complexity directly devalues the time i
> spend volunteering
> (because fixing finer details gets so much harder when complexity increases)
> 
> And with a Kid on the way i'm no longer willing to take those kinds of
> blows in personal time at least.

Mine just turned six and i can relate to such considerations ... and i agree
it's worthwhile to be critical when "easy" is used for advertising a
change -- e.g. i was skeptical with merging pytest.yield_fixture and
pytest.fixture for that reason but eventually was ok with it because the 
concrete code changes did not look too frightening ...  so, the
pytest.raises(None) change has roughly this patch (docs missing):

    diff --git a/_pytest/python.py b/_pytest/python.py
    index 59492bc4..32954ad4 100644
    --- a/_pytest/python.py
    +++ b/_pytest/python.py
    @@ -1175,20 +1175,22 @@ def raises(expected_exception, *args, **kwargs):
     
         """
         __tracebackhide__ = True
         if expected_exception is AssertionError:
             # we want to catch a AssertionError
             # replace our subclass with the builtin one
             # see https://github.com/pytest-dev/pytest/issues/176
             from _pytest.assertion.util import BuiltinAssertionError \
                 as expected_exception
    -    msg = ("exceptions must be old-style classes or"
    -           " derived from BaseException, not %s")
    -    if isinstance(expected_exception, tuple):
    -        for exc in expected_exception:
    -            if not isclass(exc):
    -                raise TypeError(msg % type(exc))
    -    elif not isclass(expected_exception):
    -        raise TypeError(msg % type(expected_exception))
    +    elif expected_exception is not None:
    +        msg = ("exceptions must be old-style classes or"
    +               " derived from BaseException, not %s")
    +        if isinstance(expected_exception, tuple):
    +            for exc in expected_exception:
    +                if not isclass(exc):
    +                    raise TypeError(msg % type(exc))
    +        elif not isclass(expected_exception):
    +            raise TypeError(msg % type(expected_exception))
     
         message = "DID NOT RAISE {0}".format(expected_exception)
     
    @@ -1231,6 +1233,8 @@ class RaisesContext(object):
         def __exit__(self, *tp):
             __tracebackhide__ = True
             if tp[0] is None:
    +            if self.expected_exception is None:
    +                return
                 pytest.fail(self.message)
             if sys.version_info < (2, 7):
                 # py26: on __exit__() exc_value often does not contain the
    @@ -1240,7 +1244,8 @@ class RaisesContext(object):
                     exc_type, value, traceback = tp
                     tp = exc_type, exc_type(value), traceback
             self.excinfo.__init__(tp)
    -        suppress_exception = issubclass(self.excinfo.type, self.expected_exception)
    +        suppress_exception = self.expected_exception is not None and \
    +                             issubclass(self.excinfo.type, self.expected_exception)
             if sys.version_info[0] == 2 and suppress_exception:
                 sys.exc_clear()
             return suppress_exception
    diff --git a/testing/python/raises.py b/testing/python/raises.py
    index 8f141cfa..17a30dc6 100644
    --- a/testing/python/raises.py
    +++ b/testing/python/raises.py
    @@ -126,3 +126,10 @@ class TestRaises:
             for o in gc.get_objects():
                 assert type(o) is not T
     
    +    def test_raises_non(self):
    +        with pytest.raises(None):
    +            pass
    +
    +        with pytest.raises(ValueError):
    +            with pytest.raises(None):
    +                raise ValueError


Does this really look like increasing maintenance and complexity that much?
I suggest to look concretely at things here and not further argue from first
principles and ... well, a sleepless night because of sudden child illness 
is orders of magnitudes more draining like i experienced two days ago ...

holger

From kvas.it at gmail.com  Fri Mar 31 06:13:45 2017
From: kvas.it at gmail.com (Vasily Kuznetsov)
Date: Fri, 31 Mar 2017 10:13:45 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170331083059.b7mekieurttsqj2t@merlinux.eu>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
Message-ID: <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>

Hi Holger and Ronny,

I see merit in both of your points. All those "is not None" checks in
between other logic and the proposed "raises unless the argument is None"
semantics of pytest.raises do increase complexity (I'm not qualified to
predict whether or not this increase is significant in terms of further
maintenance though) but at the same time "pytest.raises(None)" API is
convenient in some cases. What if we do something like this:

diff --git a/_pytest/python.py b/_pytest/python.py
index e763aa8..27ece6b 100644
--- a/_pytest/python.py
+++ b/_pytest/python.py
@@ -131,6 +131,7 @@ def pytest_namespace():
     raises.Exception = pytest.fail.Exception
     return {
         'raises': raises,
+        'does_not_raise': does_not_raise,
         'approx': approx,
         'collect': {
             'Module': Module,
@@ -1194,6 +1195,8 @@ def raises(expected_exception, *args, **kwargs):
         information.

     """
+    if expected_exception is None:
+        return does_not_raise
     __tracebackhide__ = True
     msg = ("exceptions must be old-style classes or"
            " derived from BaseException, not %s")
@@ -1267,6 +1270,17 @@ class RaisesContext(object):
         return suppress_exception


+class DoesNotRaiseContext(object):
+    def __enter__(self):
+        pass
+
+    def __exit__(self, *tp):
+        pass
+
+
+does_not_raise = DoesNotRaiseContext()
+
+
 # builtin pytest.approx helper

 class approx(object):
diff --git a/testing/python/raises.py b/testing/python/raises.py
index 21a6f80..b00fe28 100644
--- a/testing/python/raises.py
+++ b/testing/python/raises.py
@@ -118,6 +118,17 @@ class TestRaises(object):
         for o in gc.get_objects():
             assert type(o) is not T

+    @pytest.mark.parametrize('does_not_raise', [
+        pytest.does_not_raise,
+        pytest.raises(None)
+    ])
+    def test_does_not_raise(self, does_not_raise):
+        with does_not_raise:
+            pass
+
+        with pytest.raises(ValueError):
+            with does_not_raise:
+                raise ValueError

     def test_raises_match(self):
         msg = r"with base \d+"

The "is not None" checks are gone from the main logic and both APIs are
available. Or if we would rather not have more than one way to do it, we
can drop "does_not_raise" but otherwise still keep it a separate context.

Seems like if we can agree on the API, a not-complexity-increasing option
of implementation is possible.

Cheers,
Vasily

On Fri, Mar 31, 2017 at 10:31 AM holger krekel <holger at merlinux.eu> wrote:

> Hi Ronny,
>
> On Fri, Mar 31, 2017 at 09:55 +0200, Ronny Pfannschmidt wrote:
> > Hi Holger,
> >
> > what we do here is to add support for "inverted behavior" to a function!
> >
> > this is a direct increase in inner complexity that looks easy on the
> > outside, but is not all all simple on the inside
>
> The complexity of pytest.raises stems from its 10 years history of
> supporting exception-control interactions with the dependent code block
> and especially the grown ways to specify the code blocks -- as a string,
> as function with args and finally through a context manager.
>
> Now, allowing None to mean "no exception expected" is not changing the
> meaning of the "expected_exception" argument like
> string-func-contextmanager
> did for the rest of the pytest.raises arguments.
>
> > its changes like that that ensure maintenance pain in future,
> >
> > in reference, just take a look at marks,
> >
> > that get copied around between different classes on a inheritance tree
> > and are a major mess to fix because of the sheer amount of easy changes
> > that being them to where they are now
>
> i never considered marks easy and some early decisions lead to later
> complexity, agreed.  And let's not talk of the wonderful collection tree
> ...
>
> > same goes for the mess with fixture declaration that double as object
> > caches braking
> > while trying to introduce multi-skoped fixtures.
> >
> > I am increasingly hostile to "easy" things that have a larger cost in
> > inner complexity,
> > because we don't have full time employees to deal with the fallout.
> >
> > And the needless increase in complexity directly devalues the time i
> > spend volunteering
> > (because fixing finer details gets so much harder when complexity
> increases)
> >
> > And with a Kid on the way i'm no longer willing to take those kinds of
> > blows in personal time at least.
>
> Mine just turned six and i can relate to such considerations ... and i
> agree
> it's worthwhile to be critical when "easy" is used for advertising a
> change -- e.g. i was skeptical with merging pytest.yield_fixture and
> pytest.fixture for that reason but eventually was ok with it because the
> concrete code changes did not look too frightening ...  so, the
> pytest.raises(None) change has roughly this patch (docs missing):
>
>     diff --git a/_pytest/python.py b/_pytest/python.py
>     index 59492bc4..32954ad4 100644
>     --- a/_pytest/python.py
>     +++ b/_pytest/python.py
>     @@ -1175,20 +1175,22 @@ def raises(expected_exception, *args,
> **kwargs):
>
>          """
>          __tracebackhide__ = True
>          if expected_exception is AssertionError:
>              # we want to catch a AssertionError
>              # replace our subclass with the builtin one
>              # see https://github.com/pytest-dev/pytest/issues/176
>              from _pytest.assertion.util import BuiltinAssertionError \
>                  as expected_exception
>     -    msg = ("exceptions must be old-style classes or"
>     -           " derived from BaseException, not %s")
>     -    if isinstance(expected_exception, tuple):
>     -        for exc in expected_exception:
>     -            if not isclass(exc):
>     -                raise TypeError(msg % type(exc))
>     -    elif not isclass(expected_exception):
>     -        raise TypeError(msg % type(expected_exception))
>     +    elif expected_exception is not None:
>     +        msg = ("exceptions must be old-style classes or"
>     +               " derived from BaseException, not %s")
>     +        if isinstance(expected_exception, tuple):
>     +            for exc in expected_exception:
>     +                if not isclass(exc):
>     +                    raise TypeError(msg % type(exc))
>     +        elif not isclass(expected_exception):
>     +            raise TypeError(msg % type(expected_exception))
>
>          message = "DID NOT RAISE {0}".format(expected_exception)
>
>     @@ -1231,6 +1233,8 @@ class RaisesContext(object):
>          def __exit__(self, *tp):
>              __tracebackhide__ = True
>              if tp[0] is None:
>     +            if self.expected_exception is None:
>     +                return
>                  pytest.fail(self.message)
>              if sys.version_info < (2, 7):
>                  # py26: on __exit__() exc_value often does not contain the
>     @@ -1240,7 +1244,8 @@ class RaisesContext(object):
>                      exc_type, value, traceback = tp
>                      tp = exc_type, exc_type(value), traceback
>              self.excinfo.__init__(tp)
>     -        suppress_exception = issubclass(self.excinfo.type,
> self.expected_exception)
>     +        suppress_exception = self.expected_exception is not None and \
>     +                             issubclass(self.excinfo.type,
> self.expected_exception)
>              if sys.version_info[0] == 2 and suppress_exception:
>                  sys.exc_clear()
>              return suppress_exception
>     diff --git a/testing/python/raises.py b/testing/python/raises.py
>     index 8f141cfa..17a30dc6 100644
>     --- a/testing/python/raises.py
>     +++ b/testing/python/raises.py
>     @@ -126,3 +126,10 @@ class TestRaises:
>              for o in gc.get_objects():
>                  assert type(o) is not T
>
>     +    def test_raises_non(self):
>     +        with pytest.raises(None):
>     +            pass
>     +
>     +        with pytest.raises(ValueError):
>     +            with pytest.raises(None):
>     +                raise ValueError
>
>
> Does this really look like increasing maintenance and complexity that much?
> I suggest to look concretely at things here and not further argue from
> first
> principles and ... well, a sleepless night because of sudden child illness
> is orders of magnitudes more draining like i experienced two days ago ...
>
> holger
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170331/3ff79409/attachment-0001.html>

From nicoddemus at gmail.com  Fri Mar 31 07:24:34 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 31 Mar 2017 11:24:34 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
References: <CA+RQFffX5FXnEbgiZF5WsYjULtEB+=OCRq9Si2RoEN8-dRekew@mail.gmail.com>
 <20170330193239.ez3z6ginj7cs6n5z@merlinux.eu>
 <CA+RQFfcpXYiT=C_=wyYw_KJAwAgZ1jkizPgJzzUvPoWAw97_4Q@mail.gmail.com>
 <E5318850-CF1D-4B76-B5A3-54226823A8E2@ronnypfannschmidt.de>
 <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
Message-ID: <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>

Hi all,

On Fri, Mar 31, 2017 at 7:13 AM Vasily Kuznetsov <kvas.it at gmail.com> wrote:

> Hi Holger and Ronny,
>
> I see merit in both of your points. All those "is not None" checks in
> between other logic and the proposed "raises unless the argument is None"
> semantics of pytest.raises do increase complexity (I'm not qualified to
> predict whether or not this increase is significant in terms of further
> maintenance though) but at the same time "pytest.raises(None)" API is
> convenient in some cases. What if we do something like this:
> ...
> The "is not None" checks are gone from the main logic and both APIs are
> available. Or if we would rather not have more than one way to do it, we
> can drop "does_not_raise" but otherwise still keep it a separate context.
>
> Seems like if we can agree on the API, a not-complexity-increasing option
> of implementation is possible.
>

Thanks for that Vasily!

I sympathize with Ronny's points about the problem of apparently harmless
changes on the outside causing increase in internal complexity being a
problem for maintenance down the road. We should also strive to refactor
the known pain points of the internal code (mark handling and fixture cache
come readily to mind), and Ronny is the main champion in that regard.

I agree with Holger's sentiment of aiming for the user interface we feel is
better, but we must then look at the implementation and weigh the cost of
maintenance and increased complexity and step back if we find it too costly.

Now for the specific case of pytest.raises(None), I believe we can strike a
good balance between a nice user interface and minimal internal impact like
Vasily proposes, unless Ronny or others feel that pytest.raises(None) is
not a good interface for this functionality.

My 2 cc.

Cheers,
Bruno.



> Cheers,
> Vasily
>
> On Fri, Mar 31, 2017 at 10:31 AM holger krekel <holger at merlinux.eu> wrote:
>
> Hi Ronny,
>
> On Fri, Mar 31, 2017 at 09:55 +0200, Ronny Pfannschmidt wrote:
> > Hi Holger,
> >
> > what we do here is to add support for "inverted behavior" to a function!
> >
> > this is a direct increase in inner complexity that looks easy on the
> > outside, but is not all all simple on the inside
>
> The complexity of pytest.raises stems from its 10 years history of
> supporting exception-control interactions with the dependent code block
> and especially the grown ways to specify the code blocks -- as a string,
> as function with args and finally through a context manager.
>
> Now, allowing None to mean "no exception expected" is not changing the
> meaning of the "expected_exception" argument like
> string-func-contextmanager
> did for the rest of the pytest.raises arguments.
>
> > its changes like that that ensure maintenance pain in future,
> >
> > in reference, just take a look at marks,
> >
> > that get copied around between different classes on a inheritance tree
> > and are a major mess to fix because of the sheer amount of easy changes
> > that being them to where they are now
>
> i never considered marks easy and some early decisions lead to later
> complexity, agreed.  And let's not talk of the wonderful collection tree
> ...
>
> > same goes for the mess with fixture declaration that double as object
> > caches braking
> > while trying to introduce multi-skoped fixtures.
> >
> > I am increasingly hostile to "easy" things that have a larger cost in
> > inner complexity,
> > because we don't have full time employees to deal with the fallout.
> >
> > And the needless increase in complexity directly devalues the time i
> > spend volunteering
> > (because fixing finer details gets so much harder when complexity
> increases)
> >
> > And with a Kid on the way i'm no longer willing to take those kinds of
> > blows in personal time at least.
>
> Mine just turned six and i can relate to such considerations ... and i
> agree
> it's worthwhile to be critical when "easy" is used for advertising a
> change -- e.g. i was skeptical with merging pytest.yield_fixture and
> pytest.fixture for that reason but eventually was ok with it because the
> concrete code changes did not look too frightening ...  so, the
> pytest.raises(None) change has roughly this patch (docs missing):
>
>     diff --git a/_pytest/python.py b/_pytest/python.py
>     index 59492bc4..32954ad4 100644
>     --- a/_pytest/python.py
>     +++ b/_pytest/python.py
>     @@ -1175,20 +1175,22 @@ def raises(expected_exception, *args,
> **kwargs):
>
>          """
>          __tracebackhide__ = True
>          if expected_exception is AssertionError:
>              # we want to catch a AssertionError
>              # replace our subclass with the builtin one
>              # see https://github.com/pytest-dev/pytest/issues/176
>              from _pytest.assertion.util import BuiltinAssertionError \
>                  as expected_exception
>     -    msg = ("exceptions must be old-style classes or"
>     -           " derived from BaseException, not %s")
>     -    if isinstance(expected_exception, tuple):
>     -        for exc in expected_exception:
>     -            if not isclass(exc):
>     -                raise TypeError(msg % type(exc))
>     -    elif not isclass(expected_exception):
>     -        raise TypeError(msg % type(expected_exception))
>     +    elif expected_exception is not None:
>     +        msg = ("exceptions must be old-style classes or"
>     +               " derived from BaseException, not %s")
>     +        if isinstance(expected_exception, tuple):
>     +            for exc in expected_exception:
>     +                if not isclass(exc):
>     +                    raise TypeError(msg % type(exc))
>     +        elif not isclass(expected_exception):
>     +            raise TypeError(msg % type(expected_exception))
>
>          message = "DID NOT RAISE {0}".format(expected_exception)
>
>     @@ -1231,6 +1233,8 @@ class RaisesContext(object):
>          def __exit__(self, *tp):
>              __tracebackhide__ = True
>              if tp[0] is None:
>     +            if self.expected_exception is None:
>     +                return
>                  pytest.fail(self.message)
>              if sys.version_info < (2, 7):
>                  # py26: on __exit__() exc_value often does not contain the
>     @@ -1240,7 +1244,8 @@ class RaisesContext(object):
>                      exc_type, value, traceback = tp
>                      tp = exc_type, exc_type(value), traceback
>              self.excinfo.__init__(tp)
>     -        suppress_exception = issubclass(self.excinfo.type,
> self.expected_exception)
>     +        suppress_exception = self.expected_exception is not None and \
>     +                             issubclass(self.excinfo.type,
> self.expected_exception)
>              if sys.version_info[0] == 2 and suppress_exception:
>                  sys.exc_clear()
>              return suppress_exception
>     diff --git a/testing/python/raises.py b/testing/python/raises.py
>     index 8f141cfa..17a30dc6 100644
>     --- a/testing/python/raises.py
>     +++ b/testing/python/raises.py
>     @@ -126,3 +126,10 @@ class TestRaises:
>              for o in gc.get_objects():
>                  assert type(o) is not T
>
>     +    def test_raises_non(self):
>     +        with pytest.raises(None):
>     +            pass
>     +
>     +        with pytest.raises(ValueError):
>     +            with pytest.raises(None):
>     +                raise ValueError
>
>
> Does this really look like increasing maintenance and complexity that much?
> I suggest to look concretely at things here and not further argue from
> first
> principles and ... well, a sleepless night because of sudden child illness
> is orders of magnitudes more draining like i experienced two days ago ...
>
> holger
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170331/87ce346a/attachment.html>