21–30 of 92 posts
Earlier quoted context omitted.
It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.
> The second you need a C extension, you're pretty much out of luck. In theory, shouldn't CFFI be the foundation of the solution to that problem?
I don't know or use Python but why an implementation that is trying to be "superior" still has the GIL?
Because it's very tricky to remove. Ruby also has a GIL.
MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not.
OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)
Earlier quoted context omitted.
It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.
> The second you need a C extension, you're pretty much out of luck. In theory, shouldn't CFFI be the foundation of the solution to that problem?
Earlier quoted context omitted.
Because it's very tricky to remove. Ruby also has a GIL.
> Ruby also has a GIL. MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not. OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)
Earlier quoted context omitted.
Because it's very tricky to remove. Ruby also has a GIL.
> Ruby also has a GIL. MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not. OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)
Earlier quoted context omitted.
Because it's very tricky to remove. Ruby also has a GIL.
> Ruby also has a GIL. MRI has a GIL; major alternative implementations (JRuby, Rubinius) do not. OTOH, addressing the downsides of a GIL are not the only reasonable motivations for an alternative implementation, so there's no reason that a better-than-stock Python (or Ruby) fundamentally must remove the GIL (the current "MRI" used to be an alternative, YARV, to the old MRI, and both had GILs.)
Earlier quoted context omitted.
It makes sense to use pypy if you're writing pure python code. The second you need a C extension, you're pretty much out of luck. This kills a lot of the appeal for people in the scientific/analytics side of things, who make heavy use of legacy C and Fortran routines.
You can use these C and Fortran routines on PyPy, just not with the CPython C extension API.
https://terminal.com/tiny/shkhWWkcEV
(this lets you compare the performance on a real Linux system, without installing anything)
I created a simple Terminal instance that compares Python and PyPy in a performance test: https://terminal.com/tiny/shkhWWkcEV (this lets you compare the performance on a real Linux system, without installing anything)
Wow, this is a very exciting moment for the Python world. And they didn't even reached their funding goal for "py3k in pypy" [1]. This is dedication. I encourage everyone to fund this extremely incredible project! [1]: http://pypy.org/py3donate.html
I donated a while back, will make another donation soon.
I would like to start using this immediately but I think I'll have to wait until a 3.3 release for "yield from".