Skip to main content

A tool for checking conditions in Python

Project description

https://github.com/nyggus/easycheck/actions/workflows/check.yml/badge.svg https://codecov.io/github/nyggus/easycheck/branch/master/graph/badge.svg?token=EH4TLHQQWC https://img.shields.io/pypi/l/easycheck.svg https://img.shields.io/pypi/v/easycheck.svg https://img.shields.io/pypi/wheel/easycheck https://img.shields.io/pypi/pyversions/easycheck https://img.shields.io/github/stars/nyggus/easycheck?style=social https://img.shields.io/github/last-commit/nyggus/easycheck

The easycheck package offers a lightweight tool for running functionized checks within Python code; it also offers functions to be used in testing - particularly in doctests, but also in pytests, for which purpose some of the functions have dedicated aliases (starting off with assert_ instead of check_). You can also switch off all easycheck checks, by setting the "EASYCHECK_RUN" environmental variable to "0".

The idea is to use the easycheck functions to check conditions that are _not_ assertions. The checks work in the following general way: When a condition is met, nothing happens (in fact, the function returns None); if it is violated, an exception is raised or a warning is issued. The main differences between easycheck functions and assertions are as follows:

  • Assertions are meant to be used conditions that _must_ be true (when only the code is correct). So, if an assertion is incorrect, it means something is wrong with the code. You should never use assertions to handle regular exceptions, like those related to data or arguments.

  • Unlike assertions, easycheck functions are to be used to check conditions related to things like data and argument values, and to handle regular exceptions.

  • While assertions only raise AssertionError, you can choose any exception to be raised by easycheck functions.

  • When using easycheck, instead of raising an exception, you can issue a warning.

The main easycheck functions (with names starting off with check_) are designed in such a way that they can be used as easy-to-understand code that checks whether one or more conditions are met. They can be used instead of if-blocks, which are normally used to check conditions and raise exceptions (or issue warnings) if they are not met. So, you can do the following:

if not isinstance(x, (float, int)):
    raise TypeError('x must be a number')
if x > 10:
    raise ValueError('Too high value of x')

or you can use easycheck for this:

check_type(x, (float, int), message='x must be a number')
check_if(x <= 10, ValueError, 'Too high value of x')

The easycheck approach has two main advantages over this classical approach:

  • It saves a little space; not much, since most often you’ll end up with one line of code instead of two, but not always, particularly when you provide an exception type to be raised and a long message.

  • Mainly, it increases code simplicity and readability, since both the names of easycheck functions and their arguments are designed in such a way that the reader immediately understands what is being checked.

You can also issue a warning:

check_if(x <= 10,
         Warning,
         'For stable functioning of the function, '
         'x should not be greater than 10.')

The package also offers functions dedicated to testing, e.g.,

assert_type(x, (float, int))
assert_if(x <= 10)

The message argument has the default value of None, which does the following. If the exception class provided in handle_with is built-in (that is, can be found in dir(builtins)), no message is provided. But if it is not a built-in exception (or warning) class, then the exception/warning class’s docstring is taken as the message. This is a convenient way of providing a typical message. If you want to customize the message (e.g., depending on the value of a variable), you should use a customized string (e.g., through an f-string). But if you do not want to use any message with a custom exception/warning, simply provide an empty string (message='').

Read about easycheck

You will find more about assertions in this article, entitled “Python Assertions, or Checking If a Cat Is a Dog” and published in Towards Data Science. It mentions easycheck! You will read about easycheck also in the article “Comparing floating-point numbers with easycheck” (also from Towards Data Science). The Better Programming article entitiled “How to Overwrite AssertionError in Python and Use Custom Exceptions”, mentions the package, too.

Installing

Install and update using pip:

pip install easycheck

Testing

The package is covered with both pytests and doctests. The latter are included in both docstrings of all the functions, but also in documentation files.

Use in code to raise exceptions

Here are several examples of a simple use of basic easycheck functions. The most basic usage resembles the following:

check_if(a < 10)

This simply checks if a is smaller than 10; if it is, nothing happens (in fact, check_if(a < 10) returns None). But if the condition is violated, the function raises AssertionError. AssertionError is the default exception returned by check_if(), but you can change this:

check_if(a < 10, handle_with=ValueError)
# or shorter and equally readable:
check_if(a < 10, ValueError)

For built-in exceptions, like ValueError, the default behaviour is to not print any message. For custom exceptions, however, the exception’s docstring (.__doc__) serves as a message. You can use this when you create custom exceptions:

class IncorrectNameTypeError(Exception):
    """Argument name must be a string."""

name = 40
check_type(name, IncorrectNameTypeError)
Traceback (most recent call last):
  ...
IncorrectNameTypeError: Argument name must be a string.

If you want to ensure that no message is printed, even for a custom exception, override the default behaviour by passing an empty string message=''. You can also add a custom message:

check_if(a < 10, handle_with=ValueError, message='Too high a')
# or shorter and equally readable:
check_if(a < 10, ValueError, 'Too high a')

Some other functions have different default errors; for instance, this call

check_type(a, expected_type=str)
# or shorter:
check_type(a, str)

will raise TypeError while this

check_length([1, 2, 3], 1)

will raise LengthError (an exception class defined in the easycheck module).

Here is a list of easycheck check functions the module offers, discluding assertions, which are listed in the next paragraph:

  • check_if(); it’s the most basic easycheck function, similar to what you would get using if;

  • check_if_not(); the opposite of check_if(), helpful when you need to assure that a condition is not met;

  • check_if_isclose(); to compare two floating-point numbers, based on match.isclose() (see this file);

  • check_if_in_limits(); to check if a number lies between two other numbers;

  • check_length(); to compare length (equal to, smaller than, greater than, and the like);

  • check_type(); to check expected type, similar to isinstance();

  • check_if_paths_exist(); to compare paths (or just one path) exist;

  • check_comparison() (used to compare two items); to compare two objects, just like you would do using if obj1 != obj2: raise

  • check_all_ifs(); used to check multiple conditions and return all the checks;

  • check_argument(); used to make one or more checks of a function’s argument.

You can also use a catch_check() function, if you want to catch an exception or a warning the easycheck function you use would raise (see examples here). Sometimes, however, you will do better using a try-except block to catch exceptions (see examples).

> Note that some easycheck functions are simple wrappers around built-in functions, but their behavior is different, as they have the typical behavior of an easycheck function: if a condition is not met, an exception is raised or an issue is raised.

Assertions

In addition to the above checking functions, easycheck provides a set of functions for assertions. They can be used in both code and tests, just like regular assertions using the assert statement. Assertion functions do have a specific functionality that makes them different from the corresponding check functions. You can read more about it here. In short, assertions are called only in the development (non-production) mode, that is, when __debug__ is set to True. An assertion should check a condition that should never happen; when the corresponding exception is raised, it means that something went wrong in the code, that something that should never happen has just happened.

Some examples:

You are working only on integers, for example pixels when rendering images, or placing objects on a board. You are sure that output will be integer, so you can assert on integers:

def convert_to_pixel_position(real_pos: tuple[float, float]):
    pos_x = real_pos[0]
    pos_y = real_pos[1]
    pixel_pos_x = round(pos_x)
    pixel_pos_y = round(pos_y)
    return pixel_pos_x, pixel_pos_y

pos = convert_to_pixel_position((1.2, 3.4))
assert_type(pos, tuple)
assert_type(pos[0], int)

Now consider a different example. Imagine you have output from some len() method, or any other method calculating the length of something:

out = len(example_object)
# doing something with out, like
number_of_elements_required = out * no_of_objects
assert_type(out_for_something_else, int)

You are working on subset of some data. So the size of the data should not be larger than the initial one, but also not smaller than 0:

def subset_of(data: pd.DataFrame, filter_condition: callable) -> pd.DataFrame:
    # create a data frame that is a subset of `data` based on `filter_condition`
    ...
x = pd.DataFrame({'x': [1, 2, 4], 'y': [3, 3, 5]})
x_subset = subset_of(x, lambda value: value < 3)
assert_if_in_limits(len(x_subset), 0, len(x))

Here is full list of supported assert functions:

  • assert_if(); it’s the most basic easycheck function, similar to what you would get using if;

  • assert_if_not(); the opposite of assert_if(), helpful when you need to assure that a condition is not met;

  • assert_if_isclose(); to assert whether two floating-point numbers are close enough, based on match.isclose() (see this file);

  • assert_if_in_limits(); to assert whether a number is in range of two other numbers;

  • assert_length(); to assert length (equal to, smaller than, greater than, and the like);

  • assert_type();to assert that an object has a particular type, as you would do using assert isinstance;

  • assert_paths(); to assert that a path exists or paths exist.

Use in code to issue warnings

In order to issue a warning if a condition is violated, simply use a warning class (in the handle_with argument) instead of an exception class:

check_if(2 > 1, Warning, 'Too high a value')
check_length([1, 2, 3], 10, Warning, 'Too short list with data')

Remember to always use a message with warnings, in order to make them meaningful. (See more in use_with_warnings_doctest.rst).

Of course, you can use a custom warning:

class TooSmallSampleSize(Warning):
    """Results for samples size below 100 can be unstable."""

n = 50
check_if(n >= 100, TooSmallSampleSize)
... TooSmallSampleSize: Results for samples size below 100 can be unstable.
  warnings.warn(message, error)

Use in code, an example

Imagine you want to connect to a database; if the connection fails for any reason, you want to read an archived flat file. (We will use some undefined functions whose names will clearly convey what the functions do.)

from easycheck import check_if, check_if_paths_exist

class DataBaseConnectionError(Exception):
    pass

def get_data_from_db(db_details, db_credentials):
    try:
        connect_to_db(db_details, db_credentials)
    except:
        return False
    data = get_records_from_db()
    return data

The easycheck code could look like the following:

def get_data(db_details, db_credentials):
    data = get_data_from_db(db_details, db_credentials)
    check_if(
        data,
        handle_with=DataBaseConnectionError,
        message='Cannot communicate with the database'
        )
    return data

You can of course handle this exception, for example like here:

def get_data(db_details, db_credentials, archived_data_file):
    data = get_data_from_db(db_details, db_credentials)
    try:
        check_if(
            data,
            handle_with=DataBaseConnectionError,
            message='Cannot communicate with the database'
        )
    except DataBaseConnectionError:
        check_if_paths_exist(archived_data_file)
        with open(archived_data_file) as f:
            data = f.readlines()
    return data

Of course, you might use here a dedicated context manager. Sure, you can write it in a shorter way, without easycheck, but the flow of information will not be as smooth, resulting in less readability:

def get_data(db_details, db_credentials, archived_data_file):
    data = get_data_from_db(db_details, db_credentials)
    if not data:
        with open(archived_data_file) as f:
            data = f.readlines()
    return data

Of course, the open() context manager will itself throw an error, but when you use the check_if() function and explicitly define an exception class, you clearly show the reader that you’re checking if this file exists and raise a particular exception if it doesn’t.

Use in testing

As mentioned above, most easycheck functions have their asserts counterparts which can be used in testing. Of course, you can use check_if(), but to align with the common use of assertions, the easycheck module offers those aliases so that the reader will immediately see that you’re using these functions to test. Consider these examples:

# Using assertions
def test_something():
    a, b = my_function_1(), my_function_2()

    assert a == 2;
    assert isinstance(a, int)
    assert isinstance(b, tuple)
    assert len(b) == 5

# Using easycheck assert-like functions:
def test_something():
    a, b = my_function_1(), my_function_2()

    assert_if(a == 2)
    assert_type(a, int)
    assert_type(b, tuple)
    assert_length(b, 5)

Note that only the first one will raise AssertionError while the others will raise more meaningful errors (TypeError and LengthError), which may better explain the reasons that the tests did not pass.

You will find more about using easycheck in use_in_testing_doctest.rst.

Other examples

You will find a number of examples in doctest files, which also serve as doctests.

Switching off easycheck

If you want to maximize performance, you may wish to switch off easycheck checks. You would get the greatest increase in performance by removing (or commenting out) all calls to easycheck functions, but this can be inconvenient. Hence, easycheck offers you a more convenient way of doing so, namely, switching off via an environmental variable. This will be less efficient, as this will mean calling an empty function instead of actual easycheck functions. While not the most performant, this approach can increase performance quite significantly. Its obvious advantage is that you do not need to do anything else than just setting the "EASYCHECK_RUN" environmental variable to "0":

> EASYCHECK_RUN = 0
> python my_script.py

The my_script.py script will be run with all easycheck functions replaced with an empty function.

You can also switch off easycheck directly from Python:

import os

os.environ["EASYCHECK_RUN"] = "0"

> Warning: Do remember to use this option wisely. While it will increase performance, it can also change the behavior of the Python program.

Changelog

  • Version 0.6.0 came with significant optimization of performance. Before, easycheck functions performed internal checks of the argument values provided to the function call. Most of these checks are not performed anymore, at least not for the most significant easycheck functions, such as check_if() or check_type(). Some checks, however, are still done. These are mainly checks without which the behavior of the function would be either unwanted or unexpected. We decided to remove all checks that do not change much; for instance, they raise an error due to an incorrect type of an argument value — even though it would be raised anyway, but by the internal Python process, not by the easycheck function itself. The point is to remove such unnecessary checks and that way remove the unnecessary if blocks, which certainly add some cost to execution time. While one such check costs almost nothing, many of them (e.g., in a long loop) can mean a significant cost. As of version 0.6.0, we will try to optimize the performance of easycheck by getting rid of such overhead costs, unless they are important for the behavior of the corresponding easycheck function.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

easycheck-0.10.1.tar.gz (30.0 kB view hashes)

Uploaded Source

Built Distribution

easycheck-0.10.1-py3-none-any.whl (17.7 kB view hashes)

Uploaded Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page