A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2016-August/145990.html below:

[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects [Python-Dev] Update on PEP 523 and adding a co_extra field to code objectsChris Angelico rosuav at gmail.com
Tue Aug 30 17:11:23 EDT 2016
On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 30.08.16 21:20, Antoine Pitrou wrote:
>>
>> On Tue, 30 Aug 2016 18:12:01 +0000
>> Brett Cannon <brett at python.org> wrote:
>>>>
>>>> Why not make it always a list?  List objects are reasonably cheap in
>>>> memory and access time... (unlike dicts)
>>>
>>>
>>> Because I would prefer to avoid any form of unnecessary performance
>>> overhead for the common case.
>>
>>
>> But the performance overhead of iterating over a 1-element list
>> is small enough (it's just an array access after a pointer dereference)
>> that it may not be larger than the overhead of the multiple tests and
>> conditional branches your example shows.
>
>
> Iterating over a tuple is even faster. It needs one pointer dereference
> less.
>
> And for memory efficiency we can use just a raw array of pointers.

Didn't all this kind of thing come up when function annotations were
discussed? Insane schemes like dictionaries with UUID keys and so on.
The decision then was YAGNI. The decision now, IMO, should be the
same. Keep things simple.

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