RetroSearch Browse

Tue Aug 30 05:24:27 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-August/145960.html

On 8/30/2016 4:20 AM, Maciej Fijalkowski wrote:
> 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?
>
AFAIK, we can't.  The multiple tool people will have to work that out, 
or document incompatibilities between tools.

-- 
Terry Jan Reedy

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

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

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