extended Python 2.6 compatibility

[GoogleCodeExporter]

A few minor fixes are needed for Python 2.6 compatibility.

Python 3 compatibility also needs to be investigated. I think it should be
fairly easy to support both Python 2.x and 3.x with the same codebase.

Original issue reported on code.google.com by fredrik....@gmail.com on 20 Sep 2008 at 2:28

[GoogleCodeExporter]

New things to support are:

* __format__ (http://docs.python.org/library/string.html#formatstrings)
* numbers module (http://docs.python.org/library/numbers.html)

The last one would break compatibility with Python 2.5 however.

Original comment by Vinzent.Steinberg@gmail.com on 2 Oct 2008 at 4:50

[GoogleCodeExporter]

I'm using mpmath without problems with Python 2.6 for a while now.

We could think about supporting the new stuff as mentioned above.

Original comment by Vinzent.Steinberg@gmail.com on 13 Jan 2009 at 7:44

• Changed title: extended Python 2.6 compatibility
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Looking at the Python 2.6 numbers module, it seems that there will be some 
overhead
in creating number instances. For example, creating a MyInt (derived from
numbers.Integral) is more than twice slower than creating int():

>>> class MyInt(numbers.Integral):
    __abs__ = __add__  = __and__ = __div__ = __eq__ = __floordiv__ = __invert__ =
__le__ = __long__ = __lshift__ = __lt__ = __mod__ = __mul__ = __neg__ = __or__ =
__pos__ = __pow__ = __radd__ = __rand__ = __rdiv__ = __rfloordiv__ = 
__rlshift__ =
__rmod__ = __rmul__ = __ror__ = __rpow__ = __rrshift__ = __rshift__ = 
__rtruediv__ =
__rxor__ = __truediv__ = __trunc__ = __xor__ = None
    def __init__(self, i): pass
...     
...     
>>> %timeit MyInt(1000)
1000000 loops, best of 3: 479 ns per loop
>>> %timeit int(1000)
1000000 loops, best of 3: 209 ns per loop

Original comment by pearu.peterson on 13 Jan 2009 at 9:59

[GoogleCodeExporter]

Pearu, how big speedup do you think there would be if the make_mpf function were
implemented in C?

Original comment by fredrik....@gmail.com on 13 Jan 2009 at 10:09

[GoogleCodeExporter]

I would say 2-3x for constructing instances:

>>> from sympycore import *
>>> %timeit Expr(1,2)
10000000 loops, best of 3: 183 ns per loop

>>> %timeit make_mpf((1,2,3,4))
1000000 loops, best of 3: 520 ns per loop

The implementation of mpf extension type could be
identical to Expr except mpf would hold 4 objects.

Original comment by pearu.peterson on 13 Jan 2009 at 10:28

[GoogleCodeExporter]

I implemented make_mpf in C and got no speed up for mpf calls.
For example,
%timeit mpf(1.2)
gave the same results when using extension function make_mpf or
the current python make_mpf. This means that the pure Python overhead,
that determines timeit result, is somewhere else. It is not actually
surprising as make_mpf is very simple compared to mpf.__new__.

Original comment by pearu.peterson on 15 Jan 2009 at 7:58

[GoogleCodeExporter]

Problems encountered with 2to3 (have not checked docstrings yet):

2to3 doesn't fix all imports automatically

functions with tuple parameters

mpf.__round__ method missing

"input" argument to monitor() needs renaming

cmp needs replacement in mpf_cmp and other places. A replacement for 
sorted(list,
cmp=mpf_cmp) is needed. This is the only nontrivial issue as far as I can tell.

Original comment by fredrik....@gmail.com on 18 Feb 2009 at 6:59