Different Python versions

[rkillick]

I'm a CRAN package developer and I have had many people call for a Python implementation of one of my packages. I got a student to create this and we have it all working in base Python but I wanted to take advantage of the same C code that the R package uses.

This is when I ran into Python problems. I've tried several recommended ways of interfacing existing C code to Python but for each way there are Python installs that cannot download and use my package! You have to be using the "right" version of Python in order to be able to use the package. This is just my understanding so please do correct me if i'm wrong on this.

This, to me, is a huge downside of Python right now. Why should a user have to change their software to run my package? I can see an argument for forcing users to upgrade, but most Python packages that run on 2.7 don't run on 2.6 or 3.0. At least with R packages get checked and removed if authors don't update them.

[eddelbuettel]

Great points, Rebecca. For years we had one 'dual language' package on CRAN: fastcluster but that idea never got much further. I did add R(cpp) bindings to the powerful C++-based Python package annoy in the RcppAnnoy. But I am with you -- we need better 'reference' ways to design modeling approaches and implementations that can be shared. Where to start?

[rkillick]

Certainly starting with common base code such as written in C/C++ is a must. But ultimately it is down to the individual languages to be welcoming to interfacing to such code. Thankfully R is, Matlab is too, but I can't say the same for Python.

[matloff]

Yes, this is an excellent example. And it's not just Python versions, but also things like virtual environments.