Hi,
On Sat, Sep 21, 2013 at 8:54 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote: [...]
weave ````` This is the only module that was not ported to Python 3. Effectively it's deprecated (not recommended to use for new code). In the future it should be removed from scipy (can be made into a separate module).
Let me just mention that I am worried about the removal of weave: a substantial amount of code developed in our group over the years uses weave. Porting this to cython seems not trivial, in particular, because many of the original authors (diploma students, PhD students, ...) have left academia by now. Well, as porting weave to Python 3 is way out of my capabilities, this is just a comment in the hope that someone could give this a try (if at some point testing would be needed, I could try to help, of course). Best, Arnd
On Wed, Sep 25, 2013 at 5:18 PM, Arnd Baecker <arnd.baecker@web.de> wrote:
Hi,
On Sat, Sep 21, 2013 at 8:54 PM, Ralf Gommers <ralf.gommers@gmail.com>
wrote:
[...]
weave ````` This is the only module that was not ported to Python 3. Effectively
it's
deprecated (not recommended to use for new code). In the future it should be removed from scipy (can be made into a separate module).
Let me just mention that I am worried about the removal of weave: a substantial amount of code developed in our group over the years uses weave. Porting this to cython seems not trivial, in particular, because many of the original authors (diploma students, PhD students, ...) have left academia by now.
Well, as porting weave to Python 3 is way out of my capabilities, this is just a comment in the hope that someone could give this a try (if at some point testing would be needed, I could try to help, of course).
Would it be within your capabilities to volunteer to maintain it as a separate package outside of scipy? -- Robert Kern
I can at least describe our case of porting away from weave. In order to improve portability and stability when releasing our software, we ported our inline C weave code to normal Python C modules. This only required, at least in our case, separating out the C portions of our code into their own functions and adding some short boilerplate C code for dealing with parameters and output. There was no need to modify the already-written C code beyond placing it into separate files. If I understand the mechanisms behind weave correctly, this is essentially what weave.inline does automatically. Perhaps documentation of this porting method, maybe in the SciPy tutorial to replace the weave section, might be useful. This of course would not work for porting code that uses weave.blitz, but blitz involves such small expressions that porting to pure C wouldn't necessarily seem too tricky (so long as blitz arrays aren't being used). Regards, Constantine On Wed, Sep 25, 2013 at 9:18 AM, Arnd Baecker <arnd.baecker@web.de> wrote:
Hi,
On Sat, Sep 21, 2013 at 8:54 PM, Ralf Gommers <ralf.gommers@gmail.com>
wrote:
[...]
weave
````` This is the only module that was not ported to Python 3. Effectively it's deprecated (not recommended to use for new code). In the future it should be removed from scipy (can be made into a separate module).
Let me just mention that I am worried about the removal of weave: a substantial amount of code developed in our group over the years uses weave. Porting this to cython seems not trivial, in particular, because many of the original authors (diploma students, PhD students, ...) have left academia by now.
Well, as porting weave to Python 3 is way out of my capabilities, this is just a comment in the hope that someone could give this a try (if at some point testing would be needed, I could try to help, of course).
Best, Arnd
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi, 25.09.2013 19:18, Arnd Baecker kirjoitti: [clip]
Let me just mention that I am worried about the removal of weave: a substantial amount of code developed in our group over the years uses weave. Porting this to cython seems not trivial, in particular, because many of the original authors (diploma students, PhD students, ...) have left academia by now.
Note that weave is not going to vanish even if it happens that nobody steps up and it's removed from Scipy. Rather, it will simply be split out to a separate Python package --- which however will likely not receive further attention from our side. In your own code, it should then be enough to change import scipy.weave to something like import weave and make sure the `weave` package is installed locally. -- Pauli Virtanen
Hi, thanks for all the replies! It seems that Constantines approach to transforming weave code into normal Python C modules would apply also to our situtation (only weave.inline being used). Even if the current weave will be split out from scipy and can be easily used as Pauli pointed out, at some point one needs to make the transition to Python 3. If weave is deprecated (even if someone makes the effort to port it to Python 3), in the long run it seems to make more sense to convert the code to either modules or cython. Of course I do understand the reasons to deprecate weave. Personally, I only use cython for new code and Numba looks extremely promising. So surely the question is, whether porting weave is worth the needed effort (as I said, I have no idea how much work is necessary for this). Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue what this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a python 3 port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used? Best, Arnd
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Of course I do understand the reasons to deprecate weave. Personally, I only use cython for new code and Numba looks extremely promising. So surely the question is, whether porting weave is worth the needed effort (as I said, I have no idea how much work is necessary for this).
If you drop support for some features that relate to stuff in which the C API changed a lot in Python 3, such as passing in file pointers, porting weave to Python 3 is probably doable without too much trouble. Getting the basics working in my estimation is not hard, the trouble is in the corners. -- Pauli Virtanen
On Thu, Sep 26, 2013 at 2:05 PM, Pauli Virtanen <pav@iki.fi> wrote:
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Of course I do understand the reasons to deprecate weave. Personally, I only use cython for new code and Numba looks extremely promising. So surely the question is, whether porting weave is worth the needed effort (as I said, I have no idea how much work is necessary for this).
If you drop support for some features that relate to stuff in which the C API changed a lot in Python 3, such as passing in file pointers, porting weave to Python 3 is probably doable without too much trouble.
Getting the basics working in my estimation is not hard, the trouble is in the corners.
How much work is porting to python 3 when using weave? If someone is porting to python 3 already, would porting away from weave at the same time add very much additional work?
Todd <toddrjen <at> gmail.com> writes: [clip]
How much work is porting to python 3 when using weave? If someone is porting to python 3 already, would porting away from weave at the same time add very much additional work?
Depends. I would expect little to no changes required in most cases. -- Pauli Virtanen
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue what this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a python 3 port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used?
Also, let's say that if someone with personal interest in keeping it working addresses the issues within the next few years, then the pressure of splitting it out decreases quite a lot. In the big picture, weave is relatively "mature" code base, and keeping it working is probably not too big apart from the Py3 port. -- Pauli Virtanen
Hi, Pauli Virtanen <pav <at> iki.fi> writes:
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue what this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a python 3 port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used?
Also, let's say that if someone with personal interest in keeping it working addresses the issues within the next few years, then the pressure of splitting it out decreases quite a lot.
In the big picture, weave is relatively "mature" code base, and keeping it working is probably not too big apart from the Py3 port.
I found this two-month-old thread while checking (again) for any solutions regarding weave.inline and python 3.x compatibility. Our lab is another example of what Arnd was talking about: I'm a graduate student close to the end of my Ph.D, and I built many parts of our code using weave.inline. Now I'm looking for ways to make my code compatible with future generation. And weave.inline is the only package which holds us at python 2.x. Did someone start porting weave.inline since this thread ended on Sep 26? What are the chances someone will do this in the nearest future? Thanks, Max
On Thu, Nov 28, 2013 at 10:03 PM, Maxim Imakaev <imakaev@mit.edu> wrote:
Hi,
Pauli Virtanen <pav <at> iki.fi> writes:
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue what this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a python
3
port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used?
Also, let's say that if someone with personal interest in keeping it working addresses the issues within the next few years, then the pressure of splitting it out decreases quite a lot.
In the big picture, weave is relatively "mature" code base, and keeping it working is probably not too big apart from the Py3 port.
I found this two-month-old thread while checking (again) for any solutions regarding weave.inline and python 3.x compatibility.
Our lab is another example of what Arnd was talking about: I'm a graduate student close to the end of my Ph.D, and I built many parts of our code using weave.inline. Now I'm looking for ways to make my code compatible with future generation. And weave.inline is the only package which holds us at python 2.x.
Did someone start porting weave.inline since this thread ended on Sep 26? What are the chances someone will do this in the nearest future?
They were small, it looks like. I spent some time this weekend on packaging weave as a separate package: https://github.com/rgommers/weave. My proposal is to: - release this under the name "Weave". - put it on PyPi and at https://github.com/scipy/weave - deprecate scipy.weave for 0.15.0 - add an extra envvar to trigger running the scipy.weave tests marked as slow. don't run those by default when executing ``scipy.test('full')``. this will fix the timeout issues we currently have on TravisCi. - remove scipy.weave for 0.17.0 or 1.0.0, whichever comes first. Thoughts? Ralf
On Mon, Apr 28, 2014 at 12:56 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Thu, Nov 28, 2013 at 10:03 PM, Maxim Imakaev <imakaev@mit.edu> wrote:
Hi,
Pauli Virtanen <pav <at> iki.fi> writes:
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue
this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a
what python 3
port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used?
Also, let's say that if someone with personal interest in keeping it working addresses the issues within the next few years, then the pressure of splitting it out decreases quite a lot.
In the big picture, weave is relatively "mature" code base, and keeping it working is probably not too big apart from the Py3 port.
I found this two-month-old thread while checking (again) for any solutions regarding weave.inline and python 3.x compatibility.
Our lab is another example of what Arnd was talking about: I'm a graduate student close to the end of my Ph.D, and I built many parts of our code using weave.inline. Now I'm looking for ways to make my code compatible with future generation. And weave.inline is the only package which holds us at python 2.x.
Did someone start porting weave.inline since this thread ended on Sep 26? What are the chances someone will do this in the nearest future?
They were small, it looks like.
I spent some time this weekend on packaging weave as a separate package: https://github.com/rgommers/weave. My proposal is to: - release this under the name "Weave". - put it on PyPi and at https://github.com/scipy/weave - deprecate scipy.weave for 0.15.0 - add an extra envvar to trigger running the scipy.weave tests marked as slow. don't run those by default when executing ``scipy.test('full')``. this will fix the timeout issues we currently have on TravisCi. - remove scipy.weave for 0.17.0 or 1.0.0, whichever comes first.
Thoughts?
+1 Warren
Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, Apr 28, 2014 at 5:56 PM, Ralf Gommers <ralf.gommers@gmail.com>wrote:
On Thu, Nov 28, 2013 at 10:03 PM, Maxim Imakaev <imakaev@mit.edu> wrote:
Hi,
Pauli Virtanen <pav <at> iki.fi> writes:
Arnd Baecker <arnd.baecker <at> web.de> writes: [clip]
Finally, to answer Roberts question whether I could volunteer to maintain weave as a separate package: not sure - maybe with some helping hands (currently I have no clue
this would require) it might be possible. The important aspect is the long term perspective: How many people would be interested in this and maybe even in a
what python 3
port and actively use weave also for new code, or is the general impression, that the more modern tools (cython, ...) should be used?
Also, let's say that if someone with personal interest in keeping it working addresses the issues within the next few years, then the pressure of splitting it out decreases quite a lot.
In the big picture, weave is relatively "mature" code base, and keeping it working is probably not too big apart from the Py3 port.
I found this two-month-old thread while checking (again) for any solutions regarding weave.inline and python 3.x compatibility.
Our lab is another example of what Arnd was talking about: I'm a graduate student close to the end of my Ph.D, and I built many parts of our code using weave.inline. Now I'm looking for ways to make my code compatible with future generation. And weave.inline is the only package which holds us at python 2.x.
Did someone start porting weave.inline since this thread ended on Sep 26? What are the chances someone will do this in the nearest future?
They were small, it looks like.
I spent some time this weekend on packaging weave as a separate package: https://github.com/rgommers/weave. My proposal is to: - release this under the name "Weave". - put it on PyPi and at https://github.com/scipy/weave - deprecate scipy.weave for 0.15.0 - add an extra envvar to trigger running the scipy.weave tests marked as slow. don't run those by default when executing ``scipy.test('full')``. this will fix the timeout issues we currently have on TravisCi. - remove scipy.weave for 0.17.0 or 1.0.0, whichever comes first.
Thoughts?
In favour as well. David
Ralf
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (9)
-
Arnd Baecker -
Constantine Evans -
David Cournapeau -
Maxim Imakaev -
Pauli Virtanen -
Ralf Gommers -
Robert Kern -
Todd -
Warren Weckesser