Re: [Python-Dev] Should standard library modules optimize for CPython?

2014-06-03 Thread Sturla Molden
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,

Re: [Python-Dev] Should standard library modules optimize for CPython?

2014-06-03 Thread Stefan Behnel
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

Re: [Python-Dev] Should standard library modules optimize for CPython?

2014-06-03 Thread Sturla Molden
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

[Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Chris Angelico
I'm helping out with the micropython project and am finding that one of their tests fails on CPython 3.5 (fresh build from Mercurial this morning). It comes down to this: Python 3.4.1rc1 (default, May 5 2014, 14:28:34) [GCC 4.8.2] on linux Type help, copyright, credits or license for more

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Victor Stinner
Hi, 2014-06-03 23:38 GMT+02:00 Chris Angelico ros...@gmail.com: Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean much. Yes, it's intentional. See the issue for the rationale:

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Eric V. Smith
On 6/3/2014 5:38 PM, Chris Angelico wrote: I'm helping out with the micropython project and am finding that one of their tests fails on CPython 3.5 (fresh build from Mercurial this morning). It comes down to this: Python 3.4.1rc1 (default, May 5 2014, 14:28:34) [GCC 4.8.2] on linux Type

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner victor.stin...@gmail.com wrote: 2014-06-03 23:38 GMT+02:00 Chris Angelico ros...@gmail.com: Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Glenn Linderman
On 6/3/2014 3:05 PM, Chris Angelico wrote: On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner victor.stin...@gmail.com wrote: 2014-06-03 23:38 GMT+02:00 Chris Angelico ros...@gmail.com: Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 8:26 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote: On 6/3/2014 3:05 PM, Chris Angelico wrote: On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner victor.stin...@gmail.com wrote: 2014-06-03 23:38 GMT+02:00 Chris Angelico ros...@gmail.com: Is this an intentional change?

Re: [Python-Dev] Should standard library modules optimize for CPython?

2014-06-03 Thread Steven D'Aprano
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

[Python-Dev] Internal representation of strings and Micropython

2014-06-03 Thread Steven D'Aprano
There is a discussion over at MicroPython about the internal representation of Unicode strings. Micropython is aimed at embedded devices, and so minimizing memory use is important, possibly even more important than performance. (I'm not speaking on their behalf, just commenting as an

Re: [Python-Dev] Internal representation of strings and Micropython

2014-06-03 Thread Donald Stufft
I think UTF8 is the best option. On Jun 3, 2014, at 9:17 PM, Steven D'Aprano st...@pearwood.info wrote: There is a discussion over at MicroPython about the internal representation of Unicode strings. Micropython is aimed at embedded devices, and so minimizing memory use is important,

Re: [Python-Dev] Internal representation of strings and Micropython

2014-06-03 Thread Chris Angelico
On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano st...@pearwood.info wrote: * Having a build-time option to restrict all strings to ASCII-only. (I think what they mean by that is that strings will be like Python 2 strings, ASCII-plus-arbitrary-bytes, not actually ASCII.) What I was

Re: [Python-Dev] Internal representation of strings and Micropython

2014-06-03 Thread Nick Coghlan
On 4 June 2014 11:17, Steven D'Aprano st...@pearwood.info wrote: My own feeling is that O(1) string indexing operations are a quality of implementation issue, not a deal breaker to call it a Python. If string indexing iteration is still presented to the user as an array of code points, it

Re: [Python-Dev] Internal representation of strings and Micropython

2014-06-03 Thread Guido van Rossum
On Tue, Jun 3, 2014 at 7:32 PM, Chris Angelico ros...@gmail.com wrote: On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano st...@pearwood.info wrote: * Having a build-time option to restrict all strings to ASCII-only. (I think what they mean by that is that strings will be like Python 2