Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pythran: Crossing the Python Frontier [pdf]

computer.org

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Pythran: Crossing the Python Frontier [pdf]

#31

Post by montalbano »

knlji wrote: post #24
joshsyn wrote: post #7

Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh

Maybe. It's currently just a safer bet to learn and use Python. Easier to get a job after you fail getting your next grant. I have so far seen zero Julia job ads. Hell, I see more e.g. Haskell and Fortran job ads than Julia.

or learn both and have the convenience+speed of Julia for scientific work? Speaking from my experience here as a bioengineering PhD student. The Julia learning curve is low enough for an experienced Python/scipy user to switch over fairly swiftly.

edit: also, I would be very surprised if you had seen any Julia job ads, v1.0 hasn't been released yet. Doesn't mean it can't make my scientific life easier in the meanwhile.

Re: Pythran: Crossing the Python Frontier [pdf]

#32

Post by dagw »

ianamartin wrote: post #27
cbcoutinho wrote: post #15

Earlier quoted context omitted.

Scientific work should strive to be functional by definition (identical input == identical output), so I could see why a programing language should reflect that.

That's a pretty broad statement. And it's a goal that a lot of scientific work simply doesn't allow for. Any stochastic process will have variability for a given set of inputs. I think there are more fields within the umbrella of Science where purely functional programming isn't an achievable ideal--let alone a desirable one--than there are where this is a good fit. You can make the argument that all programming shou…

Any stochastic process will have variability for a given set of inputs

If you're modelling stochastic processes it's important to be able to set the random seed you can reproduce your simulations. So for a given set of inputs you should get the same output, given that one of the inputs is your seed.

Re: Pythran: Crossing the Python Frontier [pdf]

#33

Post by joshuamorton »

ChrisRackauckas wrote: post #22
hprotagonist wrote: post #18

Earlier quoted context omitted.

just as soon as someone who knows C/C++ ports numpy and scipy and pandas. and gensim and nltk and sounddevice. and tensorflow and scikit-learn and keras....

That was done quite awhile ago? Julia now has a bunch of unique stuff Python doesn't have because the basics are already done.

Such as?

Re: Pythran: Crossing the Python Frontier [pdf]

#35

Post by ssivark »

hprotagonist wrote: post #18
joshsyn wrote: post #7

Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh

just as soon as someone who knows C/C++ ports numpy and scipy and pandas. and gensim and nltk and sounddevice. and tensorflow and scikit-learn and keras....

Julia libraries don’t need to be written in C/C++ for speed; Julia is good enough :-) This was one of Julia’s fundamental goals.

Re: Pythran: Crossing the Python Frontier [pdf]

#37

Post by xapata »

Arkanosis wrote: post #29
HerrMonnezza wrote: post #16

Does anyone know how this compares to existing Python-to-C++ transpilers like Cython or Shedskin?

Cython is a bit different from CPython / Pythran / Shedskin in that you need to learn the Cython language, which is a Python-ish programming language, but not Python. Shedskin and Pythran look somewhat similar to me (disclaimer: I've contributed quite a bit to Shedskin but have never used Pythran so far), except in Shedskin you don't even need annotations like with Pythran (the downside being the finer control you ha…

> Python-ish

It's a little more Python-like than just -ish.

Re: Pythran: Crossing the Python Frontier [pdf]

#38

Post by AnimalMuppet »

Off topic, but this seems like as good a place as any to ask: It's my impression that numpy is really good. Is it as good as Fortran? That is, if I have a large, sparse, complex matrix, Fortran will have an efficient solver for it that will also be numerically stable, and will have four decades of use to find any weaknesses. Is numpy equivalent (except for the four decades part)? Is it close? Or does it just cover the basic cases well, and for the specializations you're on your own?

Re: Pythran: Crossing the Python Frontier [pdf]

#40

Post by HerrMonnezza »

Arkanosis wrote: post #29
HerrMonnezza wrote: post #16

Does anyone know how this compares to existing Python-to-C++ transpilers like Cython or Shedskin?

Cython is a bit different from CPython / Pythran / Shedskin in that you need to learn the Cython language, which is a Python-ish programming language, but not Python. Shedskin and Pythran look somewhat similar to me (disclaimer: I've contributed quite a bit to Shedskin but have never used Pythran so far), except in Shedskin you don't even need annotations like with Pythran (the downside being the finer control you ha…

Thanks for your answer!

However, I think this might be a bit misleading for people who do not know Cython:

> the Cython language, which is a Python-ish programming language, but not Python.

Actually, http://cython.org/ states:

""" The Cython language is a superset of the Python language that additionally supports calling C functions and declaring C types on variables and class attributes. """

In my experience with Cython, this description is quite accurate: code can be annotated with C types and then compiled to efficient C code by Cython; if you don't use annotations, then you can still compile to C code but with less speed advantage.

I haven't used Cython since version 0.17 (quite old now) but IIRC the major drawback was that it was mainly targeting writing extension modules for Python; it could generate self-standing executables, but would still require a Python interpreter to be embedded in any compiled code (that was the price for seamless interoperability between Cython/compiled code and "pure Python" code).

Post reply on HN