[IPOL discuss] python as an addition to c++

[Ofer]

Hi,
You raise good points. I am not an expert in python (In fact, I'm moving
these days from Matlab to python), so I'll answer to the best of my,
currently limited, knowledge.

1+2. Language + Packages
Which Python are we talking about?
Both is best. If you have to choose one - go qith 3 because the updates for
2 are discontinued.

Do we have some guarantee that any code working with Python 2.N will
always work with Python 2.N+1. Is there an official policy on backward
compatibility? Can we trust a code written for SciPy to still work and give
the same results 10 years from now?
I don't know about an official policy regarding python and SciPy, but code
may always break with changes in versions, even if there is an official
policy.
It could be worthwhile to bundle the code with the versions of the
components it was developed for. Perhaps the demo system could be
configured to run the code with specific old versions it was developed for.

Unfortunately, the quasi-standard PIL package is buggy and
unmaintained. Is there an alternative?
I don't know.

3. Reuseability

So far, with only in C and C++, all the codes published in IPOL are
quite compatible, in the sense that one can build a new C or C++
software by reusing parts of these codes. One can also reuse them
with other languages, like Fortran, Java, Python, or Matlab, via the
compatibility all these languages have with the C binary interface and
types.

If we publish codes in Python, how well can they be reused by other
researchers not using Python?
There are ways to run python from other languages but I haven't
experimented with them.
I think a viable official policy is to support an input-output command line
interface which can be used by all languages. It may cause some overhead
but it will always work.

4. Expertise

I do not know if we have enough editors and reviewers capable of not only
reading and analyzing Python code, but
also able to say when a code is well written.
Matlab and python are both effective tools for fast prototyping, python
being the free choice of the two. For this reason, perhaps is would be a
language worthwhile to learn? :)

5. Safety

This sandboxing will be good for other demos as well, but
its implementation has not started yet.
I know there is sandboxing in pypy, a python interpreter.

To conclude, you raise very good points. On one hand, adding python to IPOL
seems hard for the reasons you've mentioned.
On the other hand, it is a very effective language for algorithm
development, and allowing it makes it easier for researchers to submit to
IPOL.

I've tried to answer all of your questions to the best of my knowledge.

Good luck,
Ofer




On Wed, Jun 5, 2013 at 5:42 PM, Nicolas Limare <nicolas at limare.net> wrote:

> Hi,
>
> > I was wondering whether python could be used in addition to c++.
> > It is a free language (unlike Matlab) and has math packages such as NumPy
> > and SciPy.
>
> Python is interesting and could be added to the list of languages
> accepted by IPOL. For me, its advantages over Matlab are a public
> language reference, multiple implementations, very large portability,
> useful types and constructs, rich standard library, and free software
> interpreters and modules.
>
> But I think a few points must be discussed before a decision can be
> reached. Some are quite sensible, some are less important. I'l like
> your opinion on them, and answers on the questions included would help
> close some points.
>
> 1. Language
>
> Which Python are we talking about? There are currently two major
> and incompatible versions of the language, Python2 and Python3. I have
> no idea how long the Python Foundation intends to provide
> implementations for the Python2 language, and how long this
> implementation will be available for IPOL machines.
>
> Moreover, Python is not very useful without its standard library,
> and this library has frequent updates, about once every two years. Do
> we have some guarantee that any code working with Python 2.N will
> always work with Python 2.N+1. Is there an official policy on backward
> compatibility?
>
> 2. Packages
>
> The standard library may not be enough for real image processing
> algorithm. You mentioned NumPy (the "efficient numeric array"
> package), and SciPy (the "everyting for sciences using NumPy"
> package), but how stable are they. I haven't used them for years and
> in ~2008 things were still moving. Numpy may have stabilized now, but
> what about SciPy. Can we trust a code written for SciPy to still work
> and give the same results 10 years from now? 10 years is not much,
> it's just the time from entering university to getting a PhD...
>
> Another package is essential: something to read and write
> images. Unfortunately, the quasi-standard PIL package is buggy and
> unmaintained. Is there an alternative? I know about scikit-image, but
> I am afraid it is still young. In fact, we do not need an iomage
> processing package, just a VERY RELIABLE solution to read and write
> standard image formats from a Python code.
>
> 3. Reuseability
>
> So far, with only in C and C++, all the codes published in IPOL are
> quite compatible, in the sense that one can build a new C or C++
> software by reusing parts of these codes. On ne can also reuse them
> with other languages, like Fortran, Java, Python, or Matlab, via the
> compatibility all these languages have with the C binary interface and
> types.
>
> If we publish codes in Python, how well can they be reused by other
> researchers not using Python?
>
> 4. Expertise
>
> To accept Python code, we need to update the Software Guidelines with
> details for this language, and we need to have enough editors and
> reviewers capable of not only reading and analyzing Python code, but
> also able to say when a code is well written. I do not know if we have
> them.
>
> 5. Safety
>
> With the power of the Python standard library, it is very easy to do
> vthings very annoying on the demo serve, including exploring the
> filesystem and talking over the network. This is possible in any
> language, but not as easy as in Python. So, to avoid abuses of the
> demo server, I think demos will have to be run in an isolation
> environment. This sandboxing will be good for other demos as well, but
> its implementation has not started yet.
>
> All the best,
>
> --
> Nicolas LIMARE
> http://nicolas.limare.net/                         pgp:0xFA423F4F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20130605/cef51a53/attachment.html>