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

Python 3 in 2016

hynek.me

Post reply on HN
Print view View original

141–150 of 194 posts

Re: Python 3 in 2016

#141

Post by jerf »

plesner wrote: post #125
orf wrote: post #119

Earlier quoted context omitted.

It's not a bold statement, it's one made time and time again by the cPython developers. In short: 1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic. 2. cPython is the reference implementation. It's source should be as simple as possible. 3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry and finally, 4. If you want/need a JIT the…

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous". 1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't " we can't make a JIT for python" rather than " nobody can make one"? Because that's how it turned out with JS. 2. If given the choice, do you think the community would turn down a JIT to avoid making the reference…

JITs for Javascript aren't comparable; at the time, nobody had C-based extensions for Javascript. It makes it a radically simpler problem.

Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or C libraries.

Re: Python 3 in 2016

#142

Post by jerf »

ZenoArrow wrote: post #123
DasIch wrote: post #100

Earlier quoted context omitted.

STM isn't magic. Transactions can and will silently fail and you lose your parallelism. You need additional tools to identify and debug failed transactions and you'll need to learn how to structure your code to avoid failed transactions. This might turn out to be quite difficult for non-trivial Python applications. STM is exciting but I think it's important to keep in mind that it's an experiment that while promising…

> "STM isn't magic." What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.

But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in.

I remain skeptical that STM is a good fit for this problem, as I was when I first heard about this, and after their work, alas, I have to say I see little evidence to make me change my mind on that. STM is something that probably needs to be baked in from day one, possibly all the way into the language itself, not put on the side of a complicated secondary implementation of Python.

Re: Python 3 in 2016

#143

Post by esaym »

I've debated jumping from perl only dev into the python world for a couple of years now.

I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have?

Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5)?

Re: Python 3 in 2016

#144

Post by knabacks »

orf wrote: post #119
plesner wrote: post #102

Earlier quoted context omitted.

> Adding a freaking JIT to CPython is a ridiculous suggestion that will never happen for a whole load of reasons. That's a bold statement. Can you elaborate on what those reasons are?

It's not a bold statement, it's one made time and time again by the cPython developers. In short: 1. The Python language itself doesn't lend itself to being JIT compiled - it's too dynamic. 2. cPython is the reference implementation. It's source should be as simple as possible. 3. Only a subset of Python programs would benefit, and the rest would be slower/more memory hungry and finally, 4. If you want/need a JIT the…

"tldr: Want a JIT? Use PyPy."

or spend some time helping with Pyjion to add a C API to CPython for plugging in a JIT of your choice

- https://github.com/Microsoft/Pyjion

Re: Python 3 in 2016

#145

Post by ch4s3 »

esaym wrote: post #143

I've debated jumping from perl only dev into the python world for a couple of years now. I've got a list of Django youtube vids queued up on my plex server right now. But I was thinking yesterday (while in the shower of course), perl has perl6 (which may or may not take off). But what does the future of python have? Python 4,5,6? Any real innovative changes or just more of kicking the can down the road (such as perl5…

I think the best case for moving to Python is for the tooling around math and data science. If you're build other types of web apps in Perl and looking to switch to something else. I'm not sure Django is going to offer you a ton of benefit for the switching cost, IMHO.

Re: Python 3 in 2016

#146

Post by ZenoArrow »

jerf wrote: post #142
ZenoArrow wrote: post #123

Earlier quoted context omitted.

> "STM isn't magic." What difference does that make. STM will still enable the removal of the GIL. If an applications is coded that doesn't work with PyPy, that's a separate matter.

But first it has to actually work. So far, based on that page, it has suffered the same fate as all the other attempts to remove the GIL; mostly functional, but slower. And the numbers cited on that page put it on the rather slow side for single-threaded code for a GIL removal, too, which is what has always prevented previous efforts from getting merged in. I remain skeptical that STM is a good fit for this problem,…

> "So far, based on that page..."

From the page... "THIS PAGE IS OLD, THE REST IS ABOUT STMGC-C7 WHEREAS THE CURRENT DEVELOPMENT WORK IS DONE ON STMGC-C8"

This page is probably a better starting point for the current PyPy STM work:

http://pypy.org/tmdonate2.html

Re: Python 3 in 2016

#147

Post by mangecoeur »

raverbashing wrote: post #94
mangecoeur wrote: post #79

Earlier quoted context omitted.

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunche…

Yeah, I don't know While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky. I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.

It's a really complicated piece of kit, that has also been around since long before modern build systems and conventions existed. That's why you have excellent scientific packages like Anaconda or Canopy, while on linux you can also install your distro's package. Situation is also becoming easier with pre-built python wheels.

Re: Python 3 in 2016

#148

Post by jdlyga »

My main gripe about Python 3 and Python in general is that it really needs a good method of distribution. Sure there's PyInstaller, but it's not straightforward enough and there's a lot of mystery problems that take a lot of time to figure out.

Re: Python 3 in 2016

#149

Post by plesner »

jerf wrote: post #141
plesner wrote: post #125

Earlier quoted context omitted.

By "bold" I'm also referring to your use of the words "freaking" and "ridiculous". 1. This was also said about JS before people just went ahead and wrote JITs for it. Are you sure what they're saying isn't " we can't make a JIT for python" rather than " nobody can make one"? Because that's how it turned out with JS. 2. If given the choice, do you think the community would turn down a JIT to avoid making the reference…

JITs for Javascript aren't comparable; at the time, nobody had C-based extensions for Javascript. It makes it a radically simpler problem. Remove the "maintaining compatibility for C-based extensions" requirement, and you get, well, PyPy. And you also get a community split that makes 2/3 look trivial. Vast swathes of core Python code and libraries are really not "Python", but Python C-based bindings to custom code or…

Sure there were C-based extensions for JavaScript, that's how it integrates with the DOM. It makes it a little trickier but not a whole lot.

Re: Python 3 in 2016

#150

Post by StavrosK »

moistgorilla wrote: post #57

This is the ultimate HN circlejerk comment >Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart Are you kidding me? Did you just list the languages you see threads on HN about? Scala and Go I could maybe understand if you needed the performance but the rest of the choices are just bad. Especially if you are trying to start a business instead of a functional pro…

Eh, okay, Go is much easier to deploy because it's a single binary (also the same with Dart), but yeah, the rest of the comment makes no sense. Seriously? Dart? Not even Rust?
Post reply on HN