Testsuite: allow sharing code between is_bar and _test_bar methods

[nthiery]

is_method / _test_from_is_method: method wrappers to factor out code between is_bar and _test_bar methods

From the documentation:

The typical usecase for those wrappers is as follow: Consider a
category Foo with a subcategory Bar. Foo wants to
provide a method Foo.ParentMethods.is_bar such that, for F
in Foo(), F.is_bar() returns whether F satisfies all
the properties of Bar(). The method is_bar is allowed to
assume that F indeed satisfies all the properties specified by
Foo(). It may decide to upgrade the category of F to
Bar().

Bar itself wants to provide a method
Bar.ParentMethod._test_bar which is supposed to do some
reasonable sanity checks on F to determine whether it
satisfies all the properties of Bar. If yes, F._test_bla()
should return None; otherwise it should raise some (hopefully
meaningful) assertion. Note that Bar() will typically
override is_bar by a trivial method that always returns
True.

The purpose of two decorators is_method and
_test_method_from_is is to factor out the logic between the two
related methods F.is_bla() and F._test_bla(). They take as
input a Python function is_bla(self, proof=False, **options).
This function should proceed as usual for a _test method (see
:class:TestSuite). If proof is True, then the answer
should be provably correct. At the end, is_bla should return
None, or a category that will be used to refine the category
of F.

CC: @sagetrac-sage-combinat

Component: misc

Keywords: days38

Author: Nicolas M. Thiéry

Reviewer: Franco Saliola

Issue created by migration from https://trac.sagemath.org/ticket/12920

[nthiery]

Changed keywords from none to days38

[roed314]

comment:5

Attachment: trac_12920-is_test_methods-nt.patch.gz

[videlec]

comment:6

Needs to rebase on 5-11.beta3 (reject on unittest.py).

The patch may definitely be useful. There are two things that I dislike.

1. When you add the decorator the code does not correspond anymore to a is_X method (it does not return a boolean but raise an error or return a refined category). In other words, it is unreadable. Moreover, when you want to access the documentation (reusing your example)

sage: F = FiniteUnion([GF(2), GF(3)])
sage: F.is_finite?

you get something that you do not want to see here.

2. the speed

sage: %timeit F.is_finite()
10000 loops, best of 3: 27.2 us per loop

just to compare

sage: class P:
....:     def is_finite(self):
....:         return True
sage: p = P()
sage: %timeit p.is_finite()
1000000 loops, best of 3: 218 ns per loop

which is how is_finite should be implemented for a finite set.