nyggus / easycheck Goto Github PK

check_argument() is actually a function that has potential to be used most often among the easycheck functions, so would be good to provide an example of its use in the main README.

Add the description of check_if_in_limits() to docs files.

Add function check_subclass to check if an object is a subclass. For example:

>>> class MyWarning(Warning): pass
>>> check_subclass(MyWarning, str)
False
>>> check_subclass(MyWarning, Warning)
True

Add function check_if_isclose() (and assert_if_isclose()), to compare two floats. This will basically be a wrapper around math.isclose() that, unlike it (which returns a bool), will behave like other easycheck functions.

Assert functions should not accept warning classes as a value of handle_with.

The decorator will work in the following way:

from easycheck import disable_checks, check_if

@disable_checks(False)
def foo(x):
    check_instance(x, int)
    pass

As @disable_checks got False, the foo() function will run check_instance(). However, if you make it @disable_checks(True), meaning that you want to disable checks, then check_instance() will not be run and the check will not be made. This can save quite some time if foo() is run many times - but of course you need to remember that disabling checks can affect the behavior of the function.

Use default of ValueError instead of AssertionError in check_if(). The latter is used in assert_* functions, and it's fine. But the natural solution for check_if() seems to be ValueError.

Add function check_if_sorted() and its alias assert_if_sorted().

This is the continuation of another issue. This task aims to implement unit complex tests to check the traceback of all easycheck check functions and assertion functions.

You can use check_length() to compare an object's length in various ways. Currently, it's done using expected_length argument. However, you can use any operator, like operator.ne, in which case you're checking if the length of an object is not equal to this value. So, its name can be misleading and so it should be renamed. The new name can be compare_to.

_raise() has quite a significant overhead, so it should be redesigned to make it faster.

In Python, you can do this:

x = [10, ]
if x: print("x is not empty")

You cannot do this with easycheck, as check_if() accepts only a Boolean value and will not transform any object to a bool, like above. This should be changed.

Add function check_if_in_limits(x, lower_limit, upper_limit, include_equal=True) and its testing alias assert_if_in_limits().

The function will check if a number (either a float or an int) lies with the provided range. include_equal=True means the check will use >= and <= operators, while include_equal=False will use > and < operators.

Note: for the moment not replicable
I have noticed some issues when using easycheck with pandas, but in quite complex situations. I cannot, however, replicate this situation, but it's clearly worth double-checking whether easycheck works well with pandas.

check_if_not can have a nice use in the following scenario. Imagine you have two arguments, say x and y, whose combination of x == 1 and y == 2 is invalid. You can check it using the following call:

>>> check_if_not(x == 1 and y == 2)

This is something you cannot achieve using a simple call to check_if or any other easycheck function, which makes this scenario a perfect one for using check_if_not, hence such an example can be added to the main README of easycheck.

We forgot to add tests for catch_check() working with check_if_isclose().

The check_comparison() function seems to be reluctant. It works the same way as check_if(), but seems to be less clear. For instance,

check_if(x >= y)

is clearer, and more natural, than

from easycheck import gt

check_comparison(x, gt, y)

Should we deprecate check_comparison()?

This can be done in an easy way, via making AssertionError the default value of handle_with, and adding if __debug__: blocks to the code. So, the assert_ functions would stop being aliases as they would get new functionality.

Currently, condition_to_check = operator(len(item), expected_length) disables to use handle_with as exception/warning when assign_length_to_others=True, as it's used only in the next step. To use it, a try-except block, or something similar, needs to be checked for condition_to_check.

Imagine you have a custom exception that takes some arguments. You cannot pass these arguments using easycheck. This tasks aims to enable that, through passing *args and **kwargs from easycheck functions to the instances of custom exception classes (created when an exception is raised).

Check if the exception class provided has .message attribute: if it does and the user did not provide a message, use it; otherwise, don't.

Add performance tests (using perftester) to analyze and test how the easycheck functions perform against their built-in counterparts.

Now, easycheck can also raise a single exception. So, it's impossible to

raise Exception1 from Exception2

It seems to make sense to enable this functionality. This can be done via a new argument, e.g., raise_from. The default of None would mean not raising from.

Add function annotations to easycheck functions.

In four locations, # type: ignore is added. The question is, should these be fixed or left? Maybe simplified?

The switch function doesn't set __tracebackhide__ to True. Thus the resulting traceback when an easycheck check fails is uninformative. This task aims to add the following line to the switch function:

__tracebackhide__ = True

and then implement unit tests to test the structure of the traceback for failing easycheck.check_if checks.

Should it use math.nan and float('nan'), too?

Catching a check is easy with catch_check():

>>> check = catch_check(2 == 1, ValueError)
>>> check
ValuError
>>> check = catch_check(2 == 2, ValueError)
>>> check

What the documentation could show is that it's simple to use the check object:

>>> if check:
...     do_something()
...     raise check
Traceback (most recent call last):
    ...
ValueError

This will do_something() when the check failed, and then it will raise the . This is a rare situation to do something like that, but sometimes you may want to do something before raising the exception.
This approach can be particularly helpful when you want to raise a warning and return, without finishing a function in a standard way.
This task aims to update documentation to explicitly say how to do it, even if this is nothing difficult. New Python developers, however, may benefit from such explicit documentation.

Let the user use a class exception's __doc__ as the message. For instance:

>>> class IncorrectSomethingError(Exception):
...     """Something should be smaller than 10."""

>>> check_if(
...     something < 10,
...     handle_with=IncorrectSomethingError,
...     message=ExceptionDoc()

For this, we need to defined ExceptionDoc (or something like this). Enough to use an empty class:

>>> class ExceptionDoc:
...     pass

and then, in code, when a message is created, enough to check

if isinstance(message, ExceptionDoc):
    message=handle_with.__doc__

Such an opportunity will unlikely be used with built-in errors, but can be very useful in the case of custom exceptions.