From oliver at bestwalter.de  Mon Apr  3 10:25:33 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Mon, 03 Apr 2017 14:25:33 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
Message-ID: <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>

Hi all,

I just got the green light to go to EuroPython, so I volunteer to do the
proposal and in the worst case I will be helpdesking away on my own, but I
sincerely hope that a few of you will be there and join me :)

I would also be willing to help organizing/being part of sprints at the
weekend.

Cheers
Oliver

On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dhunt at mozilla.com> wrote:

> 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/
>
> 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/20170403/a67c13ba/attachment.html>

From contact at ionelmc.ro  Mon Apr  3 10:51:20 2017
From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 3 Apr 2017 17:51:20 +0300
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>
Message-ID: <CANkHFr_SmvcOyqC9biHjYQ65NGLwwyWA5G0QCArv1HKYy-J6uw@mail.gmail.com>

I'm interested in this as well (pytest-cov/benchmark and general pytest
help) but what are the guidelines? I suppose there is no space for a 10
people "pytest-*" helpdesk. The CFP page is very scarce on information.
Anyone already asked organizers for more info?


Thanks,
-- Ionel Cristian M?rie?, http://blog.ionelmc.ro

On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oliver at bestwalter.de>
wrote:

> Hi all,
>
> I just got the green light to go to EuroPython, so I volunteer to do the
> proposal and in the worst case I will be helpdesking away on my own, but I
> sincerely hope that a few of you will be there and join me :)
>
> I would also be willing to help organizing/being part of sprints at the
> weekend.
>
> Cheers
> Oliver
>
> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dhunt at mozilla.com> wrote:
>
>> 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/
>>
>> 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/
>>
>>
> _______________________________________________
> 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/20170403/0953f273/attachment.html>

From oliver at bestwalter.de  Mon Apr  3 16:57:08 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Mon, 03 Apr 2017 20:57:08 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CANkHFr_SmvcOyqC9biHjYQ65NGLwwyWA5G0QCArv1HKYy-J6uw@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>
 <CANkHFr_SmvcOyqC9biHjYQ65NGLwwyWA5G0QCArv1HKYy-J6uw@mail.gmail.com>
Message-ID: <CAG5CgtofwHbQOsmzsO11AxXjs5yN9r3uGqpx+eo7b_wRpWj3Cw@mail.gmail.com>

Hi,

I wrote a mail to ask. I also noticed that the call for proposals is closed
already, I asked anyway - maybe there is still some room for us.

Cheers
Oliver

On Mon, 3 Apr 2017 at 16:51 Ionel Cristian M?rie? <contact at ionelmc.ro>
wrote:

> I'm interested in this as well (pytest-cov/benchmark and general pytest
> help) but what are the guidelines? I suppose there is no space for a 10
> people "pytest-*" helpdesk. The CFP page is very scarce on information.
> Anyone already asked organizers for more info?
>
>
> Thanks,
> -- Ionel Cristian M?rie?, http://blog.ionelmc.ro
>
> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oliver at bestwalter.de>
> wrote:
>
> Hi all,
>
> I just got the green light to go to EuroPython, so I volunteer to do the
> proposal and in the worst case I will be helpdesking away on my own, but I
> sincerely hope that a few of you will be there and join me :)
>
> I would also be willing to help organizing/being part of sprints at the
> weekend.
>
> Cheers
> Oliver
>
> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dhunt at mozilla.com> wrote:
>
> 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/
>
> 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/
>
>
> _______________________________________________
> 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/20170403/facfb5c3/attachment.html>

From oliver at bestwalter.de  Tue Apr  4 10:16:23 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Tue, 04 Apr 2017 14:16:23 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5CgtofwHbQOsmzsO11AxXjs5yN9r3uGqpx+eo7b_wRpWj3Cw@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>
 <CANkHFr_SmvcOyqC9biHjYQ65NGLwwyWA5G0QCArv1HKYy-J6uw@mail.gmail.com>
 <CAG5CgtofwHbQOsmzsO11AxXjs5yN9r3uGqpx+eo7b_wRpWj3Cw@mail.gmail.com>
Message-ID: <CAG5CgtraQXpaXEWNzpi8RpXMdvgpdRBfJ8vg8SyJt3La1k0zqg@mail.gmail.com>

Hi,

I don't know what I saw yesterday, but the call for proposals ist not
closed, There is time untill the 16th of April ...

Oliver

On Mon, 3 Apr 2017 at 22:57 Oliver Bestwalter <oliver at bestwalter.de> wrote:

> Hi,
>
> I wrote a mail to ask. I also noticed that the call for proposals is
> closed already, I asked anyway - maybe there is still some room for us.
>
> Cheers
> Oliver
>
> On Mon, 3 Apr 2017 at 16:51 Ionel Cristian M?rie? <contact at ionelmc.ro>
> wrote:
>
> I'm interested in this as well (pytest-cov/benchmark and general pytest
> help) but what are the guidelines? I suppose there is no space for a 10
> people "pytest-*" helpdesk. The CFP page is very scarce on information.
> Anyone already asked organizers for more info?
>
>
> Thanks,
> -- Ionel Cristian M?rie?, http://blog.ionelmc.ro
>
> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oliver at bestwalter.de>
> wrote:
>
> Hi all,
>
> I just got the green light to go to EuroPython, so I volunteer to do the
> proposal and in the worst case I will be helpdesking away on my own, but I
> sincerely hope that a few of you will be there and join me :)
>
> I would also be willing to help organizing/being part of sprints at the
> weekend.
>
> Cheers
> Oliver
>
> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dhunt at mozilla.com> wrote:
>
> 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/
>
> 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/
>
>
> _______________________________________________
> 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/20170404/193ba11a/attachment-0001.html>

From nicoddemus at gmail.com  Tue Apr  4 11:48:47 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 04 Apr 2017 15:48:47 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
Message-ID: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>

On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com> wrote:

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

Guys, anything else to add here? I would like to move the implementation
forward, either in its current form or changing it to pytest.raises(None).

Ronny, after the discussion here are you still against using
ptyest.raises(None), given that we can implement it easily by Vasily's
suggested implementation?

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

From holger at merlinux.eu  Tue Apr  4 13:19:44 2017
From: holger at merlinux.eu (holger krekel)
Date: Tue, 4 Apr 2017 19:19:44 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
Message-ID: <20170404171944.le4n4erv7obx2lxx@merlinux.eu>

On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com> wrote:
> 
> > 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.
> >
> >
> > 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.
> >
> 
> Guys, anything else to add here? I would like to move the implementation
> forward, either in its current form or changing it to pytest.raises(None).

i was and am fine with your suggestion!

IMO compared to markers or fixtures ... "pytest.raises" is relatively 
self-contained side-effect-free code so i don't think it's neccessary
to get scared about maintanability too much in this case.

cheers, holger

> 
> Ronny, after the discussion here are you still against using
> ptyest.raises(None), given that we can implement it easily by Vasily's
> suggested implementation?
> 
> Cheers,
> Bruno.

From opensource at ronnypfannschmidt.de  Wed Apr  5 11:25:01 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 5 Apr 2017 17:25:01 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170404171944.le4n4erv7obx2lxx@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>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
Message-ID: <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>

Hi all,


my own stance is still to give it a different name,

while experimenting i learned of the fun fact that None is a "valid
exception type"
for except clauses on at least python 2.7
however on python3 it is invalid and a type error,

since the usage patterns of python don't hold such a case,
i'd like to use a distinct building block for expressing it in order to
match the semantics of the language closer

- Ronny

On 04.04.2017 19:19, holger krekel wrote:
> On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
>> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com> wrote:
>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>> Guys, anything else to add here? I would like to move the implementation
>> forward, either in its current form or changing it to pytest.raises(None).
> i was and am fine with your suggestion!
>
> IMO compared to markers or fixtures ... "pytest.raises" is relatively 
> self-contained side-effect-free code so i don't think it's neccessary
> to get scared about maintanability too much in this case.
>
> cheers, holger
>
>> Ronny, after the discussion here are you still against using
>> ptyest.raises(None), given that we can implement it easily by Vasily's
>> suggested implementation?
>>
>> Cheers,
>> Bruno.



From me at the-compiler.org  Wed Apr  5 11:46:49 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 5 Apr 2017 17:46:49 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
References: <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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
Message-ID: <20170405154649.i5hlunfx3lgig3rn@hooch>

Hey,

On Wed, Apr 05, 2017 at 05:25:01PM +0200, Ronny Pfannschmidt wrote:
> while experimenting i learned of the fun fact that None is a "valid
> exception type"
> for except clauses on at least python 2.7

But it doesn't seem to be possible to raise it:

    Python 2.7.13 (default, Dec 21 2016, 07:16:46)
    >>> raise None
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType

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/20170405/45d1f9f9/attachment.sig>

From opensource at ronnypfannschmidt.de  Wed Apr  5 11:49:24 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 5 Apr 2017 17:49:24 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170405154649.i5hlunfx3lgig3rn@hooch>
References: <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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405154649.i5hlunfx3lgig3rn@hooch>
Message-ID: <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>

i meant the except clause

In [1]: try:
   ...:     1/0
   ...: except None:
   ...:     pass
   ...:
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-1-0d5ef3af74e6> in <module>()
      1 try:
----> 2     1/0
      3 except None:
      4     pass

ZeroDivisionError: integer division or modulo by zero


vs


In [1]: try:
   ...:     1/0
   ...: except None:
   ...:     pass
   ...:
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-1-0d5ef3af74e6> in <module>()
      1 try:
----> 2     1/0
      3 except None:

ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

TypeError                                 Traceback (most recent call last)
<ipython-input-1-0d5ef3af74e6> in <module>()
      1 try:
      2     1/0
----> 3 except None:
      4     pass

TypeError: catching classes that do not inherit from BaseException is
not allowed


On 05.04.2017 17:46, Florian Bruhin wrote:
> Hey,
>
> On Wed, Apr 05, 2017 at 05:25:01PM +0200, Ronny Pfannschmidt wrote:
>> while experimenting i learned of the fun fact that None is a "valid
>> exception type"
>> for except clauses on at least python 2.7
> But it doesn't seem to be possible to raise it:
>
>     Python 2.7.13 (default, Dec 21 2016, 07:16:46)
>     >>> raise None
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
>
> Florian
>



From me at the-compiler.org  Wed Apr  5 11:58:28 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 5 Apr 2017 17:58:28 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405154649.i5hlunfx3lgig3rn@hooch>
 <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>
Message-ID: <20170405155827.rit2omvce4mg3tyn@hooch>

On Wed, Apr 05, 2017 at 05:49:24PM +0200, Ronny Pfannschmidt wrote:
> i meant the except clause

I know, I was just pointing out that there's no valid use case for
pytest.raises(None) already, as None can never be raised.

In fact, pytest.raises(None) already *does* error out, even on Python 2:

  >>> pytest.raises(None)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/home/florian/tmp/.venv/lib/python2.7/site-packages/_pytest/python.py", line 1191, in raises
      raise TypeError(msg % type(expected_exception))
  TypeError: exceptions must be old-style classes or derived from BaseException, not <type 'NoneType'>

You could as well argue that "except" not doing type checking is simply
a Python 2 bug, and the code in it will never be run anyways.

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/20170405/6d69fbd9/attachment-0001.sig>

From opensource at ronnypfannschmidt.de  Wed Apr  5 12:19:15 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 5 Apr 2017 18:19:15 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170405155827.rit2omvce4mg3tyn@hooch>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405154649.i5hlunfx3lgig3rn@hooch>
 <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>
 <20170405155827.rit2omvce4mg3tyn@hooch>
Message-ID: <710eb1d7-44fb-a14f-e438-bddf4e57ca20@ronnypfannschmidt.de>

I just wanted to point out a quirk,
that i stumbled upon while checking for symmetry with the python language

-- Ronny

On 05.04.2017 17:58, Florian Bruhin wrote:
> On Wed, Apr 05, 2017 at 05:49:24PM +0200, Ronny Pfannschmidt wrote:
>> i meant the except clause
> I know, I was just pointing out that there's no valid use case for
> pytest.raises(None) already, as None can never be raised.
>
> In fact, pytest.raises(None) already *does* error out, even on Python 2:
>
>   >>> pytest.raises(None)
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in <module>
>     File "/home/florian/tmp/.venv/lib/python2.7/site-packages/_pytest/python.py", line 1191, in raises
>       raise TypeError(msg % type(expected_exception))
>   TypeError: exceptions must be old-style classes or derived from BaseException, not <type 'NoneType'>
>
> You could as well argue that "except" not doing type checking is simply
> a Python 2 bug, and the code in it will never be run anyways.
>
> Florian
>



From holger at merlinux.eu  Wed Apr  5 12:31:34 2017
From: holger at merlinux.eu (holger krekel)
Date: Wed, 5 Apr 2017 18:31:34 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
References: <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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
Message-ID: <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>

Hi Ronny,

On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
> Hi all,
> 
> 
> my own stance is still to give it a different name,
> 
> while experimenting i learned of the fun fact that None is a "valid
> exception type"
> for except clauses on at least python 2.7
> however on python3 it is invalid and a type error,
> 
> since the usage patterns of python don't hold such a case,
> i'd like to use a distinct building block for expressing it in order to
> match the semantics of the language closer

several people said however that "with pytest.raises(None): ..." reads
good to them.  And Python is also a pragmatic language not one just
built on first principles :)  Also, this construct is not going to get
used directly (as it's a no-op), just for the corner case of easing 
parametrizing expected exceptions ... 

holger
 
> - Ronny
> 
> On 04.04.2017 19:19, holger krekel wrote:
> > On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
> >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com> wrote:
> >>
> >>> 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.
> >>>
> >>>
> >>> 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.
> >>>
> >> Guys, anything else to add here? I would like to move the implementation
> >> forward, either in its current form or changing it to pytest.raises(None).
> > i was and am fine with your suggestion!
> >
> > IMO compared to markers or fixtures ... "pytest.raises" is relatively 
> > self-contained side-effect-free code so i don't think it's neccessary
> > to get scared about maintanability too much in this case.
> >
> > cheers, holger
> >
> >> Ronny, after the discussion here are you still against using
> >> ptyest.raises(None), given that we can implement it easily by Vasily's
> >> suggested implementation?
> >>
> >> Cheers,
> >> Bruno.
> 
> 

From dadygalo at gmail.com  Wed Apr  5 12:41:05 2017
From: dadygalo at gmail.com (Dmitry Dygalo)
Date: Wed, 5 Apr 2017 18:41:05 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <710eb1d7-44fb-a14f-e438-bddf4e57ca20@ronnypfannschmidt.de>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405154649.i5hlunfx3lgig3rn@hooch>
 <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>
 <20170405155827.rit2omvce4mg3tyn@hooch>
 <710eb1d7-44fb-a14f-e438-bddf4e57ca20@ronnypfannschmidt.de>
Message-ID: <CAOg7RA61ehPqLq--N7PwpuUwRG+B1Cpyp7rQrRt0OrMyO1sBEQ@mail.gmail.com>

Hello everyone!

Here is my 2 ,-.
What do you think about the following syntax?

with not pytest.raises():
    foo()

or

with not pytest.raises(BaseException):
    foo()

Is it possible to negate pytest.raises?
I'm not familiar with the implementation, but from user perspective it
seems more friendly to me.

Best regards,
Dmitry Dygalo

2017-04-05 18:19 GMT+02:00 Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de>:

> I just wanted to point out a quirk,
> that i stumbled upon while checking for symmetry with the python language
>
> -- Ronny
>
> On 05.04.2017 17:58, Florian Bruhin wrote:
> > On Wed, Apr 05, 2017 at 05:49:24PM +0200, Ronny Pfannschmidt wrote:
> >> i meant the except clause
> > I know, I was just pointing out that there's no valid use case for
> > pytest.raises(None) already, as None can never be raised.
> >
> > In fact, pytest.raises(None) already *does* error out, even on Python 2:
> >
> >   >>> pytest.raises(None)
> >   Traceback (most recent call last):
> >     File "<stdin>", line 1, in <module>
> >     File "/home/florian/tmp/.venv/lib/python2.7/site-packages/_pytest/python.py",
> line 1191, in raises
> >       raise TypeError(msg % type(expected_exception))
> >   TypeError: exceptions must be old-style classes or derived from
> BaseException, not <type 'NoneType'>
> >
> > You could as well argue that "except" not doing type checking is simply
> > a Python 2 bug, and the code in it will never be run anyways.
> >
> > Florian
> >
>
>
> _______________________________________________
> 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/20170405/a8c8165f/attachment.html>

From me at the-compiler.org  Wed Apr  5 12:51:43 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Wed, 5 Apr 2017 18:51:43 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CAOg7RA61ehPqLq--N7PwpuUwRG+B1Cpyp7rQrRt0OrMyO1sBEQ@mail.gmail.com>
References: <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405154649.i5hlunfx3lgig3rn@hooch>
 <ef0d0e81-3010-3a10-1752-3e15ed5c551e@ronnypfannschmidt.de>
 <20170405155827.rit2omvce4mg3tyn@hooch>
 <710eb1d7-44fb-a14f-e438-bddf4e57ca20@ronnypfannschmidt.de>
 <CAOg7RA61ehPqLq--N7PwpuUwRG+B1Cpyp7rQrRt0OrMyO1sBEQ@mail.gmail.com>
Message-ID: <20170405165143.endi7rnjeh5dvkup@hooch>

On Wed, Apr 05, 2017 at 06:41:05PM +0200, Dmitry Dygalo wrote:
> Hello everyone!
> 
> Here is my 2 ,-.
> What do you think about the following syntax?
> 
> with not pytest.raises():
>     foo()
> 
> or
> 
> with not pytest.raises(BaseException):
>     foo()
> 
> Is it possible to negate pytest.raises?
> I'm not familiar with the implementation, but from user perspective it
> seems more friendly to me.

That'd make the original use-case for pytest.raises(None) (make it
easier to parametrize expected exceptions) impossible again.

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/20170405/e4db20ad/attachment.sig>

From nicoddemus at gmail.com  Wed Apr  5 14:19:52 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 05 Apr 2017 18:19:52 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
References: <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>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
Message-ID: <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>

Hi Ronny, Holger, all,

On Wed, Apr 5, 2017 at 1:31 PM holger krekel <holger at merlinux.eu> wrote:

> On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
> > while experimenting i learned of the fun fact that None is a "valid
> > exception type"
> > for except clauses on at least python 2.7
> > however on python3 it is invalid and a type error,
>

I agree with Florian in that the Python behavior for try/except None should
not really be an argument in favor or against pytest.raises(None), given
that try/except None is clearly an accident of implementation which has
been fixed in Python 3.

> since the usage patterns of python don't hold such a case,
> > i'd like to use a distinct building block for expressing it in order to
> > match the semantics of the language closer
>
> several people said however that "with pytest.raises(None): ..." reads
> good to them.
>

I decided to go around the office and do a small poll, asking my colleagues
what they thought "pytest.raises(None)" meant when shown different pieces
of code.

Example 1:

    def test():
        with pytest.raises(None):
            foo()

Overall answers/thoughts:

1. "I expect pytest.raises(None) to assert that an exception of *any* type
is raised"
2. "I expect pytest.raises(None) to assert that no exception will be raised
by the block"
3. "Expect that foo() should raise None? Wait, is that possible?" (it isn't)
4. "I think pytest.raise(None) should always be an error, seems like it
could let an error slip through""

When showing this example:

    @pytest.mark.parametrize('v, exc', [
        ('', ValueError),
        (1, None),
    ])
    def test(v, exc):
        with pytest.raises(exc):
            validate_int(v)

Things then made more sense everyone, but most people still thought it
weird/surprising and another person still preferred that
pytest.raises(None) to immediately throw an explicit error about None not
being accepted (and that an exception type should be used instead).

When shown the "pytest.do_not_raise" alternative most people liked it
because it is explicit, there's no guessing about what it means and it is
easy to find in the documentation, albeit a little more verbose.

At first I was also convinced that the semantics of pytest.raises(None)
would be obvious, but it seems that's not the case (at least in my small
poll of around the office).

Given all that I'm now leaning towards going through the safe route of
being more explicit albeit more verbose.

What do others think?

Cheers,
Bruno.


>
> holger
>
> > - Ronny
> >
> > On 04.04.2017 19:19, holger krekel wrote:
> > > On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
> > >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com>
> wrote:
> > >>
> > >>> 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.
> > >>>
> > >>>
> > >>> 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.
> > >>>
> > >> Guys, anything else to add here? I would like to move the
> implementation
> > >> forward, either in its current form or changing it to
> pytest.raises(None).
> > > i was and am fine with your suggestion!
> > >
> > > IMO compared to markers or fixtures ... "pytest.raises" is relatively
> > > self-contained side-effect-free code so i don't think it's neccessary
> > > to get scared about maintanability too much in this case.
> > >
> > > cheers, holger
> > >
> > >> Ronny, after the discussion here are you still against using
> > >> ptyest.raises(None), given that we can implement it easily by Vasily's
> > >> suggested implementation?
> > >>
> > >> Cheers,
> > >> Bruno.
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170405/38ba5731/attachment-0001.html>

From holger at merlinux.eu  Wed Apr  5 14:44:21 2017
From: holger at merlinux.eu (holger krekel)
Date: Wed, 5 Apr 2017 20:44:21 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
Message-ID: <20170405184421.6qx76tpjuxw47pql@merlinux.eu>

Hi Bruno,

thanks for going through user-testing, good idea!

On Wed, Apr 05, 2017 at 18:19 +0000, Bruno Oliveira wrote:
> Hi Ronny, Holger, all,
> 
> On Wed, Apr 5, 2017 at 1:31 PM holger krekel <holger at merlinux.eu> wrote:
> 
> > On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
> > > while experimenting i learned of the fun fact that None is a "valid
> > > exception type"
> > > for except clauses on at least python 2.7
> > > however on python3 it is invalid and a type error,
> >
> 
> I agree with Florian in that the Python behavior for try/except None should
> not really be an argument in favor or against pytest.raises(None), given
> that try/except None is clearly an accident of implementation which has
> been fixed in Python 3.
> 
> > since the usage patterns of python don't hold such a case,
> > > i'd like to use a distinct building block for expressing it in order to
> > > match the semantics of the language closer
> >
> > several people said however that "with pytest.raises(None): ..." reads
> > good to them.
> >
> 
> I decided to go around the office and do a small poll, asking my colleagues
> what they thought "pytest.raises(None)" meant when shown different pieces
> of code.
> 
> Example 1:
> 
>     def test():
>         with pytest.raises(None):
>             foo()
> 
> Overall answers/thoughts:
> 
> 1. "I expect pytest.raises(None) to assert that an exception of *any* type
> is raised"
> 2. "I expect pytest.raises(None) to assert that no exception will be raised
> by the block"
> 3. "Expect that foo() should raise None? Wait, is that possible?" (it isn't)
> 4. "I think pytest.raise(None) should always be an error, seems like it
> could let an error slip through""
> 
> When showing this example:
> 
>     @pytest.mark.parametrize('v, exc', [
>         ('', ValueError),
>         (1, None),
>     ])
>     def test(v, exc):
>         with pytest.raises(exc):
>             validate_int(v)
> 
> Things then made more sense everyone, but most people still thought it
> weird/surprising and another person still preferred that
> pytest.raises(None) to immediately throw an explicit error about None not
> being accepted (and that an exception type should be used instead).

Hum, wondering what about a "pytest.NoExceptionRaised" as a special value:

     @pytest.mark.parametrize('v, exc', [
         ('', ValueError),
         (1, pytest.NoExceptionRaised),
     ])
     def test(v, exc):
         with pytest.raises(exc):
             validate_int(v)

If it makes some sense to you could you ask your colleagues 
how they feel about that?  It also means that if someone
just looks at the pytest.* namespace content there is
confusing "pytest.do_not_raise" as a general helper.

best,
holger

> 
> When shown the "pytest.do_not_raise" alternative most people liked it
> because it is explicit, there's no guessing about what it means and it is
> easy to find in the documentation, albeit a little more verbose.
> 
> At first I was also convinced that the semantics of pytest.raises(None)
> would be obvious, but it seems that's not the case (at least in my small
> poll of around the office).
> 
> Given all that I'm now leaning towards going through the safe route of
> being more explicit albeit more verbose.
> 
> What do others think?
> 
> Cheers,
> Bruno.
> 
> 
> >
> > holger
> >
> > > - Ronny
> > >
> > > On 04.04.2017 19:19, holger krekel wrote:
> > > > On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
> > > >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com>
> > wrote:
> > > >>
> > > >>> 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.
> > > >>>
> > > >>>
> > > >>> 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.
> > > >>>
> > > >> Guys, anything else to add here? I would like to move the
> > implementation
> > > >> forward, either in its current form or changing it to
> > pytest.raises(None).
> > > > i was and am fine with your suggestion!
> > > >
> > > > IMO compared to markers or fixtures ... "pytest.raises" is relatively
> > > > self-contained side-effect-free code so i don't think it's neccessary
> > > > to get scared about maintanability too much in this case.
> > > >
> > > > cheers, holger
> > > >
> > > >> Ronny, after the discussion here are you still against using
> > > >> ptyest.raises(None), given that we can implement it easily by Vasily's
> > > >> suggested implementation?
> > > >>
> > > >> Cheers,
> > > >> Bruno.
> > >
> > >
> >

From opensource at ronnypfannschmidt.de  Wed Apr  5 16:02:30 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Wed, 05 Apr 2017 22:02:30 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
Message-ID: <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>

Please lets just use the New Name already ...

Im sick of magical knobs, they cause so much pain and suffering down the line

Am 5. April 2017 20:44:21 MESZ schrieb holger krekel <holger at merlinux.eu>:
>Hi Bruno,
>
>thanks for going through user-testing, good idea!
>
>On Wed, Apr 05, 2017 at 18:19 +0000, Bruno Oliveira wrote:
>> Hi Ronny, Holger, all,
>> 
>> On Wed, Apr 5, 2017 at 1:31 PM holger krekel <holger at merlinux.eu>
>wrote:
>> 
>> > On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
>> > > while experimenting i learned of the fun fact that None is a
>"valid
>> > > exception type"
>> > > for except clauses on at least python 2.7
>> > > however on python3 it is invalid and a type error,
>> >
>> 
>> I agree with Florian in that the Python behavior for try/except None
>should
>> not really be an argument in favor or against pytest.raises(None),
>given
>> that try/except None is clearly an accident of implementation which
>has
>> been fixed in Python 3.
>> 
>> > since the usage patterns of python don't hold such a case,
>> > > i'd like to use a distinct building block for expressing it in
>order to
>> > > match the semantics of the language closer
>> >
>> > several people said however that "with pytest.raises(None): ..."
>reads
>> > good to them.
>> >
>> 
>> I decided to go around the office and do a small poll, asking my
>colleagues
>> what they thought "pytest.raises(None)" meant when shown different
>pieces
>> of code.
>> 
>> Example 1:
>> 
>>     def test():
>>         with pytest.raises(None):
>>             foo()
>> 
>> Overall answers/thoughts:
>> 
>> 1. "I expect pytest.raises(None) to assert that an exception of *any*
>type
>> is raised"
>> 2. "I expect pytest.raises(None) to assert that no exception will be
>raised
>> by the block"
>> 3. "Expect that foo() should raise None? Wait, is that possible?" (it
>isn't)
>> 4. "I think pytest.raise(None) should always be an error, seems like
>it
>> could let an error slip through""
>> 
>> When showing this example:
>> 
>>     @pytest.mark.parametrize('v, exc', [
>>         ('', ValueError),
>>         (1, None),
>>     ])
>>     def test(v, exc):
>>         with pytest.raises(exc):
>>             validate_int(v)
>> 
>> Things then made more sense everyone, but most people still thought
>it
>> weird/surprising and another person still preferred that
>> pytest.raises(None) to immediately throw an explicit error about None
>not
>> being accepted (and that an exception type should be used instead).
>
>Hum, wondering what about a "pytest.NoExceptionRaised" as a special
>value:
>
>     @pytest.mark.parametrize('v, exc', [
>         ('', ValueError),
>         (1, pytest.NoExceptionRaised),
>     ])
>     def test(v, exc):
>         with pytest.raises(exc):
>             validate_int(v)
>
>If it makes some sense to you could you ask your colleagues 
>how they feel about that?  It also means that if someone
>just looks at the pytest.* namespace content there is
>confusing "pytest.do_not_raise" as a general helper.
>
>best,
>holger
>
>> 
>> When shown the "pytest.do_not_raise" alternative most people liked it
>> because it is explicit, there's no guessing about what it means and
>it is
>> easy to find in the documentation, albeit a little more verbose.
>> 
>> At first I was also convinced that the semantics of
>pytest.raises(None)
>> would be obvious, but it seems that's not the case (at least in my
>small
>> poll of around the office).
>> 
>> Given all that I'm now leaning towards going through the safe route
>of
>> being more explicit albeit more verbose.
>> 
>> What do others think?
>> 
>> Cheers,
>> Bruno.
>> 
>> 
>> >
>> > holger
>> >
>> > > - Ronny
>> > >
>> > > On 04.04.2017 19:19, holger krekel wrote:
>> > > > On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
>> > > >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira
><nicoddemus at gmail.com>
>> > wrote:
>> > > >>
>> > > >>> 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.
>> > > >>>
>> > > >>>
>> > > >>> 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.
>> > > >>>
>> > > >> Guys, anything else to add here? I would like to move the
>> > implementation
>> > > >> forward, either in its current form or changing it to
>> > pytest.raises(None).
>> > > > i was and am fine with your suggestion!
>> > > >
>> > > > IMO compared to markers or fixtures ... "pytest.raises" is
>relatively
>> > > > self-contained side-effect-free code so i don't think it's
>neccessary
>> > > > to get scared about maintanability too much in this case.
>> > > >
>> > > > cheers, holger
>> > > >
>> > > >> Ronny, after the discussion here are you still against using
>> > > >> ptyest.raises(None), given that we can implement it easily by
>Vasily's
>> > > >> suggested implementation?
>> > > >>
>> > > >> Cheers,
>> > > >> Bruno.
>> > >
>> > >
>> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170405/19baae3b/attachment-0001.html>

From contact at ionelmc.ro  Wed Apr  5 16:27:02 2017
From: contact at ionelmc.ro (=?UTF-8?Q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Wed, 5 Apr 2017 23:27:02 +0300
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
Message-ID: <CANkHFr-VHBQvAcVOW8j4PFWxQ3zJPkkcV5GA2Xm=ucYXtki4KA@mail.gmail.com>

At first I didn't like Holger's pytest.raises(None) either but then I
realized I just wanted to play the naming game. It's so fun. BTW,
pytest.no_raise is way better, use my name :)

How would parametrization work with a new context manager?


Thanks,
-- Ionel Cristian M?rie?, http://blog.ionelmc.ro

On Wed, Apr 5, 2017 at 11:02 PM, Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

> Please lets just use the New Name already ...
>
> Im sick of magical knobs, they cause so much pain and suffering down the
> line
>
>
> Am 5. April 2017 20:44:21 MESZ schrieb holger krekel <holger at merlinux.eu>:
>>
>> Hi Bruno,
>>
>> thanks for going through user-testing, good idea!
>>
>> On Wed, Apr 05, 2017 at 18:19 +0000, Bruno Oliveira wrote:
>>
>>>  Hi Ronny, Holger, all,
>>>
>>>  On Wed, Apr 5, 2017 at 1:31 PM holger krekel <holger at merlinux.eu> wrote:
>>>
>>>  On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
>>>>
>>>>>  while experimenting i learned of the fun fact that None is a "valid
>>>>>  exception type"
>>>>>  for except clauses on at least python 2.7
>>>>>  however on python3 it is invalid and a type error,
>>>>>
>>>>
>>>>
>>>  I agree with Florian in that the Python behavior for try/except None should
>>>  not really be an argument in favor or against pytest.raises(None), given
>>>  that try/except None is clearly an accident of implementation which has
>>>  been fixed in Python 3.
>>>
>>>  since the usage patterns of python don't hold such a case,
>>>>
>>>>>  i'd like to use a distinct building block for expressing it in order to
>>>>>  match the semantics of the language closer
>>>>>
>>>>
>>>>  several people said however that "with pytest.raises(None): ..." reads
>>>>  good to them.
>>>
>>>
>>>
>>>  I decided to go around the office and do a small poll, asking my colleagues
>>>  what they thought "pytest.raises(None)" meant when shown different pieces
>>>  of code.
>>>
>>>  Example 1:
>>>
>>>      def test():
>>>          with pytest.raises(None):
>>>              foo()
>>>
>>>  Overall answers/thoughts:
>>>
>>>  1. "I expect pytest.raises(None) to assert that an exception of *any* type
>>>  is raised"
>>>  2. "I expect pytest.raises(None) to assert that no exception will be raised
>>>  by the block"
>>>  3. "Expect that foo() should raise None? Wait, is that possible?" (it isn't)
>>>  4. "I think pytest.raise(None) should always be an error, seems like it
>>>  could let an error slip through""
>>>
>>>  When showing this example:
>>>
>>>      @pytest.mark.parametrize('v, exc', [
>>>          ('', ValueError),
>>>          (1, None),
>>>      ])
>>>      def test(v, exc):
>>>          with pytest.raises(exc):
>>>              validate_int(v)
>>>
>>>  Things then made more sense everyone, but most people still thought it
>>>  weird/surprising and another person still preferred that
>>>  pytest.raises(None) to immediately throw an explicit error about None not
>>>  being accepted (and that an exception type should be used instead).
>>>
>>
>> Hum, wondering what about a "pytest.NoExceptionRaised" as a special value:
>>
>>      @pytest.mark.parametrize('v, exc', [
>>          ('', ValueError),
>>          (1, pytest.NoExceptionRaised),
>>      ])
>>      def test(v, exc):
>>          with pytest.raises(exc):
>>              validate_int(v)
>>
>> If it makes some sense to you could you ask your colleagues
>> how they feel about that?  It also means that if someone
>> just looks at the pytest.* namespace content there is
>> confusing "pytest.do_not_raise" as a general helper.
>>
>> best,
>> holger
>>
>>
>>>  When shown the "pytest.do_not_raise" alternative most people liked it
>>>  because it is explicit, there's no guessing about what it means and it is
>>>  easy to find in the documentation, albeit a little more verbose.
>>>
>>>  At first I was also convinced that the semantics of pytest.raises(None)
>>>  would be obvious, but it seems that's not the case (at least in my small
>>>  poll of around the office).
>>>
>>>  Given all that I'm now leaning towards going through the safe route of
>>>  being more explicit albeit more verbose.
>>>
>>>  What do others think?
>>>
>>>  Cheers,
>>>  Bruno.
>>>
>>>
>>>
>>>>  holger
>>>>
>>>>  - Ronny
>>>>>
>>>>>  On 04.04.2017 19:19, holger krekel wrote:
>>>>>
>>>>>>  On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
>>>>>>
>>>>>>>  On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira <nicoddemus at gmail.com>
>>>>>>>
>>>>>>  wrote:
>>>>
>>>>>
>>>>>>>  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.
>>>>>>>>
>>>>>>>>
>>>>>>>>  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.
>>>>>>>
>>>>>>>
>>>>>>>  Guys, anything else to add here? I would like to move the
>>>>>>>
>>>>>>  implementation
>>>>
>>>>>  forward, either in its current form or changing it to
>>>>>>>
>>>>>>  pytest.raises(None).
>>>>
>>>>>  i was and am fine with your suggestion!
>>>>>>
>>>>>>  IMO compared to markers or fixtures ... "pytest.raises" is relatively
>>>>>>  self-contained side-effect-free code so i don't think it's neccessary
>>>>>>  to get scared about maintanability too much in this case.
>>>>>>
>>>>>>  cheers, holger
>>>>>>
>>>>>>  Ronny, after the discussion here are you still against using
>>>>>>>  ptyest.raises(None), given that we can implement it easily by Vasily's
>>>>>>>  suggested implementation?
>>>>>>>
>>>>>>>  Cheers,
>>>>>>>  Bruno.
>>>>>>>
>>>>>>
>>>>
>>>>
> _______________________________________________
> 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/20170405/b5140e32/attachment-0001.html>

From flub at devork.be  Wed Apr  5 16:48:35 2017
From: flub at devork.be (Floris Bruynooghe)
Date: Wed, 05 Apr 2017 22:48:35 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
Message-ID: <87vaqi8tss.fsf@powell.devork.be>

Hi all,

After this whole thread I'm now starting to lean towards being -1 on the
entire concept of the feature.  It tries to optimise the Don't Repeat
Yourself thing for one rather specific corner case where the cognitive
load on pytest itself seems to become higher then what is saved by doing
things with the existing API.  Even some simple normal python code of
the test allows DRY right now (wrap code in a closure/function + if
statement).

Anyway, just my opinion.

Regards,
Floris

Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> writes:

> Please lets just use the New Name already ...
>
> Im sick of magical knobs, they cause so much pain and suffering down the line
>
> Am 5. April 2017 20:44:21 MESZ schrieb holger krekel <holger at merlinux.eu>:
>>Hi Bruno,
>>
>>thanks for going through user-testing, good idea!
>>
>>On Wed, Apr 05, 2017 at 18:19 +0000, Bruno Oliveira wrote:
>>> Hi Ronny, Holger, all,
>>> 
>>> On Wed, Apr 5, 2017 at 1:31 PM holger krekel <holger at merlinux.eu>
>>wrote:
>>> 
>>> > On Wed, Apr 05, 2017 at 17:25 +0200, Ronny Pfannschmidt wrote:
>>> > > while experimenting i learned of the fun fact that None is a
>>"valid
>>> > > exception type"
>>> > > for except clauses on at least python 2.7
>>> > > however on python3 it is invalid and a type error,
>>> >
>>> 
>>> I agree with Florian in that the Python behavior for try/except None
>>should
>>> not really be an argument in favor or against pytest.raises(None),
>>given
>>> that try/except None is clearly an accident of implementation which
>>has
>>> been fixed in Python 3.
>>> 
>>> > since the usage patterns of python don't hold such a case,
>>> > > i'd like to use a distinct building block for expressing it in
>>order to
>>> > > match the semantics of the language closer
>>> >
>>> > several people said however that "with pytest.raises(None): ..."
>>reads
>>> > good to them.
>>> >
>>> 
>>> I decided to go around the office and do a small poll, asking my
>>colleagues
>>> what they thought "pytest.raises(None)" meant when shown different
>>pieces
>>> of code.
>>> 
>>> Example 1:
>>> 
>>>     def test():
>>>         with pytest.raises(None):
>>>             foo()
>>> 
>>> Overall answers/thoughts:
>>> 
>>> 1. "I expect pytest.raises(None) to assert that an exception of *any*
>>type
>>> is raised"
>>> 2. "I expect pytest.raises(None) to assert that no exception will be
>>raised
>>> by the block"
>>> 3. "Expect that foo() should raise None? Wait, is that possible?" (it
>>isn't)
>>> 4. "I think pytest.raise(None) should always be an error, seems like
>>it
>>> could let an error slip through""
>>> 
>>> When showing this example:
>>> 
>>>     @pytest.mark.parametrize('v, exc', [
>>>         ('', ValueError),
>>>         (1, None),
>>>     ])
>>>     def test(v, exc):
>>>         with pytest.raises(exc):
>>>             validate_int(v)
>>> 
>>> Things then made more sense everyone, but most people still thought
>>it
>>> weird/surprising and another person still preferred that
>>> pytest.raises(None) to immediately throw an explicit error about None
>>not
>>> being accepted (and that an exception type should be used instead).
>>
>>Hum, wondering what about a "pytest.NoExceptionRaised" as a special
>>value:
>>
>>     @pytest.mark.parametrize('v, exc', [
>>         ('', ValueError),
>>         (1, pytest.NoExceptionRaised),
>>     ])
>>     def test(v, exc):
>>         with pytest.raises(exc):
>>             validate_int(v)
>>
>>If it makes some sense to you could you ask your colleagues 
>>how they feel about that?  It also means that if someone
>>just looks at the pytest.* namespace content there is
>>confusing "pytest.do_not_raise" as a general helper.
>>
>>best,
>>holger
>>
>>> 
>>> When shown the "pytest.do_not_raise" alternative most people liked it
>>> because it is explicit, there's no guessing about what it means and
>>it is
>>> easy to find in the documentation, albeit a little more verbose.
>>> 
>>> At first I was also convinced that the semantics of
>>pytest.raises(None)
>>> would be obvious, but it seems that's not the case (at least in my
>>small
>>> poll of around the office).
>>> 
>>> Given all that I'm now leaning towards going through the safe route
>>of
>>> being more explicit albeit more verbose.
>>> 
>>> What do others think?
>>> 
>>> Cheers,
>>> Bruno.
>>> 
>>> 
>>> >
>>> > holger
>>> >
>>> > > - Ronny
>>> > >
>>> > > On 04.04.2017 19:19, holger krekel wrote:
>>> > > > On Tue, Apr 04, 2017 at 15:48 +0000, Bruno Oliveira wrote:
>>> > > >> On Fri, Mar 31, 2017 at 8:24 AM Bruno Oliveira
>><nicoddemus at gmail.com>
>>> > wrote:
>>> > > >>
>>> > > >>> 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.
>>> > > >>>
>>> > > >>>
>>> > > >>> 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.
>>> > > >>>
>>> > > >> Guys, anything else to add here? I would like to move the
>>> > implementation
>>> > > >> forward, either in its current form or changing it to
>>> > pytest.raises(None).
>>> > > > i was and am fine with your suggestion!
>>> > > >
>>> > > > IMO compared to markers or fixtures ... "pytest.raises" is
>>relatively
>>> > > > self-contained side-effect-free code so i don't think it's
>>neccessary
>>> > > > to get scared about maintanability too much in this case.
>>> > > >
>>> > > > cheers, holger
>>> > > >
>>> > > >> Ronny, after the discussion here are you still against using
>>> > > >> ptyest.raises(None), given that we can implement it easily by
>>Vasily's
>>> > > >> suggested implementation?
>>> > > >>
>>> > > >> Cheers,
>>> > > >> Bruno.
>>> > >
>>> > >
>>> >
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev

From oliver at bestwalter.de  Wed Apr  5 18:00:06 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Wed, 05 Apr 2017 22:00:06 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <87vaqi8tss.fsf@powell.devork.be>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
Message-ID: <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>

Hi,

I am reading this thread with growing fascination, because I have the
feeling I am missing something, so can I summarize?

If I had a test, where I don't care about output and only about whther
exceptions are thrown or not I would normally write this:

@pytest.mark.parametrize(
    "req, exc", (
    ('foo', None),
    ('bar', None),
    ('BLARF', ValueError),
    ('PLONK', IndexError),
))
def test_something(self, arg, exc):
    if exc:
        with pytest.raises(exc):
            something(arg)
    else:
        something(arg)

So the new feature would save me two lines of code:

@pytest.mark.parametrize(
    "req, exc", (
    ('foo', None),
    ('bar', None),
    ('BLARF', ValueError),
    ('PLONK', IndexError),
))
def test_something(arg, exc):
    with pytest.raises(exc):
        something(arg)

... and this would be a bit harder to understand, because as Bruno found
out already, there are quite different expectations about what is supposed
to happen if I write pytest.raises(None).

Am I missing something?

I usually don't write tests like that anyway but rather tests where I
expect either a concrete value of a certain type or I expect an Exception
to be raised. E.g.

@pytest.mark.parametrize(
    "req, exp", (
    ('foo', True),
    ('bar', False),
    ('BLARF', ValueError),
    ('PLONK', IndexError),
))
def test_something(arg, exp):
    if not isinstance(exp, bool):
        with pytest.raises(exp):
            something(arg)
    else:
        assert something(arg) == exp

And there this feature would not help me anyway or one would have to make a
new bastard context manager like

@pytest.mark.parametrize(
    "req, exp", (
    ('foo', True),
    ('bar', False),
    ('BLARF', ValueError),
    ('PLONK', IndexError),
))
def test_something(arg, exp):
    with pytest.raises_or_returns_or_yields_or_whatever(exp):
        something(arg)

**shudder**

So I am not sure if this is worth implementing unless I am just not able to
grasp the real benfits.

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

From nicoddemus at gmail.com  Wed Apr  5 20:25:16 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 06 Apr 2017 00:25:16 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
References: <20170330213636.nw45ywbg42xi2ijq@merlinux.eu>
 <ce37cac2-2a93-8263-4345-ef0342b66abd@ronnypfannschmidt.de>
 <20170331083059.b7mekieurttsqj2t@merlinux.eu>
 <CAK7X-XB_ENTyC2X0Af=rRac1VN82VqJTyZpURf_p+86u3i3kzA@mail.gmail.com>
 <CA+RQFffoqC35SebJfgDu=iuWG2Fx6Jg=-oii-+mFjKyFHr_T7g@mail.gmail.com>
 <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
Message-ID: <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>

Hi Walter!

On Wed, Apr 5, 2017 at 7:00 PM Oliver Bestwalter <oliver at bestwalter.de>
wrote:

> ... and this would be a bit harder to understand, because as Bruno found
> out already, there are quite different expectations about what is supposed
> to happen if I write pytest.raises(None).
>
> Am I missing something?
>

Not really, that's the gist of it. :)

Myself I've experienced the need for this in pytest-qt's tests, which has
lots of tests for a context manager which can raise an exception in various
scenarios, but other than that I don't recall ever needing it actually.

After all the discussion I'm also inclining to just drop the feature since
there doesn't seem to be consensus for a good API.

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

From holger at merlinux.eu  Thu Apr  6 02:30:31 2017
From: holger at merlinux.eu (holger krekel)
Date: Thu, 6 Apr 2017 08:30:31 +0200
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
References: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
 <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
Message-ID: <20170406063031.ffxs5gigshdrwdag@merlinux.eu>

Hi Bruno,

On Thu, Apr 06, 2017 at 00:25 +0000, Bruno Oliveira wrote:
> Hi Walter!

heh, names are hard, let's go shopping? :)
 
> On Wed, Apr 5, 2017 at 7:00 PM Oliver Bestwalter <oliver at bestwalter.de>
> wrote:
> 
> > ... and this would be a bit harder to understand, because as Bruno found
> > out already, there are quite different expectations about what is supposed
> > to happen if I write pytest.raises(None).
> >
> > Am I missing something?
> >
> 
> Not really, that's the gist of it. :)

In case i wasn't clear -- i am fine to drop pytest.raises(None) in light
of your user tests.
 
> Myself I've experienced the need for this in pytest-qt's tests, which has
> lots of tests for a context manager which can raise an exception in various
> scenarios, but other than that I don't recall ever needing it actually.
> 
> After all the discussion I'm also inclining to just drop the feature since
> there doesn't seem to be consensus for a good API.

I am fine to have user-tests guide the decision ...  so now for me it's
only between offering a context manager or offering a special
"NoExceptionRaised" object which you can give to pytest.raises(...).  
so we are almost there and for me, the user-testing can decide that so it's
not much discussion left to do at least from my side ... 

So for me there is already one useful outcome of our discussion here:

- UI facing API is good to test against users/colleagues perceptions
  as it gives real-life empirical clues instead of gut feelings
  of implementors (including mine)

- maintenance costs or a raise in internal complexities
  also play into the evaluation of how/if to do something

cheers,
holger


 
> Cheers,
> Bruno.

From psavage at redhat.com  Thu Apr  6 06:26:04 2017
From: psavage at redhat.com (Pete Savage)
Date: Thu, 6 Apr 2017 11:26:04 +0100
Subject: [pytest-dev] Need access to parameter IDs during
 pytest_collection_modifyitems
Message-ID: <2e4b2544-1a4c-88be-de4b-8fab7dda8874@redhat.com>

Hi all,

Forgive this seemingly useless requirement. We have the requirement to collect the parameters which
are used in a parametrized test to pass to a test case results system.

Currently I am pulling out the parameters using the item.callspec.params except there are issues
where the parameter is an object and has a differing repr than that id that was used in the idlist.
To keep things consistent, I would like to tell the test case result system the ID of the parameter
that was used for the test, if one is available and if not to fall back to the object.

This is basically being used to describe a whole set of tests during a --collect-only that _should_
run based on parametrization and passing those into the results system, so that they can be
populated across multiple smaller runs with the actual results.

The problem is this information is not available on the item object. Here is what IS available:

Consider the following contrived test

---
import pytest


@pytest.mark.parametrize('num', [1, 2, 3], ids=["one", "two", "three"])
@pytest.mark.parametrize('letter', ['a', 'b', 'c'], ids=["A", "B", "C"])
def test_something(num, letter):
    print num, letter
---

During the modifyitems hook I can access the following:

* item.callspec.params
  * gives me a dict {'num': 1, 'letter': 'a'}) - but this doesn't give me IDs
* item.callspec.indices
  * gives me a dict {'num': 0, 'letter': 0}) - this is great that if I had the ID list for
    each param I could look up the right one
* item.callspec._idlist
  * gives me a list ['A', 'one']) - this is great except I don't know which ID is for which
    parameter
* item._getobj().parametrize
  * gives me <MarkInfo 'parametrize' args=('letter', ['a', 'b', 'c'], 'num', [1, 2, 3])
    kwargs={'ids': ['one', 'two', 'three']}> - which unfortunately is missing the kwargs
    entry for the IDs for the second parameter)

Seems like a problem with the MarkInfo item?

Is there any way I can construct this information?

Thanks,

-- 
Pete Savage
Principal Quality Engineer
Red Hat UK
psavage at redhat.com     IM: psav
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps

From nicoddemus at gmail.com  Thu Apr  6 15:51:29 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 06 Apr 2017 19:51:29 +0000
Subject: [pytest-dev] Need access to parameter IDs during
 pytest_collection_modifyitems
In-Reply-To: <2e4b2544-1a4c-88be-de4b-8fab7dda8874@redhat.com>
References: <2e4b2544-1a4c-88be-de4b-8fab7dda8874@redhat.com>
Message-ID: <CA+RQFffQOjGoshdY=ekw8NjR808B1gsxaTJojhNzqHaOnzoVkg@mail.gmail.com>

Hi Pete,

On Thu, Apr 6, 2017 at 7:26 AM Pete Savage <psavage at redhat.com> wrote:

> Is there any way I can construct this information?
>

I'm not sure, by the time modifyitems hook is called all items have already
been constructed, and the original ids seem to have been lost. See here:

https://github.com/pytest-dev/pytest/blob/master/_pytest/python.py#L851

This happens before the hook call, btw. An idea might have to hook earlier
than that, perhaps as a hookwrapper for one of the hooks which generate the
collected objects, and inspect the actual MarkInfo object. Sorry I can't
try to provide an example right now as I'm short on time.

Others might be able to provide some other ideas.

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

From nicoddemus at gmail.com  Fri Apr  7 15:31:11 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Fri, 07 Apr 2017 19:31:11 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <20170406063031.ffxs5gigshdrwdag@merlinux.eu>
References: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
 <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
 <20170406063031.ffxs5gigshdrwdag@merlinux.eu>
Message-ID: <CA+RQFfd5W1UGk-0-V-uA1G68ihi0y_RVeMyTLY4uh-OGA5Q8YA@mail.gmail.com>

Hi Holger, everyone,

On Thu, Apr 6, 2017 at 3:30 AM holger krekel <holger at merlinux.eu> wrote:

>
> I am fine to have user-tests guide the decision ...  so now for me it's
> only between offering a context manager or offering a special
> "NoExceptionRaised" object which you can give to pytest.raises(...).
> so we are almost there and for me, the user-testing can decide that so it's
> not much discussion left to do at least from my side ...
>

Sorry for the delay!

Made a quick poll again, showing all the possibilities we have been
considering here (including giving up and not adding anything), and
pytest.do_not_raise won by 100% of the opinions... but in fact only 5
people actually took interest and replied, so I don't think this pool has
much value TBH. :P

So for me there is already one useful outcome of our discussion here:
>
> - UI facing API is good to test against users/colleagues perceptions
>   as it gives real-life empirical clues instead of gut feelings
>   of implementors (including mine)
>
> - maintenance costs or a raise in internal complexities
>   also play into the evaluation of how/if to do something
>

Agreed!

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

From opensource at ronnypfannschmidt.de  Thu Apr 13 12:25:22 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Thu, 13 Apr 2017 18:25:22 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
Message-ID: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>

Hi everyone,

since quite a while now we keep a lot of code away from users by leaving
it in the features branch,
more recent detail https://github.com/pytest-dev/pytest/issues/2365
where even i didn't realize we had a fix since half a year.

>From my point of view it has been demonstrated that we don't deliver
well from the features branch,
and it has been a massive pain to keep merged with master over and over.

As such i would like to stop using a features branch at all and return
to having only master.

-- Ronny


From me at the-compiler.org  Thu Apr 13 12:26:55 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Thu, 13 Apr 2017 18:26:55 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
Message-ID: <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>

Hi,

On Thu, Apr 13, 2017 at 06:25:22PM +0200, Ronny Pfannschmidt wrote:
> since quite a while now we keep a lot of code away from users by leaving
> it in the features branch,
> more recent detail https://github.com/pytest-dev/pytest/issues/2365
> where even i didn't realize we had a fix since half a year.

We probably just should do more feature releases then.

> and it has been a massive pain to keep merged with master over and over.

Didn't seem like a "massive pain" to me so far.

> As such i would like to stop using a features branch at all and return
> to having only master.

And not have any bugfix releases?

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/20170413/3b245a7a/attachment.sig>

From nicoddemus at gmail.com  Thu Apr 13 13:51:34 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Thu, 13 Apr 2017 17:51:34 +0000
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
Message-ID: <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>

On Thu, Apr 13, 2017 at 1:35 PM Florian Bruhin <me at the-compiler.org> wrote:

> Hi,
>
> On Thu, Apr 13, 2017 at 06:25:22PM +0200, Ronny Pfannschmidt wrote:
> > since quite a while now we keep a lot of code away from users by leaving
> > it in the features branch,
> > more recent detail https://github.com/pytest-dev/pytest/issues/2365
> > where even i didn't realize we had a fix since half a year.
>
> We probably just should do more feature releases then.
>

I agree we should have releases more often.

Previously (at least from my POV) feature releases had one or more "themes"
or major new features attached to it.

3.0 was about removing backward incompatibilities and adding a lot of new
niceties (approx, doctest_namespace, etc).

3.1 in my head was about integrating pytest warnings and marks refactoring.

Since we maintainers can only work on pytest on our spare time, a downside
of this approach is that some feature might take a long time to land, which
can hold back other small changes from reaching our users soon, like the
issue Ronny mentioned.

What if we instead of considering features, we released a new minor version
periodically, for say every month or two? We could adopt the same for bug
fix releases, like each two weeks.

One problem with this is that now our process requires some manual work
which takes some to make a release.

> and it has been a massive pain to keep merged with master over and over.
>
> Didn't seem like a "massive pain" to me so far.
>

IMHO I agree, I rarely see conflicts except for the CHANGELOG (which we
plan to solve soon with the towncrier package).

> As such i would like to stop using a features branch at all and return
> > to having only master.
>
> And not have any bugfix releases?
>

Having only a master branch, I think Ronny was proposing to then figuring
out if it was a bug fix release or a minor release based on the CHANGELOG.

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

From me at the-compiler.org  Fri Apr 14 08:17:56 2017
From: me at the-compiler.org (Florian Bruhin)
Date: Fri, 14 Apr 2017 14:17:56 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
Message-ID: <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>

On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
> What if we instead of considering features, we released a new minor version
> periodically, for say every month or two? We could adopt the same for bug
> fix releases, like each two weeks.

FWIW what GitLab[1] does is a monthly feature release, and patch
releases whenever needed. I don't think it's a good idea to have a fixed
release cycle for patches, but it sounds like it could work quite well
for feature releases indeed.

[1] https://about.gitlab.com/

> One problem with this is that now our process requires some manual work
> which takes some to make a release.

I still think it should be manageable, at least if it's documented how
to do a release and how to use devpi-cloud-tester for everyone. Haven't
checked in a while.

> > As such i would like to stop using a features branch at all and return
> > > to having only master.
> >
> > And not have any bugfix releases?
> >
> 
> Having only a master branch, I think Ronny was proposing to then figuring
> out if it was a bug fix release or a minor release based on the CHANGELOG.

That means you either need to arbitarily hold back contributions, or you
lose the ability to do bugfix releases and need to do a feature release
(probably with new subtle bugs, looking at our track record) every time.

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/20170414/f89dbf7a/attachment.sig>

From opensource at ronnypfannschmidt.de  Mon Apr 17 14:49:39 2017
From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt)
Date: Mon, 17 Apr 2017 20:49:39 +0200
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
Message-ID: <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>



On 14.04.2017 14:17, Florian Bruhin wrote:
> On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
>> What if we instead of considering features, we released a new minor version
>> periodically, for say every month or two? We could adopt the same for bug
>> fix releases, like each two weeks.
> FWIW what GitLab[1] does is a monthly feature release, and patch
> releases whenever needed. I don't think it's a good idea to have a fixed
> release cycle for patches, but it sounds like it could work quite well
> for feature releases indeed.
>
> [1] https://about.gitlab.com/
from my pov it should be valid to release once a week and simply up
numbers depending on whether patches or features are in
>> One problem with this is that now our process requires some manual work
>> which takes some to make a release.
> I still think it should be manageable, at least if it's documented how
> to do a release and how to use devpi-cloud-tester for everyone. Haven't
> checked in a while.
https://github.com/pytest-dev/pytest/blob/master/HOWTORELEASE.rst is
about 13 steps,
most manual mundane and error-prone - it should be at most 1-2 steps

>
>>> As such i would like to stop using a features branch at all and return
>>>> to having only master.
>>> And not have any bugfix releases?
>>>
>> Having only a master branch, I think Ronny was proposing to then figuring
>> out if it was a bug fix release or a minor release based on the CHANGELOG.
> That means you either need to arbitarily hold back contributions, or you
> lose the ability to do bugfix releases and need to do a feature release
> (probably with new subtle bugs, looking at our track record) every time.
if we make releasing inexpensive and reliable even a botched release an
have a quick fix afterwards,
i don't see a problem there, as long as we have processes in place that
let stuff like "softening of xfail" to happen we'll have botched feature
releases anyway,
and IMHO that shouldn't stand in the way of removing unnecessary
maintenance pain.

what i want to remove is time eating and painful processes at releasing,

-- Ronny
>
> Florian
>



From nicoddemus at gmail.com  Wed Apr 19 07:42:29 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 19 Apr 2017 11:42:29 +0000
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
 <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
Message-ID: <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>

On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

>
> On 14.04.2017 14:17, Florian Bruhin wrote:
> > On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
> >> What if we instead of considering features, we released a new minor
> version
> >> periodically, for say every month or two? We could adopt the same for
> bug
> >> fix releases, like each two weeks.
> > FWIW what GitLab[1] does is a monthly feature release, and patch
> > releases whenever needed. I don't think it's a good idea to have a fixed
> > release cycle for patches, but it sounds like it could work quite well
> > for feature releases indeed.
>

I'm curious, why do you think it is not a good idea to have a fixed or
semi-fixed release cycle for patches?


> https://github.com/pytest-dev/pytest/blob/master/HOWTORELEASE.rst is
> about 13 steps,
> most manual mundane and error-prone - it should be at most 1-2 steps
>

I agree, we should strive to improve that. The steps are not hard, but
still they are error prone (remember me sending the email for the pytest
3.0 release and writing "and this release contains a lot of bugs and new
features" instead of "... lot of bug **fixes** and..."). Heh.


> >> Having only a master branch, I think Ronny was proposing to then
> figuring
> >> out if it was a bug fix release or a minor release based on the
> CHANGELOG.
> > That means you either need to arbitarily hold back contributions, or you
> > lose the ability to do bugfix releases and need to do a feature release
> > (probably with new subtle bugs, looking at our track record) every time.
> if we make releasing inexpensive and reliable even a botched release an
> have a quick fix afterwards,
> i don't see a problem there, as long as we have processes in place that
> let stuff like "softening of xfail" to happen we'll have botched feature
> releases anyway,
> and IMHO that shouldn't stand in the way of removing unnecessary
> maintenance pain.
>
> what i want to remove is time eating and painful processes at releasing,
>

I appreciate Ronny bringing up this topic, a 3.1 release is long overdue.

We are discussing two things which have some interconnection:

1. Should we improve our release process, so that releasing a new version
is a 1 or 2 step process?
2. Keep or not a separate branch for ``features``.

I think we can all agree that 1) would be great and we want that.

Regarding 2), there's a few sub-points:
2.1) Periodically have to merge master into ``features``; Ronny believes
this is a pain, IMHO it's not a big deal;
2.2) How often should we release bug fixes and feature releases? This is
impacted directly by question 1: the easier to make a new release, more
often we will do it (just pushing a tag every Thursday for a new bug fix
release for example).

I definitely agree that we should have more frequent feature releases than
what we have now; I was under the mentality that we wanted all feature
releases with 2 or 3 major themes and new additions, but given that we
can't really guarantee time to implement these new features it might make
more sense to just make new feature releases with just minor improvements
and changes.

Having said that, I think it is still worthwhile to keep the features
branch so we can issue bug-fixes quickly and periodically. But for that to
work, we need to improve the release process so that it takes one or two
steps at most; we have excellent CI at our service to help us accomplish
that.

I really would like for us to reach a consensus here. :)

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

From oliver at bestwalter.de  Wed Apr 19 08:16:28 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Wed, 19 Apr 2017 12:16:28 +0000
Subject: [pytest-dev] [proposal] abolishing the features branch
In-Reply-To: <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
References: <3a6c9067-4412-719e-0268-f40b709ea07a@ronnypfannschmidt.de>
 <20170413162653.nrct2oedvrwzyw5x@hooch.localdomain>
 <CA+RQFfdyZmQo8wrbgwWmn_rwzwsK3Rfe_7dj+K2uekOAXqChVg@mail.gmail.com>
 <20170414121756.6iwvxqaqt25c6s74@hooch.localdomain>
 <84363a70-f3b1-f2af-c7d4-83a1e6cae350@ronnypfannschmidt.de>
 <CA+RQFfc_9fxQ56KzoY=16dE2OCBkYqjkiTK5p2xx=_jZUfdqPQ@mail.gmail.com>
Message-ID: <CAG5CgtpLP+p5pqrG_3Z3Az5S0qpcFPVQ4OJ11+PxA8H4J_WRiw@mail.gmail.com>

Hi,

+1 for making releases easier.

Just a thought on the side: mid to long term we might even be able to
synchronize workflows between projects and do something like jazzband (
https://jazzband.co/) for pytest/tox/devpi and plugins that are maintained
by the community.

Cheers,
Oliver

On Wed, 19 Apr 2017 at 13:42 Bruno Oliveira <nicoddemus at gmail.com> wrote:

> On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> wrote:
>
>>
>> On 14.04.2017 14:17, Florian Bruhin wrote:
>> > On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
>> >> What if we instead of considering features, we released a new minor
>> version
>> >> periodically, for say every month or two? We could adopt the same for
>> bug
>> >> fix releases, like each two weeks.
>> > FWIW what GitLab[1] does is a monthly feature release, and patch
>> > releases whenever needed. I don't think it's a good idea to have a fixed
>> > release cycle for patches, but it sounds like it could work quite well
>> > for feature releases indeed.
>>
>
> I'm curious, why do you think it is not a good idea to have a fixed or
> semi-fixed release cycle for patches?
>
>
>> https://github.com/pytest-dev/pytest/blob/master/HOWTORELEASE.rst is
>> about 13 steps,
>> most manual mundane and error-prone - it should be at most 1-2 steps
>>
>
> I agree, we should strive to improve that. The steps are not hard, but
> still they are error prone (remember me sending the email for the pytest
> 3.0 release and writing "and this release contains a lot of bugs and new
> features" instead of "... lot of bug **fixes** and..."). Heh.
>
>
>> >> Having only a master branch, I think Ronny was proposing to then
>> figuring
>> >> out if it was a bug fix release or a minor release based on the
>> CHANGELOG.
>> > That means you either need to arbitarily hold back contributions, or you
>> > lose the ability to do bugfix releases and need to do a feature release
>> > (probably with new subtle bugs, looking at our track record) every time.
>> if we make releasing inexpensive and reliable even a botched release an
>> have a quick fix afterwards,
>> i don't see a problem there, as long as we have processes in place that
>> let stuff like "softening of xfail" to happen we'll have botched feature
>> releases anyway,
>> and IMHO that shouldn't stand in the way of removing unnecessary
>> maintenance pain.
>>
>> what i want to remove is time eating and painful processes at releasing,
>>
>
> I appreciate Ronny bringing up this topic, a 3.1 release is long overdue.
>
> We are discussing two things which have some interconnection:
>
> 1. Should we improve our release process, so that releasing a new version
> is a 1 or 2 step process?
> 2. Keep or not a separate branch for ``features``.
>
> I think we can all agree that 1) would be great and we want that.
>
> Regarding 2), there's a few sub-points:
> 2.1) Periodically have to merge master into ``features``; Ronny believes
> this is a pain, IMHO it's not a big deal;
> 2.2) How often should we release bug fixes and feature releases? This is
> impacted directly by question 1: the easier to make a new release, more
> often we will do it (just pushing a tag every Thursday for a new bug fix
> release for example).
>
> I definitely agree that we should have more frequent feature releases than
> what we have now; I was under the mentality that we wanted all feature
> releases with 2 or 3 major themes and new additions, but given that we
> can't really guarantee time to implement these new features it might make
> more sense to just make new feature releases with just minor improvements
> and changes.
>
> Having said that, I think it is still worthwhile to keep the features
> branch so we can issue bug-fixes quickly and periodically. But for that to
> work, we need to improve the release process so that it takes one or two
> steps at most; we have excellent CI at our service to help us accomplish
> that.
>
> I really would like for us to reach a consensus here. :)
>
> Cheers,
> Bruno.
> _______________________________________________
> 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/20170419/4ad79eec/attachment-0001.html>

From oliver at bestwalter.de  Sat Apr 22 12:04:55 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Sat, 22 Apr 2017 16:04:55 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5CgtraQXpaXEWNzpi8RpXMdvgpdRBfJ8vg8SyJt3La1k0zqg@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <CAG5CgtqfsN9UuL1_F-mcXGN3hsipfN6wsbi65dzppBrLss9cOQ@mail.gmail.com>
 <CANkHFr_SmvcOyqC9biHjYQ65NGLwwyWA5G0QCArv1HKYy-J6uw@mail.gmail.com>
 <CAG5CgtofwHbQOsmzsO11AxXjs5yN9r3uGqpx+eo7b_wRpWj3Cw@mail.gmail.com>
 <CAG5CgtraQXpaXEWNzpi8RpXMdvgpdRBfJ8vg8SyJt3La1k0zqg@mail.gmail.com>
Message-ID: <CAG5CgtonLWFS3+L=W_s_eVnD0-NRo4De8-mG-KDQ2c91w+23Gw@mail.gmail.com>

Hi all,

I almost dropped the ball here as I was on vacation and forgot about this
for a while. I am a lucky guy though, because they extended the time for
CfP until tomorrow so now I started to write a proposal.

I will write a pretty general proposal about offering to help people with
their entry to intermediate level questions and problems regarding pytest,
tox and devpi, because I am confident I can help with that even if I am on
my own. I will offer to help with their problems with configurations or
finding the right testing strategy.

If a problem is unsolvable by me, then it is by definition "advanced" and I
can help formulating their problems/potential bugs as issues or questions
to the TIP mailing list for the gurus to pick up.

I can do the proposal in my name so there is no need for any strict
commitment from anyone but me, but I would obviously be delighted, if you
turn up :)

I'll keep you posted if the proposal was accepted.

Cheers,
Oliver

On Tue, 4 Apr 2017 at 16:16 Oliver Bestwalter <oliver at bestwalter.de> wrote:

> Hi,
>
> I don't know what I saw yesterday, but the call for proposals ist not
> closed, There is time untill the 16th of April ...
>
> Oliver
>
> On Mon, 3 Apr 2017 at 22:57 Oliver Bestwalter <oliver at bestwalter.de>
> wrote:
>
>> Hi,
>>
>> I wrote a mail to ask. I also noticed that the call for proposals is
>> closed already, I asked anyway - maybe there is still some room for us.
>>
>> Cheers
>> Oliver
>>
>> On Mon, 3 Apr 2017 at 16:51 Ionel Cristian M?rie? <contact at ionelmc.ro>
>> wrote:
>>
>> I'm interested in this as well (pytest-cov/benchmark and general pytest
>> help) but what are the guidelines? I suppose there is no space for a 10
>> people "pytest-*" helpdesk. The CFP page is very scarce on information.
>> Anyone already asked organizers for more info?
>>
>>
>> Thanks,
>> -- Ionel Cristian M?rie?, http://blog.ionelmc.ro
>>
>> On Mon, Apr 3, 2017 at 5:25 PM, Oliver Bestwalter <oliver at bestwalter.de>
>> wrote:
>>
>> Hi all,
>>
>> I just got the green light to go to EuroPython, so I volunteer to do the
>> proposal and in the worst case I will be helpdesking away on my own, but I
>> sincerely hope that a few of you will be there and join me :)
>>
>> I would also be willing to help organizing/being part of sprints at the
>> weekend.
>>
>> Cheers
>> Oliver
>>
>> On Tue, 28 Mar 2017 at 10:22 Dave Hunt <dhunt at mozilla.com> wrote:
>>
>> 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/
>>
>> 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/
>>
>>
>> _______________________________________________
>> 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/20170422/3737eadd/attachment.html>

From dhunt at mozilla.com  Mon Apr 24 09:56:42 2017
From: dhunt at mozilla.com (Dave Hunt)
Date: Mon, 24 Apr 2017 14:56:42 +0100
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
Message-ID: <49073EAC-F76E-4CB1-9FBC-DC5DC8E5E93D@mozilla.com>

Unfortunately I?ve decided not to attend EuroPython this year, so I?ll need to revoke my offer to help out. Hopefully next year..!

> On 28 Mar 2017, at 09:21, Dave Hunt <dhunt at mozilla.com> wrote:
> 
> 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 <mailto: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 <mailto: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/20170424/f1a2c2a6/attachment.html>

From dhunt at mozilla.com  Mon Apr 24 11:03:34 2017
From: dhunt at mozilla.com (Dave Hunt)
Date: Mon, 24 Apr 2017 16:03:34 +0100
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <CAG5Cgtr3+57Ob5nVQBBR5AWcfWdw4ZBR=T7TqUNMpm_jXXO0KQ@mail.gmail.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <49073EAC-F76E-4CB1-9FBC-DC5DC8E5E93D@mozilla.com>
 <CAG5Cgtr3+57Ob5nVQBBR5AWcfWdw4ZBR=T7TqUNMpm_jXXO0KQ@mail.gmail.com>
Message-ID: <F1502588-1DE5-4A82-B8C1-A61818F9FF71@mozilla.com>

Unfortunately not. Might be able to attend a pytest sprint if one is planned, but otherwise it?ll probably be next year for me.

> On 24 Apr 2017, at 16:00, Oliver Bestwalter <oliver at bestwalter.de> wrote:
> 
> Hi Dave,
> 
> no problem - was looking forward to see you to though. Are you attending Pycon US? I might be there for the sprints.
> 
> Cheers,
> Oliver
> 
> On Mon, 24 Apr 2017 at 15:56 Dave Hunt <dhunt at mozilla.com <mailto:dhunt at mozilla.com>> wrote:
> Unfortunately I?ve decided not to attend EuroPython this year, so I?ll need to revoke my offer to help out. Hopefully next year..!
> 
>> On 28 Mar 2017, at 09:21, Dave Hunt <dhunt at mozilla.com <mailto:dhunt at mozilla.com>> wrote:
>> 
>> 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 <mailto: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 <mailto:tox-dev at python.org>
>>> https://mail.python.org/mm3/mailman3/lists/tox-dev.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/20170424/180ee66e/attachment.html>

From oliver at bestwalter.de  Mon Apr 24 11:00:00 2017
From: oliver at bestwalter.de (Oliver Bestwalter)
Date: Mon, 24 Apr 2017 15:00:00 +0000
Subject: [pytest-dev] [tox-dev] Suggestion: EuroPython pytest/tox/devpi
 helpdesk
In-Reply-To: <49073EAC-F76E-4CB1-9FBC-DC5DC8E5E93D@mozilla.com>
References: <CAG5CgtoVseAa-1L9QF1uS9RCy4YkobtufrW6=3E_asJR3eySyg@mail.gmail.com>
 <7F885631-AE64-4432-AD62-6D97ED8197AE@mozilla.com>
 <49073EAC-F76E-4CB1-9FBC-DC5DC8E5E93D@mozilla.com>
Message-ID: <CAG5Cgtr3+57Ob5nVQBBR5AWcfWdw4ZBR=T7TqUNMpm_jXXO0KQ@mail.gmail.com>

Hi Dave,

no problem - was looking forward to see you to though. Are you attending
Pycon US? I might be there for the sprints.

Cheers,
Oliver

On Mon, 24 Apr 2017 at 15:56 Dave Hunt <dhunt at mozilla.com> wrote:

> Unfortunately I?ve decided not to attend EuroPython this year, so I?ll
> need to revoke my offer to help out. Hopefully next year..!
>
> On 28 Mar 2017, at 09:21, Dave Hunt <dhunt at mozilla.com> wrote:
>
> 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/
>
> 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/20170424/ff790a6d/attachment-0001.html>

From rkuska at gmail.com  Tue Apr 25 04:02:57 2017
From: rkuska at gmail.com (Robert Kuska)
Date: Tue, 25 Apr 2017 10:02:57 +0200
Subject: [pytest-dev] Help available
Message-ID: <CAH95t5A0Ar6u8SxfY+kdQ11q=iWJNLgxA+czmpkVELvoXs4abw@mail.gmail.com>

Hello everyone,

my employer (kiwi.com) decided to hire a bunch of interns to work on
open source projects we actively use in our company. Each intern has its
own mentor and each mentor picks his open source projects he wants to
overlook.

I am one of the mentors and, as you probably already guessed, I picked
pytest to be my project (it was one of the first modules I ever used in
python).

My current plan is to pick some documentation issues firstly afterwards
continue
with some bugs fixing and as a final step implement some medium-sized
feature.
There are basically no rules from my employer about scope of work and
therefore
I've decided to ask you whether you have some lists of features you would
like
to have implemented but don't have a time to.

I would appreciate any ideas.

Regards,
Robert Kuska
rkuska at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170425/70e5a39b/attachment.html>

From nicoddemus at gmail.com  Tue Apr 25 07:30:25 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 25 Apr 2017 11:30:25 +0000
Subject: [pytest-dev] Help available
In-Reply-To: <CAH95t5A0Ar6u8SxfY+kdQ11q=iWJNLgxA+czmpkVELvoXs4abw@mail.gmail.com>
References: <CAH95t5A0Ar6u8SxfY+kdQ11q=iWJNLgxA+czmpkVELvoXs4abw@mail.gmail.com>
Message-ID: <CA+RQFffR2T2bMHgp-u8eMH2s1PqVnpD38JLXgR=RSEfDvmgLPg@mail.gmail.com>

Hi Robert,

On Tue, Apr 25, 2017 at 5:03 AM Robert Kuska <rkuska at gmail.com> wrote:

> my employer (kiwi.com) decided to hire a bunch of interns to work on
> open source projects we actively use in our company. Each intern has its
> own mentor and each mentor picks his open source projects he wants to
> overlook.
>
> I am one of the mentors and, as you probably already guessed, I picked
> pytest to be my project (it was one of the first modules I ever used in
> python).
>

That's great news! Thanks and congratulations to your company, that's an
excellent initiative on their part.

My current plan is to pick some documentation issues firstly afterwards
> continue
> with some bugs fixing and as a final step implement some medium-sized
> feature.
> There are basically no rules from my employer about scope of work and
> therefore
> I've decided to ask you whether you have some lists of features you would
> like
> to have implemented but don't have a time to.
>

That sounds like a good plan. We don't have an organized list, but we do
label the issues so I would suggest to take a look at issues labeled "docs"
and/or "easy" and choose from there.

As for the medium sized feature nothing comes to my mind right now, I'll
think about it.

Also feel free to ask for help regarding any topic!

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

From nicoddemus at gmail.com  Tue Apr 25 11:40:04 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Tue, 25 Apr 2017 15:40:04 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfd5W1UGk-0-V-uA1G68ihi0y_RVeMyTLY4uh-OGA5Q8YA@mail.gmail.com>
References: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
 <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
 <20170406063031.ffxs5gigshdrwdag@merlinux.eu>
 <CA+RQFfd5W1UGk-0-V-uA1G68ihi0y_RVeMyTLY4uh-OGA5Q8YA@mail.gmail.com>
Message-ID: <CA+RQFfcuc5J6nK6Rs0cGKGwPg8mcZ8o5uJADv9e31ARb=Wh_ZA@mail.gmail.com>

Hi guys,

On Fri, Apr 7, 2017 at 4:31 PM Bruno Oliveira <nicoddemus at gmail.com> wrote:

>
> On Thu, Apr 6, 2017 at 3:30 AM holger krekel <holger at merlinux.eu> wrote:
>
>>
>> I am fine to have user-tests guide the decision ...  so now for me it's
>> only between offering a context manager or offering a special
>> "NoExceptionRaised" object which you can give to pytest.raises(...).
>> so we are almost there and for me, the user-testing can decide that so
>> it's
>> not much discussion left to do at least from my side ...
>>
>
> Made a quick poll again, showing all the possibilities we have been
> considering here (including giving up and not adding anything), and
> pytest.do_not_raise won by 100% of the opinions... but in fact only 5
> people actually took interest and replied, so I don't think this pool has
> much value TBH. :P
>

Anybody would like to make poll on twitter or somewhere else about this? As
I said my own polling was not very conclusive.

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

From brianna.laugher at gmail.com  Tue Apr 25 18:47:00 2017
From: brianna.laugher at gmail.com (Brianna Laugher)
Date: Wed, 26 Apr 2017 08:47:00 +1000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CA+RQFfcuc5J6nK6Rs0cGKGwPg8mcZ8o5uJADv9e31ARb=Wh_ZA@mail.gmail.com>
References: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
 <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
 <20170406063031.ffxs5gigshdrwdag@merlinux.eu>
 <CA+RQFfd5W1UGk-0-V-uA1G68ihi0y_RVeMyTLY4uh-OGA5Q8YA@mail.gmail.com>
 <CA+RQFfcuc5J6nK6Rs0cGKGwPg8mcZ8o5uJADv9e31ARb=Wh_ZA@mail.gmail.com>
Message-ID: <CAPjwCjvH-VF7H2HyOKcT9DOb=d1GxB1fQyPp6r0oXH3FzxY+mA@mail.gmail.com>

If someone can make like a screenshot showing & labelling the various
options, I'll create a poll on the @pytestdotorg account.

Brianna

On 26 April 2017 at 01:40, Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi guys,
>
> On Fri, Apr 7, 2017 at 4:31 PM Bruno Oliveira <nicoddemus at gmail.com>
> wrote:
>
>>
>> On Thu, Apr 6, 2017 at 3:30 AM holger krekel <holger at merlinux.eu> wrote:
>>
>>>
>>> I am fine to have user-tests guide the decision ...  so now for me it's
>>> only between offering a context manager or offering a special
>>> "NoExceptionRaised" object which you can give to pytest.raises(...).
>>> so we are almost there and for me, the user-testing can decide that so
>>> it's
>>> not much discussion left to do at least from my side ...
>>>
>>
>> Made a quick poll again, showing all the possibilities we have been
>> considering here (including giving up and not adding anything), and
>> pytest.do_not_raise won by 100% of the opinions... but in fact only 5
>> people actually took interest and replied, so I don't think this pool has
>> much value TBH. :P
>>
>
> Anybody would like to make poll on twitter or somewhere else about this?
> As I said my own polling was not very conclusive.
>
> Cheers,
> Bruno
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>


-- 
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170426/cae3d3e6/attachment.html>

From nicoddemus at gmail.com  Tue Apr 25 23:24:53 2017
From: nicoddemus at gmail.com (Bruno Oliveira)
Date: Wed, 26 Apr 2017 03:24:53 +0000
Subject: [pytest-dev] [3.1 feature] "assert not raise exception" helper:
 opinions about the name
In-Reply-To: <CAPjwCjvH-VF7H2HyOKcT9DOb=d1GxB1fQyPp6r0oXH3FzxY+mA@mail.gmail.com>
References: <CA+RQFfedu0_-jkcGpqy1yNaMfH_mCDw776FRXWZd5P0+fcOVyg@mail.gmail.com>
 <20170404171944.le4n4erv7obx2lxx@merlinux.eu>
 <b6f13c58-0baf-4f53-7e72-602e457063eb@ronnypfannschmidt.de>
 <20170405163134.oxnoa7lbbvb5fyqz@merlinux.eu>
 <CA+RQFfc2Q7Xpo9CgUDUm=m4KkVUfz9w9yV9vDG62rwGYXy8Q=Q@mail.gmail.com>
 <20170405184421.6qx76tpjuxw47pql@merlinux.eu>
 <20FFE96C-7264-47F0-A5C6-C03B4E380EDC@ronnypfannschmidt.de>
 <87vaqi8tss.fsf@powell.devork.be>
 <CAG5CgtrHW_icZx--Y-=D-t4nfnR-s4XBkUVsQ3rfFQOaTg1Bkg@mail.gmail.com>
 <CA+RQFfdv_iqBAau8ArOsfO5r_SmfNuaV8QOVTGJBsZb-m_sztg@mail.gmail.com>
 <20170406063031.ffxs5gigshdrwdag@merlinux.eu>
 <CA+RQFfd5W1UGk-0-V-uA1G68ihi0y_RVeMyTLY4uh-OGA5Q8YA@mail.gmail.com>
 <CA+RQFfcuc5J6nK6Rs0cGKGwPg8mcZ8o5uJADv9e31ARb=Wh_ZA@mail.gmail.com>
 <CAPjwCjvH-VF7H2HyOKcT9DOb=d1GxB1fQyPp6r0oXH3FzxY+mA@mail.gmail.com>
Message-ID: <CA+RQFfeOQYHQx-nENdBg8pr1OK+H0REuC+j+1TJ5nmBxCnaK5w@mail.gmail.com>

On Tue, Apr 25, 2017 at 7:47 PM Brianna Laugher <brianna.laugher at gmail.com>
wrote:

> If someone can make like a screenshot showing & labelling the various
> options, I'll create a poll on the @pytestdotorg account.
>

Thanks Brianna!

Anybody with some graphic skills is up for it? :)

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