Sergey B Kirpichev

Ok, lets consider some possibilities. 1. We could add IEEE 754-like signed zeros. This will require incompatible changes, see e.g. https://github.com/mpmath/mpmath/issues/786. 2. Without signed zeros we could simplify the mpf...

Patches are welcome.

> I wonder more generally though what should be expected in terms of backwards compatibility here. Yes, I think we should decide on what is a part of the API....

> Probably only rational is something that downstream code might be expected to use from there. > ... The mpq type is an example of something where it is not...

I saw this, but it doesn't explain why SymPy uses this class. Another (only?) use case is the [mpelements.py](https://github.com/sympy/sympy/blob/4323bf2be3fc64294ac83333eb6a42f45d097595/sympy/polys/domains/mpelements.py#L144-L146). This block could [trivially be changed](https://github.com/diofant/diofant/pull/1324/commits/1ba644fa1d842d7c36b71a005ccf9c3772c96075) to use Fraction's. Unfortunately, proposed...

> If there are cases though where mpmath might return an MPQ I doubt there are. > there should be some public way for downstream code to access the MPQ...

With #703 the issue with mpnumeric import should be fixed. I think, that other stuff (related to using `mpmath.rational.mpq`) should be fixed on the SymPy side. Let's rename this issue...

> A general problem in Python is that it is not often clear what is internal vs public and by default everything is made publicly accessible by the language itself....

> I would be happy to do that immediately in SymPy if we had a clear list of what should not be used. All mpmath.libmp.* stuff. Why not use high-level...

> The highest level mpmath APIs all use a global precision in the mpmath module context objects. Yes, that's an issue and we have #683. > At minimum SymPy should...