5 ms·

Python3 is a totally different beast nowadays from Python2. The reason is async/await. It can handle Node.js style event loop / asynchronous code very well --

Python3 is a totally different beast nowadays from Python2. The reason is async/await. It can handle Node.js style event loop / asynchronous code very well -- with uvloop, python 3.5+ is actually faster than Node.js (close to Go). https://magic.io/blog/uvloop-blazing-fast-python-networking/ https://magic.io/blog/uvloop-blazing-fast-python-networking/ IMHO: after 3.5, we are clearly in the next iteration of the language.

deleted 9y ago
[deleted]
kccqzy 9y ago
I haven't written Python in a few years, and recently when I needed to read some Python code thinking it would be familiar, I am completely unprepared to see async/await peppered everywhere. It is indeed a big change.
deleted 9y ago
[deleted]
omginternets 9y ago
>is actually faster than Node.js Uhhh I call BS until proven otherwise. Maybe the event loop is faster, but I'm willing to bet the callback code is slower.
- nicoburns 9y ago
  > Maybe the event loop is faster, but I'm willing to bet the callback code is slower. This is exactly the case, and the slowdown is pretty noticeable IMO. Still, python 3 is a whole lot better at this than python 2.
- xapata 9y ago
  Depends on many things. What task are you trying to accomplish?
  - omginternets 9y ago
    In any non-contrived example, CPython's callback code will be slower than equivalent JIT-ed code from v8. Please don't play the "it depends" card just to be smug. It lowers the level of discourse.
    - xapata 9y ago
      I ain't being smug. If I were, I might use fancy words like "discourse". But we're not playing cards here, are we? JIT-ed code can be pretty fast, but so can calls to libraries like NumPy. PyPy can also be somewhat speedy, though it hasn't had as much dev time as v8. And if you somehow find yourself breaking new ground with an algorithm no one's written a fast implementation of yet, there's always Cython. Besides, if there's any task that takes more than a negligible amount of time, I usually push it to a different process and respond immediately. The callback speed in that case is bound by the time it takes to write to a message queue or append to a database table, not the language itself.
- tuco86 9y ago
  the callback code being slower is actually a feature in my opinion.. http://stackoverflow.com/questions/18542484/why-callbacks-are-ugly http://stackoverflow.com/questions/18542484/why-callbacks-ar...
  - omginternets 9y ago
    I'm struggling to see where in the wall of text this notion is supported. This smells of mental gymnastics. I'm a huge fan of python (though I much prefer twisted to aio), but slower callbacks are unequivocally worse than faster ones, all other things being equal (which of course, they never are).
- elnygren 9y ago
  The "proof" (benchmarks, yeah, I know) is in the provided link. Feel free to shoot them down. Anyway, slower or not, writing a small async service is still easier in Node.js. You can trust that no libraries block your event loop and I'm not sure there's quite anything like Express (simplicity+popularity) for async Python just yet.
  - omginternets 9y ago
    >The "proof" (benchmarks, yeah, I know) is in the provided link. Feel free to shoot them down. I just did: those benchmarks show uvloop's performance, not python's, i.e.: they're designed to minimize time spent in callback code.
Animats 9y ago
IMHO: after 3.5, we are clearly in the next iteration of the language. After 3.4, which was a stability release. The async stuff and the beginnings of optional typing went in at 3.5. Numbering probably should have gone from 3.4 to 4.0.
- mrout 9y ago
  Python 3.5 is compatible with Python 3.4. Python 4.0 would be a silly number to use, it implies that there's incompatibility.
  - MereInterest 9y ago
    I can't find a source at the moment, but I'm pretty sure that Guido said that python 4.0 would just be the version number that comes after python 3.9. There is no intention of having another break in backwards compatibility, like there was between python 2 and 3.
    - mrout 9y ago
      He's said 3.10 more recently than that: https://twitter.com/gvanrossum/status/583346987925278720 https://twitter.com/gvanrossum/status/583346987925278720
Rapzid 9y ago
The Python async story appears to be a bit of a mess though. There was some discussion recently on this here: https://news.ycombinator.com/item?id=14240125 https://news.ycombinator.com/item?id=14240125 .
- jodrellblank 9y ago
  And this discussion less recently: https://news.ycombinator.com/item?id=12829759 https://news.ycombinator.com/item?id=12829759 "I don't understand Python 3 asyncio". Along with the comment somewhere in that thread by coleifer: "I've been a gevent user for a long time and Python's decision to "bless" twisted by adopting it's patterns was a watershed moment for me, and basically was the beginning of the end of my belief that I'd ever adopt Python 3. User jerf's comment that asyncio "more than [doubles] the complexity" is absolutely correct. Watch this video of Guido talking about tulip...or struggling to talk about tulip, rather. It's clear the dude is out of his depth and my god the recent changes to the language show that the inmates are now running the asylum... Seems like Python, in it's effort to chase the latest fads, is no longer the language I would endorse to someone new to programming. Whether you think that's a meaningful litmus test or not, the staggering amount of _crap_ that's infiltrated the language now completely flies in the face of the zen of python's statement that there should be one and preferably only one way of doing things. Fuck. I'm going to go code some lua now. https://www.youtube.com/watch?v=1coLC-MUCJc https://www.youtube.com/watch?v=1coLC-MUCJc "
  - Rapzid 9y ago
    They have managed to take the async/await pattern and make it as much fun as Perl POE.
anonymoushn 9y ago
We did this in python 2 with greenlet. It's cool that people can do it today by writing "async" in a thousand different places though!
gime_tree_fiddy 9y ago
Is it just me, or comparing Python's async/await to Go is misleading. As far as I know, even with async/await, Python is still not multicore.
- stcredzero 9y ago
  even with async/await, Python is still not multicore. Even with its channels and scheduler, Go is still not as multicore as Erlang. And I say this as an avid Go user!
  - treehau5 9y ago
    What does something not being as multicore as something else mean?
    - stcredzero 9y ago
      It would be great if the GC was also multicore. As it is, the task of splitting up your application into multiple processes to have more GC still involves too much friction.
    - gime_tree_fiddy 9y ago
      Multicore in the sense that the underlying runtime (for the lack of a better word) scales to multiple cores. Like two threads in python cannot run in parallel (like at the same time, not like second one gets scheduled if first one waits for IO or network), the way a goroutine in Golang does.
- xapata 9y ago
  Async IO is solving a different problem than you're complaining about. Python is effectively multicore in nearly every use case. The only trouble is there's no free lunch -- the multicore solution depends on which problem you're facing. So, what's the issue you're facing?

deleted 9y ago

[deleted]

kccqzy 9y ago

I haven't written Python in a few years, and recently when I needed to read some Python code thinking it would be familiar, I am completely unprepared to see async/await peppered everywhere. It is indeed a big change.

deleted 9y ago

[deleted]

omginternets 9y ago

>is actually faster than Node.js Uhhh I call BS until proven otherwise. Maybe the event loop is faster, but I'm willing to bet the callback code is slower.

nicoburns 9y ago
> Maybe the event loop is faster, but I'm willing to bet the callback code is slower. This is exactly the case, and the slowdown is pretty noticeable IMO. Still, python 3 is a whole lot better at this than python 2.
xapata 9y ago
Depends on many things. What task are you trying to accomplish?
- omginternets 9y ago
  In any non-contrived example, CPython's callback code will be slower than equivalent JIT-ed code from v8. Please don't play the "it depends" card just to be smug. It lowers the level of discourse.
  - xapata 9y ago
    I ain't being smug. If I were, I might use fancy words like "discourse". But we're not playing cards here, are we? JIT-ed code can be pretty fast, but so can calls to libraries like NumPy. PyPy can also be somewhat speedy, though it hasn't had as much dev time as v8. And if you somehow find yourself breaking new ground with an algorithm no one's written a fast implementation of yet, there's always Cython. Besides, if there's any task that takes more than a negligible amount of time, I usually push it to a different process and respond immediately. The callback speed in that case is bound by the time it takes to write to a message queue or append to a database table, not the language itself.
tuco86 9y ago
the callback code being slower is actually a feature in my opinion.. http://stackoverflow.com/questions/18542484/why-callbacks-are-ugly http://stackoverflow.com/questions/18542484/why-callbacks-ar...
- omginternets 9y ago
  I'm struggling to see where in the wall of text this notion is supported. This smells of mental gymnastics. I'm a huge fan of python (though I much prefer twisted to aio), but slower callbacks are unequivocally worse than faster ones, all other things being equal (which of course, they never are).
elnygren 9y ago
The "proof" (benchmarks, yeah, I know) is in the provided link. Feel free to shoot them down. Anyway, slower or not, writing a small async service is still easier in Node.js. You can trust that no libraries block your event loop and I'm not sure there's quite anything like Express (simplicity+popularity) for async Python just yet.
- omginternets 9y ago
  >The "proof" (benchmarks, yeah, I know) is in the provided link. Feel free to shoot them down. I just did: those benchmarks show uvloop's performance, not python's, i.e.: they're designed to minimize time spent in callback code.

Animats 9y ago

IMHO: after 3.5, we are clearly in the next iteration of the language. After 3.4, which was a stability release. The async stuff and the beginnings of optional typing went in at 3.5. Numbering probably should have gone from 3.4 to 4.0.

mrout 9y ago
Python 3.5 is compatible with Python 3.4. Python 4.0 would be a silly number to use, it implies that there's incompatibility.
- MereInterest 9y ago
  I can't find a source at the moment, but I'm pretty sure that Guido said that python 4.0 would just be the version number that comes after python 3.9. There is no intention of having another break in backwards compatibility, like there was between python 2 and 3.
  - mrout 9y ago
    He's said 3.10 more recently than that: https://twitter.com/gvanrossum/status/583346987925278720 https://twitter.com/gvanrossum/status/583346987925278720

Rapzid 9y ago

The Python async story appears to be a bit of a mess though. There was some discussion recently on this here: https://news.ycombinator.com/item?id=14240125 https://news.ycombinator.com/item?id=14240125 .

jodrellblank 9y ago
And this discussion less recently: https://news.ycombinator.com/item?id=12829759 https://news.ycombinator.com/item?id=12829759 "I don't understand Python 3 asyncio". Along with the comment somewhere in that thread by coleifer: "I've been a gevent user for a long time and Python's decision to "bless" twisted by adopting it's patterns was a watershed moment for me, and basically was the beginning of the end of my belief that I'd ever adopt Python 3. User jerf's comment that asyncio "more than [doubles] the complexity" is absolutely correct. Watch this video of Guido talking about tulip...or struggling to talk about tulip, rather. It's clear the dude is out of his depth and my god the recent changes to the language show that the inmates are now running the asylum... Seems like Python, in it's effort to chase the latest fads, is no longer the language I would endorse to someone new to programming. Whether you think that's a meaningful litmus test or not, the staggering amount of _crap_ that's infiltrated the language now completely flies in the face of the zen of python's statement that there should be one and preferably only one way of doing things. Fuck. I'm going to go code some lua now. https://www.youtube.com/watch?v=1coLC-MUCJc https://www.youtube.com/watch?v=1coLC-MUCJc "
- Rapzid 9y ago
  They have managed to take the async/await pattern and make it as much fun as Perl POE.

anonymoushn 9y ago

We did this in python 2 with greenlet. It's cool that people can do it today by writing "async" in a thousand different places though!

gime_tree_fiddy 9y ago

Is it just me, or comparing Python's async/await to Go is misleading. As far as I know, even with async/await, Python is still not multicore.

stcredzero 9y ago
even with async/await, Python is still not multicore. Even with its channels and scheduler, Go is still not as multicore as Erlang. And I say this as an avid Go user!
- treehau5 9y ago
  What does something not being as multicore as something else mean?
  - stcredzero 9y ago
    It would be great if the GC was also multicore. As it is, the task of splitting up your application into multiple processes to have more GC still involves too much friction.
  - gime_tree_fiddy 9y ago
    Multicore in the sense that the underlying runtime (for the lack of a better word) scales to multiple cores. Like two threads in python cannot run in parallel (like at the same time, not like second one gets scheduled if first one waits for IO or network), the way a goroutine in Golang does.
xapata 9y ago
Async IO is solving a different problem than you're complaining about. Python is effectively multicore in nearly every use case. The only trouble is there's no free lunch -- the multicore solution depends on which problem you're facing. So, what's the issue you're facing?