A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2016-October/146730.html below:

[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)

[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) [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)Chris Angelico rosuav at gmail.com
Tue Oct 18 13:03:50 EDT 2016
On Wed, Oct 19, 2016 at 2:57 AM, Chris Barker - NOAA Federal
<chris.barker at noaa.gov> 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 if someone wrote an implementation with an O(n) insert dict, it
> would suck, but wouldn't it still be Python?

This exact question came up when MicroPython wanted to represent
Unicode strings internally as UTF-8. It was decided that having O(n)
indexing/slicing was acceptable, and was something that the
implementation could judge the value of. (Since uPy is designed for
smaller systems than CPython is, O(n) is less significant.)

ChrisA
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4