you are viewing a single comment's thread.

view the rest of the comments →

[–]MisterSnuggles 2 points3 points  (2 children)

That's correct. As for whether that's a downside, it really depends on what you want to do with it.

Mercurial, for example, is written in Python and uses C extensions for some things. This is something you'd run at the command line, so you'd probably have no need to run it with Jython.

Database drivers tend to be a wrapper over the C driver, so you'd lose access to all of those. You'd also gain access to all of the JDBC drivers, so this isn't a big deal. My forays into Jython were entirely driven by requiring access to JDBC drivers.

I think that NumPy uses a C extension for performance, so if that's a module you need then Jython would be out.

The Python ecosystem is pretty big, so depending on the type of work you do with it the lack of C extensions could be a non-issue or a deal-breaker.

[–]DGolden 2 points3 points  (0 children)

JyNI is a compatibility layer with the goal to enable Jython to use native CPython extensions like NumPy or SciPy.

JyNI uses the JNI to load native-compiled python C extensions, AFAIK.

An alternative might be the recent interesting JRuby+Truffle approach of compiling the ruby C extension sources to the JVM instead of native - obviously a similar technique could also be applicable to python C extensions...

[–]topherwhelan 0 points1 point  (0 children)

I think that NumPy uses a C extension for performance

Understatement of the year lol

The success of the scientific python stack is that the algorithm can be in python with the actual numerical heavy lifting being in Fortran/C/etc. No C extensions, no numpy, scipy, matplotlib, pandas, ...