Sturla Molden, 03.06.2014 22:51:
Stefan Behnel wrote:
So the
argument in favour is mostly a pragmatic one. If you can have 2-5x faster
code essentially for free, why not just go for it?
I would be easier if the GIL or Cython's use of it was redesigned. Cython
just grabs the GIL and holds
Stefan Behnel stefan...@behnel.de wrote:
Thus my proposal to compile the modules in CPython with Cython, rather than
duplicating their code or making/keeping them CPython specific. I think
reducing the urge to reimplement something in C is a good thing.
For algorithmic and numerical code,
Sturla Molden, 03.06.2014 17:13:
Stefan Behnel wrote:
Thus my proposal to compile the modules in CPython with Cython, rather than
duplicating their code or making/keeping them CPython specific. I think
reducing the urge to reimplement something in C is a good thing.
For algorithmic and
Stefan Behnel stefan...@behnel.de wrote:
So the
argument in favour is mostly a pragmatic one. If you can have 2-5x faster
code essentially for free, why not just go for it?
I would be easier if the GIL or Cython's use of it was redesigned. Cython
just grabs the GIL and holds on to it until it
On Sun, Jun 01, 2014 at 06:11:39PM +1000, Steven D'Aprano wrote:
I think I know the answer to this, but I'm going to ask it anyway...
I know that there is a general policy of trying to write code in the
standard library that does not disadvantage other implementations. How
far does that go
2014-06-01 10:11 GMT+02:00 Steven D'Aprano st...@pearwood.info:
My feeling is that the CPython standard library should be written for
CPython,
Right. PyPy, Jython and IronPython already have their own standard
library when they need a different implement.
PyPy: lib_pypy directory (lib-python
On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-06-01 10:11 GMT+02:00 Steven D'Aprano st...@pearwood.info:
My feeling is that the CPython standard library should be written for
CPython,
Right. PyPy, Jython and IronPython already have their own standard
Maciej Fijalkowski, 02.06.2014 10:48:
On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner wrote:
2014-06-01 10:11 GMT+02:00 Steven D'Aprano st...@pearwood.info:
My feeling is that the CPython standard library should be written for
CPython,
Right. PyPy, Jython and IronPython already have their
I think I know the answer to this, but I'm going to ask it anyway...
I know that there is a general policy of trying to write code in the
standard library that does not disadvantage other implementations. How
far does that go the other way? Should the standard library accept
slower code
Steven D'Aprano, 01.06.2014 10:11:
Briefly, I have a choice of algorithm for the median function in the
statistics module. If I target CPython, I will use a naive but simple
O(N log N) implementation based on sorting the list and returning the
middle item. (That's what the module currently
On 1 Jun 2014 18:13, Steven D'Aprano st...@pearwood.info wrote:
My feeling is that the CPython standard library should be written for
CPython, that is, it should stick to the current naive implementation of
median, and if PyPy wants to speed the function up, they can provide
their own version
Le 01/06/2014 10:11, Steven D'Aprano a écrit :
My feeling is that the CPython standard library should be written for
CPython, that is, it should stick to the current naive implementation of
median, and if PyPy wants to speed the function up, they can provide
their own version of the module. I
On Jun 1, 2014, at 9:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Le 01/06/2014 10:11, Steven D'Aprano a écrit :
My feeling is that the CPython standard library should be written for
CPython, that is, it should stick to the current naive implementation of
median, and if PyPy wants to
13 matches
Mail list logo
