Weaker precondition for registering a new coercion

[nthiery]

With the attached patch, the precondition for registering a new
coercion from P to Q with register_coercion becomes:

"no coercion into P has been queried, or no coercion from P to Q has been registered or discovered earlier"

Which is a bit weaker than the previous:

"no coercion into P has been queried"

This should still be quite safe, while covering all the formerly
problematic practical use cases coming up in the category code #5981.

CC: @sagetrac-sage-combinat @robertwb

Component: coercion

Author: Nicolas M. Thiéry

Reviewer: Robert Bradshaw

Merged: sage-4.3.alpha0

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

[mwhansen]

comment:2

I think is probably okay. After thinking about it for a bit, I could come up with a situation where this change would make the coercion graph non-commutatitve.

I'll run all the tests with it here in a bit.

[robertwb]

comment:4

There is one way this can go wrong. Suppose one has B -> C, and one wants to register A -> B. If A -> C was previously requested, its non-existence will be cached.

Now I don't think this will be an issue in practice, nor does _unset_coercions_used solve it.

[nthiery]

Description changed:

--- 
+++ 
@@ -1,7 +1,7 @@
 With the attached patch, the precondition for registering a new
 coercion from P to Q with register_coercion becomes: 
 
- "no over coercion from P to Q has been registered or discovered earlier"
+ "no coercion into P has been queried, or no coercion from P to Q has been registered or discovered earlier"
 
 Which is a bit weaker than the previous:
 

[nthiery]

comment:6

With the updated patch register_coercion also does not bark if _coercions_used is false.

Otherwise, this triggered to failing doctests in sage/modules/fg_pid/fgp_module.py
and sage/modules/fg_pid/fgp_morphism.py. An expert should investigate why a coercion gets registered twice in those modules, and whether this is not a bug. But I vote for postponing that for later.

[nthiery]

comment:7

Replying to @robertwb:

There is one way this can go wrong. Suppose one has B -> C, and one wants to register A -> B. If A -> C was previously requested, its non-existence will be cached.

Now I don't think this will be an issue in practice, nor does _unset_coercions_used solve it.

I agree.

So, is this positive review?

[nthiery]

The previous version was missing a patch header.