It seems that `_coerce_map_from_` implementations should indeed be written
quite carefully. An example is CC._coerce_map_from_ where you see the
backtracking happens programmatically:
def _coerce_map_from_(self, S):
RR = self._real_field()
if RR.has_coerce_map_from(S):
return complex_number.RRtoCC(RR, self) * RR.coerce_map_from(S)
if is_ComplexField(S) and S._prec >= self._prec:
return self._generic_convert_map(S)
late_import()
if S in [AA, QQbar, CLF, RLF] or (S == CDF and self._prec <= 53):
return self._generic_convert_map(S)
return self._coerce_map_via([CLF], S)
Comparing that with the example in the documentation
(http://www.sagemath.org/doc/reference/coercion/):
def _coerce_map_from_(self, S):
if S is ZZ:
return True
elif isinstance(S, Localization):
return all(p in self._primes for p in S._primes)
We see no effort is made to backtrack on ZZ for things that might coerce
into ZZ. Any structure with an "embedding" into ZZ would be missed. For
this particular case it's probably fairly safe, but if people learn from
this example how to implement coercion, we're going to end up with
non-transitive coercions all over the place. Would it be better (for
illustrative purposes) to add the lines:
else:
return self._coerce_map_via([ZZ], S)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
