[pytest-dev] [3.1 feature] "assert not raise exception" helper: opinions about the name

[holger krekel]

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