<div dir="ltr"><div>Hi,<br>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.<br><br>1+2. Language + Packages<br> Which Python are we talking about? <br></div>Both is best. If you have to choose one - go qith 3 because the updates for 2 are discontinued.<br><div><div> <br>Do we have some guarantee that any code working with Python 2.N will<br> always work with Python 2.N+1. Is there an official policy on backward<br> compatibility? Can we trust a code written for SciPy to still work and give the same results <span tabindex="0" class=""><span class="">10 years from now</span></span>? </div><div>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.<br> 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. <br></div><div> </div><div> <br>Unfortunately, the quasi-standard PIL package is buggy and<br> unmaintained. Is there an alternative?<br></div><div>I don't know.<br></div><div> <br> 3. Reuseability<br> <br> So far, with only in C and C++, all the codes published in IPOL are<br> quite compatible, in the sense that one can build a new C or C++<br> software by reusing parts of these codes. One can also reuse them<br> with other languages, like Fortran, Java, Python, or Matlab, via the<br> compatibility all these languages have with the C binary interface and<br> types.<br> <br> If we publish codes in Python, how well can they be reused by other<br> researchers not using Python?<br></div><div>There are ways to run python from other languages but I haven't experimented with them.<br></div><div>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.<br> </div><div> <br> 4. Expertise<br> <br> I do not know if we have enough editors and reviewers capable of not only reading and analyzing Python code, but<br> also able to say when a code is well written.<br></div><div>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? :)<br> </div><div> <br> 5. Safety<br> <br>This sandboxing will be good for other demos as well, but<br> its implementation has not started yet.<br> </div></div><div class="gmail_extra">I know there is sandboxing in pypy, a python interpreter.<br><br></div><div class="gmail_extra">To conclude, you raise very good points. On one hand, adding python to IPOL seems hard for the reasons you've mentioned.<br> </div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">I've tried to answer all of your questions to the best of my knowledge.<br> <br>Good luck,<br></div><div class="gmail_extra">Ofer<br></div><div class="gmail_extra"><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 5:42 PM, Nicolas Limare <span dir="ltr"><<a href="mailto:nicolas@limare.net" target="_blank">nicolas@limare.net</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">Hi,<br> <br> > I was wondering whether python could be used in addition to c++.<br> > It is a free language (unlike Matlab) and has math packages such as NumPy<br> > and SciPy.<br> <br> </div></div>Python is interesting and could be added to the list of languages<br> accepted by IPOL. For me, its advantages over Matlab are a public<br> language reference, multiple implementations, very large portability,<br> useful types and constructs, rich standard library, and free software<br> interpreters and modules.<br> <br> But I think a few points must be discussed before a decision can be<br> reached. Some are quite sensible, some are less important. I'l like<br> your opinion on them, and answers on the questions included would help<br> close some points.<br> <br> 1. Language<br> <br> Which Python are we talking about? There are currently two major<br> and incompatible versions of the language, Python2 and Python3. I have<br> no idea how long the Python Foundation intends to provide<br> implementations for the Python2 language, and how long this<br> implementation will be available for IPOL machines.<br> <br> Moreover, Python is not very useful without its standard library,<br> and this library has frequent updates, about once every two years. Do<br> we have some guarantee that any code working with Python 2.N will<br> always work with Python 2.N+1. Is there an official policy on backward<br> compatibility?<br> <br> 2. Packages<br> <br> The standard library may not be enough for real image processing<br> algorithm. You mentioned NumPy (the "efficient numeric array"<br> package), and SciPy (the "everyting for sciences using NumPy"<br> package), but how stable are they. I haven't used them for years and<br> in ~2008 things were still moving. Numpy may have stabilized now, but<br> what about SciPy. Can we trust a code written for SciPy to still work<br> and give the same results 10 years from now? 10 years is not much,<br> it's just the time from entering university to getting a PhD...<br> <br> Another package is essential: something to read and write<br> images. Unfortunately, the quasi-standard PIL package is buggy and<br> unmaintained. Is there an alternative? I know about scikit-image, but<br> I am afraid it is still young. In fact, we do not need an iomage<br> processing package, just a VERY RELIABLE solution to read and write<br> standard image formats from a Python code.<br> <br> 3. Reuseability<br> <br> So far, with only in C and C++, all the codes published in IPOL are<br> quite compatible, in the sense that one can build a new C or C++<br> software by reusing parts of these codes. On ne can also reuse them<br> with other languages, like Fortran, Java, Python, or Matlab, via the<br> compatibility all these languages have with the C binary interface and<br> types.<br> <br> If we publish codes in Python, how well can they be reused by other<br> researchers not using Python?<br> <br> 4. Expertise<br> <br> To accept Python code, we need to update the Software Guidelines with<br> details for this language, and we need to have enough editors and<br> reviewers capable of not only reading and analyzing Python code, but<br> also able to say when a code is well written. I do not know if we have<br> them.<br> <br> 5. Safety<br> <br> With the power of the Python standard library, it is very easy to do<br> vthings very annoying on the demo serve, including exploring the<br> filesystem and talking over the network. This is possible in any<br> language, but not as easy as in Python. So, to avoid abuses of the<br> demo server, I think demos will have to be run in an isolation<br> environment. This sandboxing will be good for other demos as well, but<br> its implementation has not started yet.<br> <br> All the best,<br> <span class=""><font color="#888888"><br> --<br> Nicolas LIMARE<br> <a href="http://nicolas.limare.net/" target="_blank">http://nicolas.limare.net/</a> pgp:0xFA423F4F<br> </font></span></blockquote></div><br></div></div>