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/145957.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 objectsMaciej Fijalkowski fijall at gmail.com
Tue Aug 30 04:20:28 EDT 2016
On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Mon, Aug 29, 2016, 17:06 Terry Reedy <tjreedy at udel.edu> wrote:
>>
>> On 8/29/2016 5:38 PM, Brett Cannon wrote:
>>
>> > who objected to the new field did either for memory ("it adds another
>> > pointer to the struct that won't be typically used"), or for conceptual
>> > reasons ("the code object is immutable and you're proposing a mutable
>> > field"). The latter is addressed by not exposing the field in Python and
>>
>> Am I correct is thinking that you will also not add the new field as an
>> argument to PyCode_New?
>
>
> Correct.
>
>>
>>  > clearly stating that code should never expect the field to be filled.
>>
>> I interpret this as "The only code that should access the field should
>> be code that put something there."
>
>
> Yep, seems like a reasonable rule to follow.
>
> -brett

How do we make sure that multuple tools don't stomp on each other?
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