Add support for __new__

[jdemeyer]

Is there any specific reason why __new__ is not defined for the gmpy2 types? You already have the Pympz_new function, which essentially implements tp_new.

In [1]: from gmpy2 import mpz as make_mpz

In [2]: mpz = type(make_mpz())

In [3]: mpz.__new__(mpz)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-1628ff8a09e4> in <module>()
----> 1 t.__new__(t)

TypeError: object.__new__(mpz) is not safe, use mpz.__new__()

Being able to create mpz objects using __new__ is crucial to allow other packages to interface efficiently with gmpy2.

It would also make sense to implement __init__ which could replace the mpz() factory function. Personally, I care much less about this part.

[casevh]

I have a prototype for new that ignores any arguments and just returns mpz(0). Are you planning to pass it a Python int/long or do you want to use something like mpz_import(...) to convert some sequence of bytes to an mpz_t?

[jdemeyer]

I have a prototype for new that ignores any arguments and just returns mpz(0).

That is exactly what I need.

Are you planning to pass it a Python int/long or do you want to use something like mpz_import(...) to convert some sequence of bytes to an mpz_t?

It could really be any mpz_FOO() call, but most probably some variant of mpz_set().

[jdemeyer]

By the way, why are you using a separate constructor function mpz() instead of just mpz.__init__()? The latter looks more like standard Python practice. The current way is confusing because you currently have 2 things called mpz (the function and the type). Also, this doesn't do the right thing because mpz is a function:

from gmpy2 import mpz

if isinstance(x, mpz):
    ...

[jdemeyer]

mpz.__new__(mpz) works but it does not work (yet) for the other types.

[casevh]

The use of a factory function dates back many years, long before I started maintaining gmpy. I've been planning on changing this behavior in 2.1. I've treated the 2.0.x series as a bug-fix only version and changing the behavior of mpz might be too visible of a change.

Of the various issues you've raised, which ones are the most important one for and could the be done in a bug-fix only version (i.e. low risk of user visible changes)?

I don't mind changing master to 2.2 and releasing a 2.1 version with user-visible changes. Or I might just try to get master released...

[jdemeyer]

The use of a factory function dates back many years, long before I started maintaining gmpy.

OK, I see. And I also agree that changing mpz to be the type is not a bug-fix (although I don't see how it could break user code).

This change is not super-important for me, it would mainly make things simpler.

Of the various issues you've raised, which ones are the most important one for and could the be done in a bug-fix only version (i.e. low risk of user visible changes)?

At this point, #121 is probably the most important remaining issue.

[skirpichev]

>>> import gmpy2
>>> gmpy2.mpz.__new__(gmpy2.mpz)
mpz(0)

@casevh, probably you can close this issue.