why did GMPY change the names of its functions?

[Mensanator]

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.

But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

What's the justification for that? I use those functions extensively
in my library of Collatz utilities and I had to re-edit them for no
obvious reason.

 

[alex23]

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.
But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

Python is not gmpy. You might be better served asking the project
maintainer(s).

What's the justification for that? I use those functions extensively
in my library of Collatz utilities  and I had to re-edit them for no
obvious reason.

Well, the obvious reason is that it's a different version which offers
no promise of API backwards compatibility.

 

[Terry Reedy]

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.

But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

Guess: Either the functions changed or they want to regularize their names.

What's the justification for that? I use those functions extensively
in my library of Collatz utilities and I had to re-edit them for no
obvious reason.

If GMPY is coded in Python with a C? backup, GMPY.scan0 = GMPY.bit_scan0
should work.

Or you could write a GMPY.py wrapper for GMPY2

from GMPY2 import *
scan0=bit_scan0
scan1=bit_scan1
<any other compatibility hacks>

and leave your user code alone.

 

[Mensanator]

Guess: Either the functions changed or they want to regularize their names.


If GMPY is coded in Python with a C? backup, GMPY.scan0 = GMPY.bit_scan0
should work.

Or you could write a GMPY.py wrapper for GMPY2

from GMPY2 import *
scan0=bit_scan0
scan1=bit_scan1
<any other compatibility hacks>

and leave your user code alone.

Oh, similar to an "import as", but this would
allow me to change individual functions. Thanks.

 

[casevh]

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.

But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

What's the justification for that? I use those functions extensively
in my library of Collatz utilities and I had to re-edit them for no
obvious reason.

I'll speak up as the maintainer of GMPY and GMPY2.

(My comments apply to the beta1 release which should be out in a couple of days.)

GMPY2 introduces many changes:

1) the limited "mpf" type that is based on GMP has been replaced with the "mpfr" type from the MPFR library
2) support for multiple-precision complex arithmetic based on the MPC library
3) support for a mutable integer type optimized for in-place bit manipulations
4) support for addition number theory functions (generalized Lucas sequences and more primality tests

I began to encounter name collisions; for example, should sqrt() only return integer square roots. I chose to call it a new name (gmpy2) and update the API to reflect new choices I made. For example, sqrt() now returns an "mpfr" and isqrt() returns an "mpz".

As part of the documentation for the beta release, I will document the namechanges. "import gmpy2 as gmpy; gmpy.scan0=gmpy.bit_scan0; etc" should work just fine.

If you encounter problems with the alpha release, please open an issue on gmpy's site.

Thanks,
casevh

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.

But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

What's the justification for that? I use those functions extensively
in my library of Collatz utilities and I had to re-edit them for no
obvious reason.

OK, GMPY is now called GMPY2. No big deal, I can import as GMPY.

But why were scan0 and scan1 changed to bit_scan0 and bit_scan1?

What's the justification for that? I use those functions extensively
in my library of Collatz utilities and I had to re-edit them for no
obvious reason.

 

[Mensanator]

I'll speak up as the maintainer of GMPY and GMPY2.

(My comments apply to the beta1 release which should be out in a couple of days.)

GMPY2 introduces many changes:

1) the limited "mpf" type that is based on GMP has been replaced with the"mpfr" type from the MPFR library
2) support for multiple-precision complex arithmetic based on the MPC library
3) support for a mutable integer type optimized for in-place bit manipulations
4) support for addition number theory functions (generalized Lucas sequences and more primality tests

I began to encounter name collisions; for example, should sqrt() only return integer square roots. I chose to call it a new name (gmpy2) and update the API to reflect new choices I made. For example, sqrt() now returns an "mpfr" and isqrt() returns an "mpz".

As part of the documentation for the beta release, I will document the name changes. "import gmpy2 as gmpy; gmpy.scan0=gmpy.bit_scan0; etc" shouldwork just fine.

If you encounter problems with the alpha release, please open an issue ongmpy's site.

Thanks,
casevh

Thanks for the explanation. Sorry if I flew off the handle, but I've
been sick recently and am trying to get
back into Python after 2 years. I just bought a new laptop, downloaded
Python 3.2 & GMPY2 only to see my
Collatz library crash. At first, given my current condition, I was
afraid I'd never get it to work again.
But luckily, the fix is simple.
I, for one, really appreciate your maintaining GMPY, otherwise, I
might have to abandon Python.
I'll keep my eyes open for any further problems.
Thanks Gain.