00:00:00

Pytest Deprecation Policy

exit strategy

Why?

  • Functionality that has better alternatives still kept around without clear exit strategy
  • 3.0 is a good point in time to introduce a deprecation policy
  • Been mainly at the receiving end of deprecation and been bitten (requests, flask)

Notes

Kick the old busted stuff

old vs new

Notes

... preventing this:

old vs new

Notes

Usual reason for deprecation is not removing functionality, but to replace OldBusted eay of doing things with NewHotness way of things - so you should actially not despair if you see a deprecation warning but rather cherish the new and much easier way to accomplish your tasks.

Emerging design leads to warts that need to be ironed out at some point to keep the code maintainable and accessible for newcomers.

Want to know how to do it right/gentle might be boring, annoying for old hands but for me something where i feel i could be useful.

I would be interested to 'sell' the new policy to users (especially that we're aware of the pain and that we will not flood them with 'clusters of deprecation' (good name for a progressive death metal band)

users relax: pytest 3.0 != python 3.0

  • Which kinds of warnings from where should be on by default? (deprecation, generated by pytest)
  • Versions: python-deprecate
  • Filtering pytest-warnings => core (> 3.1)
  • Two versions: (silent -> loud -> BOOM!)
  • removals (=> first chance in 4.0)

Worth it?

  • Config.option
  • Config.getplugin
  • Config.getvalue
  • Config.getvalueorskip
  • PluginManager: pm.addhooks

Notes

Worth it?

  • pytest_cmdline_preparse
  • yield_fixture (oldest deprecation? Since 1.10)
  • funcargnames
  • cached_setup
  • pytest_itemstart

Notes

Worth it?

  • compatproperty.fget
  • tmpdir.ensuretemp
  • genscript.py
  • addcall
  • Node.X access

Notes

Worth it?

  • outerr usage in repr_failure
  • command line option --report (use -r)
  • command line option --no-assert (--assert=plain)
  • command line option --nomagic (--assert=plain)

Notes

How?

  • Report warnings as default
  • Versioned deprecation
  • good reporting
  • (Verbose) warnings clearly document upgrade path
  • Keep deprecations for at least two minor releases
  • Removals only in major releases

Notes

  • Python core/stdlib
  • Plone/Zope
  • Django
  • SemVer recommendations
  • Related pytest issues

When?

  • Tell people about it as part of the 3.0 release
  • First step: Report warnings as default as part of 3.0 release
  • First removals of deprecated functionality in 4.0

Notes

  • issues are at the end

Last but not least ...

__multicall__

  • deprecated for quite a while
  • (Not necessary anymore) could lead to a 30% performance increase

Notes

Related issues I

  • re-enable all warnings by default #1191
  • pytest should integrate with warnings module #253
  • Recwarn empty #28
  • xdist does not report warnings #602
  • Inconsistent behaviour of recwarn #840
  • Option to treat warnings as errors #1173

Notes

Related issues II

  • py.test ignores warnings.simplefilter #1043
  • Test run summary bar is yellow but not clear why, after updating to v2.8.2 #1179
  • Warnings do not become errors with --strict #1381
  • Indicate non-pytest warnings in the UI #1262
  • PendingDeprecationWarning triggered when run with -Werror #1403

Notes

todo:

  • Fix related pending issues about warnings
  • determine timings
  • See how it's done atm (consistent? Concrete timings?)
  • explore tooling (python-deprecate, pytest-warnings, ...)

The end

Notes