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

[Ronny Pfannschmidt]

Hi Holger,

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

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

its changes like that that ensure maintenance pain in future,

in reference, just take a look at marks,

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

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

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

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

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

-- Ronny


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