On Tue, 30 Aug 2016 at 01:20 Maciej Fijalkowski <fij...@gmail.com> wrote:
> On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon <br...@python.org> wrote:
> >
> >
> > On Mon, Aug 29, 2016, 17:06 Terry Reedy <tjre...@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?
>
It will be up to the tool. For Pyjion we just don't use the field if
someone else is using it, so if vmprof chooses to take precedence then it
can. Otherwise we can work out some common practice like if the field is
set and it isn't an object you put there then create a list, push on what
was already there, push on what you want to add, and set the field to the
list. That lets us do a type-check for the common case of only one object
being set, and in the odd case of the list things don't fail as you can
search the list for your object while acknowledging performance will suffer
(or we use a dict, I don't care really as long as we don't require a
storage data structure for the field in the single user case).
My point is that we can figure this out among Pyjion, PTVS, and vmprof if
we are the first users and update the PEP accordingly as guidance.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
