Implements a mantra for declaring abstract methods

[nthiery]

This patch implements a decorator tha can be used to declare a method
that should be implemented by derived classes. This declaration should
typically include documentation for the specification for this method.

The purpose is to enforce a consistent and visual mantra for such
declarations. This is also used by #5891 for automated tests.

CC: @sagetrac-sage-combinat

Component: misc

Keywords: abstract methods

Author: Nicolas M. Thiéry

Reviewer: Robert Bradshaw

Merged: sage-4.1.alpha2

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

[williamstein]

comment:1

Feedback and suggestion for improvement on this policy are welcome!

sage: x = A() 
sage: x.my_method?
BOOM!

This must be fixed by improving sageinspect. That should be easy.

1. Trick to catch.

2. How do you get the docs on my_method though?

[nthiery]

Attachment: abstract_method-6097-nt.patch.gz

[nthiery]

comment:3

Replying to @williamstein:

Feedback and suggestion for improvement on this policy are welcome!

sage: x = A() 
sage: x.my_method?
BOOM!

This must be fixed by improving sageinspect. That should be easy.

1. Trick to catch.

2. How do you get the docs on my_method though?

I commented on those in the patch.
I vote for integrating the code now, and improve it later when we will have more experience.

[nthiery]

Description changed:

--- 
+++ 
@@ -3,6 +3,4 @@
 typically include documentation for the specification for this method.
 
 The purpose is to enforce a consistent and visual mantra for such
-declarations. In the long run, this will be used for automated
-systematic signature checks.
-
+declarations. This is also used by #5891 for automated tests.

[ncalexan]

comment:5

Making this fail on access is so introspection and command line unfriendly that I vote a very strong -1 to it.

[nthiery]

comment:6

Replying to @ncalexan:

Making this fail on access is so introspection and command line unfriendly that I vote a very strong -1 to it.

Thanks for the feedback!

Note that this is an exceptional situation: in principle, users are not supposed to encounter this situation
(in a compiled language, the code would not even compile). In any cases, this will be trivial to change later.

Do you see any strong reason not to merge this patch as is, until we accumulate enough experience?
(there are 20 patches piling upon this one).