[Numpy-discussion] Numpy on Python3

[Charles R Harris]

On Sun, Nov 22, 2009 at 10:35 PM, Pauli Virtanen <pav at iki.fi> wrote:

> http://github.com/pv/numpy-work/tree/py3k
>
> $ mkdir -p $PWD/dist/lib/python3.1/site-packages
> $ python3 setup.py install --prefix=$PWD/dist
> $ cd $PWD/dist/lib/python3.1/site-packages && python3
> Python 3.1.1+ (r311:74480, Oct 11 2009, 20:22:16)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> XXX: 3K: numpy.random is disabled for now, uses PyString_*
> XXX: 3K: numpy.ma is disabled for now -- some issues
> >>> numpy.array([1., 2, 3, 4])
> array([ 1.,  2.,  3.,  4.])
> >>> _ + 10
> array([ 11.,  12.,  13.,  14.])
> >>> numpy.ones((4,), dtype=complex)/4
> array([ 0.25+0.j,  0.25+0.j,  0.25+0.j,  0.25+0.j])
> >>> numpy.array([object(), object()])
> array([<object object at 0xb7778810>, <object object at 0xb7778d90>],
> dtype=b'object')
>
>    ***
>
> Things were fairly straightforward this far, just many tiny changes.
> What's left is then sorting out the bigger problems :)
>
> This is still far from being complete:
>
> - Most use of PyString_* needs auditing (note e.g. the b'object' in the
>  dtype print above...).
>
>  I simply added convenience wrappers for PyString -> PyBytes,
>  but this is not the correct choice at all points.
>
> - Also, should dtype='S' be Bytes or Unicode? I chose Bytes for now.
>
> - Whether to inherit Numpy ints from PyLong_* needs some thinking,
>  as they are quite different objects. Now, I dropped the inheritance,
>  but I wonder if this will break something.
>
>
Maybe. But it was always a hassle because it behaved differently than the
other integer types. Now onto float ;)


> - PyFile_AsFile has disappeared, and AsFileDescriptor+fdopen doesn't
>  seem to cut it -- don't know exactly what's wrong here.
>
> - Integer -> String formatting does not seem to work
>
> - Larger-than-long-long Python ints probably cause problems
>
>
We used a python call which would raise an error if the number was too
large. If that call is still valid, things should work.


> - The new buffer interface needs to be implemented -- currently there
>  are just error-raising stubs.
>
>  I remember Dag was working on this a bit: how far did it go?
>
> - Relative imports + 2to3 is a bit of a pain. A pity we can't have
>  them in the mainline code because of python2.4.
>
> - I didn't check for semantic changes in tp_* interface functions.
>  This we need still to do.
>
>
I left some notes in the src folder. If you discover anything new put it in
there.


> - And probably many other issues lurking.
>
>
We do need to look at the initialization of the type math stuff in the
ufuncobject module. Yeah, its a bit of a circular dependency, one reason it
would be nice to have ufuncs operate on buffer objects instead of ndarrays
would be to break the mutual dependence.


>
> Also, I didn't yet try checking how far the test suite passes on
> Python3. (It still passes completely on Python2, so at least I didn't
> break that part.)
>
> It might be nice to have this merged in at some point after 1.4.0 (after
> the most obvious glaring bugs have been fixed), so that we could perhaps
> start aiming for Python3 compatibility in Numpy 1.5.0.
>
>
If you want to see real suffering, look at the programmer notes in the
hacked CRU files.  Some poor sucker was stuck with fixing up the g*dawful
code while also needing to determine what data was in undocumented binary
files, some with the same names but containing different data. Folks, don't
let that happen to you. The conversion to Py3k is going to be a breeze by
comparison.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091122/a3408ef6/attachment.html>