Howdy, today's exercise with f2py left some lessons learned, mostly thanks to Robert's excellent help, for which I'm grateful. I'd like to recap here what we have, mostly to decide what changes (if any) should go into numpy to make the experience less "interesting" for future users: - Remove the f2py_options flag from numpy.distutils.extension.Extension? If so, do options like '--debug_capi' get correctly passed via setup.cfg? This flag is potentially very confusing, because only *some* f2py options get actually set this way, while others need to be set in calls to config_fc. - How to properly set the compiler options in a setup.py file? Robert suggested the setup.cfg file, but this doesn't get picked up unless config_fc is explicitly called by the user: ./setup.py config_fc etc... This is perhaps a distutils problem, but I don't know if we can solve it more cleanly. It seems to me that it should be possible to provide a setup.py file that can be used simply as ./setup.py install (with the necessary setup.cfg file sitting next to it). I'm thinking here of what we need to do when showing how 'easy' these tools are for scientists migrating from matlab, for example. Obscure, special purpose incantations tend to tarnish our message of ease :) - Should the 'instead' word be removed from the f2py docs regarding the use of .pyf sources? It appears to be a mistake, which threw at least me for a loop for a while. - Why does f2py in the source tree have *both* a doc/ and a docs/ directory? It's really confusing to see this. f2py happens to be a very important tool, not just because scipy couldn't build without it, but also to position python as a credible integration language for scientific work. So I hope we can make using it as easy and robust as is technically feasible. Cheers, f
Hi all, I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment? If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused. Cheers, f On Fri, Jul 18, 2008 at 9:00 PM, Fernando Perez <fperez.net@gmail.com> wrote:
Howdy,
today's exercise with f2py left some lessons learned, mostly thanks to Robert's excellent help, for which I'm grateful.
I'd like to recap here what we have, mostly to decide what changes (if any) should go into numpy to make the experience less "interesting" for future users:
- Remove the f2py_options flag from numpy.distutils.extension.Extension? If so, do options like '--debug_capi' get correctly passed via setup.cfg?
This flag is potentially very confusing, because only *some* f2py options get actually set this way, while others need to be set in calls to config_fc.
- How to properly set the compiler options in a setup.py file? Robert suggested the setup.cfg file, but this doesn't get picked up unless config_fc is explicitly called by the user:
./setup.py config_fc etc...
This is perhaps a distutils problem, but I don't know if we can solve it more cleanly. It seems to me that it should be possible to provide a setup.py file that can be used simply as
./setup.py install
(with the necessary setup.cfg file sitting next to it). I'm thinking here of what we need to do when showing how 'easy' these tools are for scientists migrating from matlab, for example. Obscure, special purpose incantations tend to tarnish our message of ease :)
- Should the 'instead' word be removed from the f2py docs regarding the use of .pyf sources? It appears to be a mistake, which threw at least me for a loop for a while.
- Why does f2py in the source tree have *both* a doc/ and a docs/ directory? It's really confusing to see this.
f2py happens to be a very important tool, not just because scipy couldn't build without it, but also to position python as a credible integration language for scientific work. So I hope we can make using it as easy and robust as is technically feasible.
Cheers,
f
2008/7/23 Fernando Perez <fperez.net@gmail.com>:
I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment?
If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused.
As far as I understand, Pearu is busy developing g3 of f2py. Does that mean that f2py in NumPy is effectively unmaintained? I hope not. I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it. Cheers Stéfan
On Wed, Jul 23, 2008 at 17:18, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2008/7/23 Fernando Perez <fperez.net@gmail.com>:
I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment?
If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused.
As far as I understand, Pearu is busy developing g3 of f2py.
I think he's been busy doing other things for the past few months, at least.
Does that mean that f2py in NumPy is effectively unmaintained? I hope not.
We'll try to fix bugs as they come up, but this is, as always, subject to the vagaries of free time. It is very unlikely to grow new features. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Howdy, On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2008/7/23 Fernando Perez <fperez.net@gmail.com>:
I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it.
Well, I think my 'recap' message earlier in this thread points to a few issues that can probably be addressed quickly (the 'instead' error in the help, the doc/docs dichotomy needs to be cleaned up so a single documentation directory exists, etc). I'm also attaching a set of very old notes I wrote years ago on f2py that you are free to use in any way you see fit. I gave them a 2-minute rst treatment but didn't edit them at all, so they may be somewhat outdated (I originally wrote them in 2002 I think). If Pearu has moved to greener pastures, f2py could certainly use an adoptive parent. It happens to be a really important piece of infrastructure and for the most part it works fairly well. I think a litlte bit of cleanup/doc integration with the rest of numpy is probably all that's needed, so it could be a good project for someone to adopt that would potentially be low-demand yet quite useful. Cheers, f
Hi, Few months ago I joined a group of system biologist and I have been busy with new projects (mostly C++ based). So I haven't had a chance to work on f2py. However, I am still around to fix f2py bugs and maintain/support numpy.f2py (as long as current numpy maintainers allow it..) -- as a rule these tasks do not take much of my time. I have also rewritten f2py users guide for numpy.f2py and submitted a paper on f2py. I'll make them available when I get some more time.. Regards, still-kicking-yoursly, Pearu On Thu, July 24, 2008 1:46 am, Fernando Perez wrote:
Howdy,
On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
2008/7/23 Fernando Perez <fperez.net@gmail.com>:
I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it.
Well, I think my 'recap' message earlier in this thread points to a few issues that can probably be addressed quickly (the 'instead' error in the help, the doc/docs dichotomy needs to be cleaned up so a single documentation directory exists, etc). I'm also attaching a set of very old notes I wrote years ago on f2py that you are free to use in any way you see fit. I gave them a 2-minute rst treatment but didn't edit them at all, so they may be somewhat outdated (I originally wrote them in 2002 I think).
If Pearu has moved to greener pastures, f2py could certainly use an adoptive parent. It happens to be a really important piece of infrastructure and for the most part it works fairly well. I think a litlte bit of cleanup/doc integration with the rest of numpy is probably all that's needed, so it could be a good project for someone to adopt that would potentially be low-demand yet quite useful.
Cheers,
f _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
Fernando Perez -
Pearu Peterson -
Robert Kern -
Stéfan van der Walt