Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-18 Thread Chris Angelico
On Wed, Oct 19, 2016 at 2:57 AM, Chris Barker - NOAA Federal wrote: >> The proposal is that it should be documented as being part of the >> language spec starting in 3.4 (or whatever). > > Is the performance characteristics of any object part of the language spec? > > I.e

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-18 Thread Chris Barker - NOAA Federal
> The proposal is that it should be documented as being part of the > language spec starting in 3.4 (or whatever). Is the performance characteristics of any object part of the language spec? I.e if someone wrote an implementation with an O(n) insert dict, it would suck, but wouldn't it still be

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-13 Thread Jeff Allen
On 13/10/2016 11:41, Serhiy Storchaka wrote: On 13.10.16 00:14, Nathaniel Smith wrote: AFAIK basically the only project that would be affected by this is PyPy, And MicroPython. And Jython, except that from the start its implementation of bytearray deferred resizing until the proportion

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-13 Thread Antoine Pitrou
On Wed, 12 Oct 2016 14:14:48 -0700 Nathaniel Smith wrote: > > The proposal is that it should be documented as being part of the > language spec starting in 3.4 (or whatever). So applications that > support Python 2.7 can't rely on it, sure. But if I have an > application that

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-13 Thread INADA Naoki
> AFAIK basically the only project that would be affected by this is > PyPy, and I when I asked on #pypy they said: > > njs`: I think we either plan to or already support this > > so I'm not sure why this is controversial. FYI, I had filed the feature request on PyPy issue tracker.

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-13 Thread Serhiy Storchaka
On 13.10.16 00:14, Nathaniel Smith wrote: AFAIK basically the only project that would be affected by this is PyPy, And MicroPython. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread Nathaniel Smith
On Wed, Oct 12, 2016 at 3:28 AM, INADA Naoki wrote: > When Tornado drop Python 2.7 support, they can use bytearray, and > iostream can be more simple and fast. FYI 2.7 does have bytearray. (You still have to implement the O(1) deletion part as a layer on top, like Victor

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread Nathaniel Smith
On Wed, Oct 12, 2016 at 4:55 AM, Victor Stinner wrote: > 2016-10-12 10:01 GMT+02:00 Nathaniel Smith : >> It's more complicated than that -- the right algorithm is the one that >> Antoine implemented in 3.4. >> (...) >> My point is that >> forcing everyone

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread Victor Stinner
2016-10-12 10:01 GMT+02:00 Nathaniel Smith : > It's more complicated than that -- the right algorithm is the one that > Antoine implemented in 3.4. > (...) > My point is that > forcing everyone who writes network code in Python to do that is > silly, especially given that CPython's

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread INADA Naoki
>> >> [1] My use case is parsing HTTP out of a receive buffer. If deleting >> the first k bytes of an N byte buffer is O(N), then not only does >> parsing becomes O(N^2) in the worst case, but it's the sort of O(N^2) >> that random untrusted network clients can trigger at will to DoS your >>

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread Nathaniel Smith
On Wed, Oct 12, 2016 at 12:17 AM, Serhiy Storchaka wrote: > On 12.10.16 09:31, Nathaniel Smith wrote: >> >> But amortized O(1) deletes from the front of bytearray are totally >> different, and more like amortized O(1) appends to list: there are >> important use cases[1] that

Re: [Python-Dev] O(1) deletes from the front of bytearray (was: Re: Adding bytes.frombuffer() constructor to PEP 467 (was: [Python-ideas] Adding bytes.frombuffer() constructor)

2016-10-12 Thread Serhiy Storchaka
On 12.10.16 09:31, Nathaniel Smith wrote: But amortized O(1) deletes from the front of bytearray are totally different, and more like amortized O(1) appends to list: there are important use cases[1] that simply cannot be implemented without some feature like this, and putting the implementation