Incompatible (with int) parsing of the sign in the mpz constructor about gmpy HOT 3 CLOSED

Another example:

>>> int('  0xA',base=0)
10
>>> mpz('  0xA',base=0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid digits

BTW, base=0 is incompatible with the int's base=10 default.

from gmpy.

Python and GMP handle embedded white space differently. They both ignore leading and trailing white space. But Python considers embedded white space an error while GMP ignores embedded white space.

The general rule is that gmpy2 should always return the same result as Python if no exception is raised by Python. Raising an exception when Python doesn't is a bug. Returning a "reasonable" value when Python raises an exception is acceptable (at least it is to me).

I think striping all white space is fine and matches the current behavior. But we won't match the Python exceptions for
embedded white space and I don't think it is worth changing GMP's behavior.

I also prefer the default of base=0. It is easier for converting strings that include the leading base indicators.

from gmpy.

The general rule is that gmpy2 should always return the same result as
Python if no exception is raised by Python. Raising an exception when
Python doesn't is a bug. Returning a "reasonable" value when Python raises
an exception is acceptable (at least it is to me).

Sure, that was the rule I kept in mind.

I think striping all white space is fine and matches the current behavior.

Probably, this does make sense for all constructors.

I also prefer the default of base=0. It is easier for converting strings
that include the leading base indicators.

My fault. That difference does matter only where Python raises exceptions (e.g. `int('0x10')).

from gmpy.