On Wed, Jun 4, 2014 at 3:17 PM, Nick Coghlan wrote:
> On 4 June 2014 11:17, Steven D'Aprano 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 t
On Tue, Jun 3, 2014 at 7:32 PM, Chris Angelico wrote:
> On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano
> 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-arbi
On 4 June 2014 11:17, Steven D'Aprano 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 should still avoid
On Wed, Jun 4, 2014 at 11:17 AM, Steven D'Aprano 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 actually suggesting al
I think UTF8 is the best option.
> On Jun 3, 2014, at 9:17 PM, Steven D'Aprano 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, possibly even
> m
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 interested
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 tha
On Wed, Jun 4, 2014 at 8:26 AM, Glenn Linderman wrote:
> On 6/3/2014 3:05 PM, Chris Angelico wrote:
>
> On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner
> wrote:
>
> 2014-06-03 23:38 GMT+02:00 Chris Angelico :
>
> Is this an intentional change? And if so, is it formally documented
> somewhere? I do
On 6/3/2014 3:05 PM, Chris Angelico wrote:
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner wrote:
2014-06-03 23:38 GMT+02:00 Chris Angelico :
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
On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner wrote:
> 2014-06-03 23:38 GMT+02:00 Chris Angelico :
>> 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
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
>
Hi,
2014-06-03 23:38 GMT+02:00 Chris Angelico :
> 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:
http://bugs.python.org/issue
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
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 on to it until it is manually rele
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 algorithm
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 numerical code, Numba has already pr
16 matches
Mail list logo
