Py3k: making a py3k compat header available in installed numpy for scipy
Hi,
I have worked on porting scipy to py3k, and it is mostly working. One thing which would be useful is to install something similar to npy_3kcompat.h in numpy, so that every scipy extension could share the compat header. Is the current python 3 compatibility header usable "in the wild", or will it still significantly change (this requiring a different, more stable one) ?
cheers,
David
On Mon, Mar 29, 2010 at 4:13 AM, David Cournapeau cournape@gmail.comwrote:
Hi,
I have worked on porting scipy to py3k, and it is mostly working. One thing which would be useful is to install something similar to npy_3kcompat.h in numpy, so that every scipy extension could share the compat header. Is the current python 3 compatibility header usable "in the wild", or will it still significantly change (this requiring a different, more stable one) ?
Pauli will have to weigh in here, but I think it is pretty stable and has been for a while. The only thing I'm thinking of changing are the PyCapsule compatibility functions; instead of having them downgrade PyCapsule to PyCObject like behaviour, go the other way. Going the other way requires changes to the surrounding code to handle errors, which is why Numpy doesn't use those functions at the moment.
Chuck
ma, 2010-03-29 kello 19:13 +0900, David Cournapeau kirjoitti:
I have worked on porting scipy to py3k, and it is mostly working. One thing which would be useful is to install something similar to npy_3kcompat.h in numpy, so that every scipy extension could share the compat header. Is the current python 3 compatibility header usable "in the wild", or will it still significantly change (this requiring a different, more stable one) ?
I believe it's reasonably stable, as it contains mostly simple stuff. Something perhaps can be added later, but I don't think anything will need to be removed.
At least, I don't see what I would like to change there. The only thing I wouldn't perhaps like to have in the long run are the PyString and possibly PyInt redefinition macros. But if the header is going to be used elsewhere, we can as well freeze it now and promise not to remove or change anything existing.
Pauli
Pauli Virtanen wrote:
ma, 2010-03-29 kello 19:13 +0900, David Cournapeau kirjoitti:
I have worked on porting scipy to py3k, and it is mostly working. One thing which would be useful is to install something similar to npy_3kcompat.h in numpy, so that every scipy extension could share the compat header. Is the current python 3 compatibility header usable "in the wild", or will it still significantly change (this requiring a different, more stable one) ?
I believe it's reasonably stable, as it contains mostly simple stuff. Something perhaps can be added later, but I don't think anything will need to be removed.
Ok. If the C capsule stuff is still in flux, it may just be removed from the public header - I don't think we will need it anywhere in scipy.
At least, I don't see what I would like to change there. The only thing I wouldn't perhaps like to have in the long run are the PyString and possibly PyInt redefinition macros.
I would also prefer a new name, instead of macro redefinition, but I can do it. The header would not be part of the public API proper anyway (I will put it somewhere else than numpy/include), it should never be pulled implicitly in when including one of the .h in numpy/include.
David
2010/3/30 David Cournapeau david@silveregg.co.jp
Pauli Virtanen wrote:
[clip]
At least, I don't see what I would like to change there. The only thing I wouldn't perhaps like to have in the long run are the PyString and possibly PyInt redefinition macros.
I would also prefer a new name, instead of macro redefinition, but I can do it.
For strings, the new names are "PyBytes", "PyUnicode" and "PyUString" (unicode on Py3, bytes on Py2). One of these should be used instead of PyString in all places, but redefining the macro reduced the work in making a quick'n'dirty port of numpy.
For integers, perhaps a separate "PyInt on Py2, PyLong on Py3" type should be defined. Not sure if this would reduce work in practice.
The header would not be part of the public API proper anyway (I will put it somewhere else than numpy/include), it should never be pulled implicitly in when including one of the .h in numpy/include.
Agreed.
Pauli
participants (4)
-
Charles R Harris -
David Cournapeau -
David Cournapeau -
Pauli Virtanen