Remove use of PY_IS_NUMERIC

[jdemeyer]

Last 10 new commits:

​1e88c72	Another polynomial division action test.
​a60134c	trac #17740: review 1 (documentation)
​728811d	trac #17740: review 2 (clean Errors)
​96c1a03	trac #17740: review 3 (less in try/except block)
​2cb51c0	Re-introduce action of fraction field as fallback for division action.
​bff474b	Better _pseudo_fraction_field default implementation.
​9c970ae	trac #17740: merge sage-6.6.beta1
​2075e2e	trac #17740: avoid parent deaths
​4fcee82	Merge commit '2075e2e' into t/17800/ticket/17800
​7083f19	Remove use of PY_IS_NUMERIC

[vdelecroix]

Could we get rid in the same ticket of _native_coercion_ranks_inv and _native_coercion_ranks and use coerce from Python

>>> coerce(True, 1l)
(1L, 1L)
>>> coerce(complex(0,1), 1.0)
(1j, (1+0j))

Or even better ​PyNumber_Coerce from the C API.

[jdemeyer]

Can you make a new ticket for that instead?

[vdelecroix]

Replying to jdemeyer:

Can you make a new ticket for that instead?

Yes #17865

[vdelecroix]

I just have two remarks but not for this ticket I guess:

• Don't we want to use faster functions in py_scalar_to_element?

• It is clear that we want compatibility between structure.coerce.py_scalar_parent and structure.element.py_scalar_to_element. I do not like the fact that these two functions belong to two different files and do not call each other in their doctests.

[jdemeyer]

Replying to vdelecroix:

I just have two remarks but not for this ticket I guess:

• Don't we want to use faster functions in py_scalar_to_element?

If you mean functions like PyFoo_Check(): Cython knows them too, it will generate calls to PyFoo_Check() in isinstance.

• It is clear that we want compatibility between structure.coerce.py_scalar_parent and structure.element.py_scalar_to_element. I do not like the fact that these two functions belong to two different files and do not call each other in their doctests.

Good point.

[vdelecroix]

Replying to jdemeyer:

Replying to vdelecroix:

I just have two remarks but not for this ticket I guess:

• Don't we want to use faster functions in py_scalar_to_element?

If you mean functions like PyFoo_Check(): Cython knows them too, it will generate calls to PyFoo_Check() in isinstance.

Nope. I meant the conversion Python int -> Sage integer and such.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​7eb0e93

Move py_scalar_to_element to coerce.pyx

[jdemeyer]

I moved py_scalar_to_element to coerce.pyx, but I couldn't improve the conversion because of circular import problems.

[vdelecroix]

I did not know

sage: isinstance(True,int)
True

Do we really want the bool -> Integer to happen within Sage? We can do an exact type check instead. That would break support for subtyped Python base classes though. Another drawback is that it would not be possible anymore to count like

sage: sum((x >= 3 for x in my_list), ZZ(0))

So I am in favor of your solution.

For the speed-up, that is not dramatic.

I changed the doc to make the link :class:`Element` works. I am ok for positive review.

---

New commits:

​8300f59

trac #17862 (review): doc typo