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 <[email protected]> > >> wrote: > >> > >>> Hi all, > >>> > >>> On Fri, Mar 31, 2017 at 7:13 AM Vasily Kuznetsov <[email protected]> > >>> 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 [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
