Hi all,
this is the classic problem of software libraries changing their
interfaces along the time and breaking the code that depends upon it.
It's not related only to Python, but to any software using libraries.
Indeed, we have the same problem in IPOL with the C libraries. We
decide that libraries are "stable" because the haven't changed the
interfaces for a long time, but we can never be sure that this will
remain true for the long term.
After all, this troubles have to do with software lifetime. All
software need to be maintained and this isn't optional, but mandatory.
If the software is not longer maintained, it's finished it's lifetime.
After that point, it might be still executed and be useful, but
without any warranty that it won't break, be incompatible with the
newer interfaces of the components it relies on, or contain bugs that
will never be fixed.
In IPOL we have already experimented this. With the new version of the
compiler, some source codes won't compile. Therefore, the only
solution if to maintain them. Even if the modifications are not
performed by the authors, but by IPOL as updates and bug fixes.
To summarize, my opinion is that Python is an excellent tool for
reproducible research and it's got no more problems with libraries
than any other system. And of course, as a language is way far more
powerful than C/C++ and allows fast prototyting. Of course, the
problem is that, as any VM-based language, it's really slow executing
operations out of the C/C++ compiled code of the libraries.
Best,
Miguel
Quoting Nicolas Limare <[email protected]>:
Hi everyone,
Here is an excerpt from a blog post by Kohnrad hinsen abour how Python
is not a perfect solution for long-term software stability, even when
only using the numerical computation Python package. The full text is
at
http://khinsen.wordpress.com/2013/11/19/python-as-a-platform-for-reproducible-research/
8<----------8<----------8<----------8<----------8<----------8<----------
Python as a platform for reproducible research
The other day I was looking at the release notes for the recently
published release 1.8 of NumPy, the library that is the basis for most
of the Scientific Python ecosystem. As usual, it contains a list of
new features and improvements, but also sections such as ?dropped
support? (for Python 2.4 and 2.5) and ?future changes?, to be
understood as ?incompatible changes that you should start to prepare
for?. [...]
From the point of view of reproducible research, all these changes are
bad news. They mean that libraries and scripts that work today will
fail to work with future NumPy releases, in ways that their users, who
are usually not the authors, cannot easily understand or fix. Actively
maintained libraries will of course be adapted to changes in NumPy,
but much, perhaps most, scientific software is not actively
maintained. A PhD student doing computational reasearch might well
publish his/her software along with the thesis, but then switch
subjects, or leave research altogether, and never look at the old code
again. There are also specialized libraries developed by small teams
who don?t have the resources to do as much maintenance as they would
like. [...]
One popular attitude is to say: Just run old Python packages with old
versions of Python, NumPy, etc. This is an option as long as the
versions you need are recent enough that they can still be built and
installed on a modern computer system. And even then, the practical
difficulties of working with parallel installation of multiple
versions of several packages are considerable [...]
--
Nicolas LIMARE
http://nicolas.limare.net/ pgp:0xFA423F4F
--
IPOL - Image Processing On Line - http://ipol.im/
contact [email protected] - http://www.ipol.im/meta/contact/
news+feeds twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
announces [email protected] - http://tools.ipol.im/mm/announce/
discussions [email protected] - http://tools.ipol.im/mm/discuss/
