Hi everyone,

while taking a closer look and trying to understand what cpython does, i
stumbled upon
https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/main.py#L77

so their default runner just crudely pushes a simplefilter onto the
complete system with an crude extra in

https://github.com/python/cpython/blob/v3.6.1/Lib/unittest/runner.py#L159

by now i do believe to just blindly show any deprecation is going to be
a massive disservice to the users (because they do use libraries)

- i believe it should e left to the library-authors to pick what exact
warnings to show
- for pytest - we should actually pick what to show inside pytest,
because we are the "library authors" of pytest

-- Ronny


Am 29.05.2017 um 19:57 schrieb Bruno Oliveira:
> Hi everyone,
> 
> Ronny and I discussed a bit on GTalk and realized that perhaps we can
> fix the current warnings plugin and avoid having to disable it entirely:
> simply removing the filter installed
> in https://github.com/pytest-dev/pytest/blob/master/_pytest/warnings.py#L56 
> might
> be sufficient to fix the affected suites. Installing that filter
> unfortunately overrides all custom filters because it will take priority
> over everything else. I did a quick test with the example posted
> in https://github.com/pytest-dev/pytest/issues/2430 and it does work.
> 
> New proposal: create a PR with the fix above and test it in a few of the
> suites mentioned in https://github.com/pytest-dev/pytest/issues/2430. If
> this actually fixes it, we can make a 3.1.1 release which is now just a
> simple bug fix.
> 
> We did discover however that this will *not* show deprecation warnings
> by default though. To make them appear, we need to install a custom
> filter but we are not sure which filter to install at the moment.
> 
> Thoughts?
> 
> Bruno.
> 
> On Mon, May 29, 2017 at 9:20 AM Bruno Oliveira <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     Thanks everyone.
> 
>     If it is alright then, I will prepare a 3.2.0 release later today. 
> 
>     Cheers,
>     Bruno.
> 
>     On Mon, May 29, 2017 at 9:18 AM RonnyPfannschmidt
>     <[email protected]
>     <mailto:[email protected]>> wrote:
> 
>         *resent after bad email client config*
> 
>         i like the 3.2 plan,
> 
>         i think its fine to mark 3.1 as botched
> 
>         we should have a proper discussion about feature lifetimes in
>         future,
>         just deprecation is simply not enough - and it seems we repeat
>         mishaps around releasing "complete" features
> 
>         -- Ronny
> 
>         Am 29.05.2017 um 14:06 schrieb Bruno Oliveira:
>>         Hi Floris and Brian, thanks for joining.
>>
>>         On Mon, May 29, 2017 at 8:44 AM Floris Bruynooghe
>>         <[email protected] <mailto:[email protected]>> wrote:
>>
>>             Hi,
>>
>>             On 26 May 2017 at 15:51, Brian Okken
>>             <[email protected]
>>             <mailto:[email protected]>> wrote:
>>             > My opinion:
>>             > - make 3.1.1 with this feature opt in
>>
>>             I'd have agreed with this initially.  But I think releasing an
>>             un-broken version should probably only be done within the
>>             first
>>             24-48h.  After that the pain might just increase rather
>>             then decrease.
>>
>>
>>         If we were to make it opt-in, I would rather release a 3.2.0
>>         version; this way we can think of 3.1 as a "botched" release
>>         and more emphatically communicate the change to users.
>>
>>             > - new features that change behavior in backwards
>>             incompatible way should be
>>             > opt in.
>>
>>             Probably with a note that next major release they'll be
>>             switched on by
>>             default and give people the time to already disable them
>>             in their
>>             config for that case
>>
>>
>>         Sounds like a good idea. The problem in this case was that we
>>         didn't foresee stuff actually breaking, otherwise it would be
>>         an opt-in feature from the start.
>>
>>         Guys, anymore opinions? I'm willing to prepare a 3.2.0 release
>>         today with warnings opt-in if we all agree this is the best
>>         course of action.
>>
>>         Cheers,
>>         Bruno.
>>
>>
>>         _______________________________________________
>>         pytest-dev mailing list
>>         [email protected] <mailto:[email protected]>
>>         https://mail.python.org/mailman/listinfo/pytest-dev
> 
_______________________________________________
pytest-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pytest-dev

Reply via email to