warn 0.0.1

Too long didn’t read:

Explicit is better than implicit:

from warn import path
patch()

# use the warning module as usual

Though the warnings.filterwarning function has now gained the emodule keyword parameter, see below for explanation.

Warning emitter, warning caller.

Python warnings are a beautiful relative simple piece of code which is extremely powerful in the right hands once you learned how to use it.

It allows you to determine a posteriori whether you want a particular piece of code to trigger an exception, display a message to the user or simply do nothing.

It is difficult to show the full power of the waring with a simple piece of code, but in large code base, and once you start having several layer of dependency a parsimonious usage of warning , and in particular DeprecationWarning can make a large difference.

# file emitter.py

def public_api(param1, deprecated_parameter=None)::

    if deprecated_parameter:
        return _deprecated_function(param1, deprecated_parameter):
    else:
        return normal_buisnell_logic(param1)


def _deprecated_function(param1, deprecated_parameter):
    import warningsA
    # warning emitted here
    warnings.warn('using `deprecated_parameter` is deprecated ',
            DeprecationWarning,
            stacklevel=3)

# file caller.py
from emitter import public_api
public_api(1, True)  # warning triggered here.

from warn import path
patch()

import warnings
warnings.filter('default', category=DeprecationWarnings, emodule='emitter.*')
import emitter
emitter.bar() # will log the warning !

Usage without patching

TODO. You should be able to use that in your own library without using patch()

Availability on Python 2

I don’t know if if works on Python 2; I don’t really have the time to investigate; I don’t particularly care a lot; but feel free

limitations

This does not work on packages that either :

• got and keep a reference on warnings.warn before patch() have been called; that is to say things of the form: from warnings iport warn

• cannot work on C-extensions (aka won’t filter on numpy) ; Both of the above are technically possible with Assembly Patching which I’m not confortabl with.

The Ugly

• as Warnings filters have to be 5 tuples with specific types this works by shoving dummy instances in the filters list and using this as keys for a proxy to lookup real filter keys. So worse case scenario the filter you insert with this module will just be no-op. But you will incur a performance penalty if you use this, especially if your codebase triggers a lot of warnings.

Get the upstream

I’d love feedback and have a nicer API to deal with warnings at CPython level in order to provide custom filters, and custom filters functions.

Good Deprecation Warnings.

A good warning and in particular Deprecation warning is extremely helpful and can make the difference for the adoption of an API. Take the following fiction example:

import warnings

warnings.simplefilter(‘default’)

from quezetraste import frobulate, constribule

frobulate(‘HI’, 3) DeprecationWarning: The ‘frobulate’ function is deprecated.

contribule(‘Hi’, 3)

DeprecationWarning: The ‘constribule(message, recipient_id)’ function of the ‘quezetraste’ package is deprecated since version 7.3. It haz been replaced by ‘Recipient(id).send(message)’ which was available since 7.2. See http://url.to/documentation/#1337

Turn the DeprecationWarnings into error in your test-suite!

At least make them visible; at best once you fixed a deprecation warning turn this specific one into an error to not reproduce it.