RetroSearch Browse

Tue Aug 30 13:35:35 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-August/145976.html

On Tue, 30 Aug 2016 at 10:32 Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 30 Aug 2016 17:14:31 +0000
> Brett Cannon <brett at python.org> wrote:
> >
> > Depends on what vmprof chooses to do. Since the data is designed to be
> > disposable it could decide it should always take precedence and overwrite
> > the data if someone beat it to using the field. Basically I don't think
> we
> > want co_extra1, co_extra2, etc. But we don't want to require a dict
> either
> > as that kills performance. Using a list where users could push on objects
> > might work, but I have no clue what that would do to perf as you would
> have
> > to still needlessly search the list when only one piece of code uses the
> > field.
>
> Perhaps a list would work indeed.  Realistically, if there are at most
> 2-3 users of the field at any given time (and most probably only one or
> zero), a simple type check (by pointer equality) on each list item may
> be sufficient.
>

Let's see what Maciej says, but we could standardize on switching the field
to a list when a conflict of usage is detected so the common case in the
frame eval function is checking for your own type, and if that fails then
doing a PyList_CheckExact() and look for your object, otherwise make a list
and move over to that for everyone to use. A little bit more code, but it's
simple code and takes care of conflicts only when it calls for it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160830/965e23f9/attachment.html>

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

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

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