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

On Sun, Sep 4, 2016 at 2:09 AM, Nick Coghlan wrote: > On 3 September 2016 at 08:50, Chris Angelico wrote: >> Got it, thanks. I hope the vagaries of linear search don't mess with >> profilers - a debugger isn't going to be bothered by whether it gets >> first slot or second, but profiling and perf

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

On 3 September 2016 at 08:50, Chris Angelico wrote: > Got it, thanks. I hope the vagaries of linear search don't mess with > profilers - a debugger isn't going to be bothered by whether it gets > first slot or second, but profiling and performance might get subtle > differences based on which thin

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

On Fri, 2 Sep 2016 at 17:37 MRAB wrote: > On 2016-09-02 23:45, Brett Cannon wrote: > > > > > > On Fri, 2 Sep 2016 at 15:11 Chris Angelico > > wrote: > > > > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon > > wrote: > > > On Fri, 2 Sep

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

On 2016-09-02 23:45, Brett Cannon wrote: On Fri, 2 Sep 2016 at 15:11 Chris Angelico mailto:ros...@gmail.com>> wrote: On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon mailto:br...@python.org>> wrote: > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > mailto:python-dev@python.o

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

On Sat, Sep 3, 2016 at 8:45 AM, Brett Cannon wrote: >> I'm not following how this solves the collision problem. If you have a >> tuple, how do the two (or more) users of it know which index they're >> using? They'd need to keep track separately for each object, or else >> inefficiently search the

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

On Fri, 2 Sep 2016 at 15:11 Chris Angelico wrote: > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon wrote: > > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > > wrote: > >> > >> So it looks like both list and tuple are about within 5% of using > co_extra > >> directly. Using a tuple in

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

On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon wrote: > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > wrote: >> >> So it looks like both list and tuple are about within 5% of using co_extra >> directly. Using a tuple instead of a list is about a wash except for >> make_v2 where list i

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

- > > From: Python-Dev [mailto:python-dev- > > bounces+dinov=microsoft@python.org] On Behalf Of Chris Angelico > > Sent: Tuesday, August 30, 2016 2:11 PM > > To: python-dev > > Subject: Re: [Python-Dev] Update on PEP 523 and adding a co_extra field > to >

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

16 2:11 PM > To: python-dev > Subject: Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to > code objects > > On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka > wrote: > > On 30.08.16 21:20, Antoine Pitrou wrote: > >> > >> On Tue, 30 Au

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

osoft@python.org] On Behalf Of Chris Angelico Sent: Tuesday, August 30, 2016 2:11 PM To: python-dev Subject: Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: >> >

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

Nick Coghlan schrieb am 31.08.2016 um 06:30: > On 31 August 2016 at 04:55, Serhiy Storchaka wrote: >> On 30.08.16 21:20, Antoine Pitrou wrote: >>> 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

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

The PEP 445, C API for malloc, allows to plug multiple wrappers and each wrapper has its own "void* context" data. When you register a new wrapper, you store the current context and function to later chain it. See the hooks example: https://www.python.org/dev/peps/pep-0445/#use-case-3-setup-hooks-

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

On 31 August 2016 at 04:55, Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: >> 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 multipl

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

On 31 August 2016 at 07:11, Chris Angelico wrote: > 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. Differen

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

On Wed, Aug 31, 2016 at 4:55 AM, Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: >> >> On Tue, 30 Aug 2016 18:12:01 + >> Brett Cannon wrote: Why not make it always a list? List objects are reasonably cheap in memory and access time... (unlike dicts) >>> >>>

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

On Tue, 30 Aug 2016 at 11:56 Serhiy Storchaka wrote: > On 30.08.16 21:20, Antoine Pitrou wrote: > > On Tue, 30 Aug 2016 18:12:01 + > > Brett Cannon wrote: > >>> Why not make it always a list? List objects are reasonably cheap in > >>> memory and access time... (unlike dicts) > >> > >> Becau

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

On 30.08.16 21:20, Antoine Pitrou wrote: On Tue, 30 Aug 2016 18:12:01 + Brett Cannon 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 co

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

On Tue, 30 Aug 2016 18:12:01 + Brett Cannon 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

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

On Tue, 30 Aug 2016 at 10:49 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:35:35 + > Brett Cannon wrote: > > > > > > 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 typ

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

On Tue, 30 Aug 2016 17:35:35 + Brett Cannon wrote: > > > > 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 suffic

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

On Tue, 30 Aug 2016 at 10:32 Antoine Pitrou wrote: > On Tue, 30 Aug 2016 17:14:31 + > Brett Cannon 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

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

On Tue, 30 Aug 2016 17:14:31 + Brett Cannon 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_extr

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

On Tue, 30 Aug 2016 at 01:20 Maciej Fijalkowski wrote: > On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > > > > On Mon, Aug 29, 2016, 17:06 Terry Reedy wrote: > >> > >> On 8/29/2016 5:38 PM, Brett Cannon wrote: > >> > >> > who objected to the new field did either for memory ("it adds

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

On Tue, 30 Aug 2016 at 09:08 Antoine Pitrou wrote: > On Mon, 29 Aug 2016 21:38:19 + > Brett Cannon wrote: > > For quick background for those that don't remember, part of PEP 523 > > proposed adding a co_extra field to code objects along with making the > > frame evaluation function pluggable

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

On Mon, 29 Aug 2016 21:38:19 + Brett Cannon wrote: > For quick background for those that don't remember, part of PEP 523 > proposed adding a co_extra field to code objects along with making the > frame evaluation function pluggable ( > https://www.python.org/dev/peps/pep-0523/#expanding-pycode

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

On 2016-08-30 01:14, Brett Cannon wrote: > So the struct in question can be found at > https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Include/code.h#L10 > . > The official docs say the fields can be changed at any time, so > re-arranging them shouldn't break any AB

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

On 8/30/2016 4:20 AM, Maciej Fijalkowski wrote: On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: On Mon, Aug 29, 2016, 17:06 Terry Reedy 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 w

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

On Tue, Aug 30, 2016 at 3:00 AM, Brett Cannon wrote: > > > On Mon, Aug 29, 2016, 17:06 Terry Reedy 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

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

On Mon, Aug 29, 2016, 17:06 Terry Reedy 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

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

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 ex

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

On Mon, 29 Aug 2016 at 15:12 Maciej Fijalkowski wrote: > Hi Brett > > For what is worth, vmprof and similar tools would love such field > (there is an open question how can you use vmprof *and* another tool, > but later) > That's great to hear! Glad the solution has multiple use-cases. -Brett

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

On Mon, 29 Aug 2016 at 15:51 Guido van Rossum wrote: > Anyway, given the outcome of Dino's tests I have no objections to the > PEP. (Though using Christian's hack would be cool.) > Great! I'll mark the PEP as accepted and get the implementation in for 3.6. > > On Mon, Aug 29, 2016 at 3:28 PM,

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

Anyway, given the outcome of Dino's tests I have no objections to the PEP. (Though using Christian's hack would be cool.) On Mon, Aug 29, 2016 at 3:28 PM, Christian Heimes wrote: > On 2016-08-29 23:38, Brett Cannon wrote: >> That means we still want to find a solution to attach arbitrary data to

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

On 2016-08-29 23:38, Brett Cannon wrote: > That means we still want to find a solution to attach arbitrary data to > code objects without sacrificing performance. One proposal is what's in > PEP 523 for the extra field. Another option is to make the memory > allocator for code objects pluggable and

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

Hi Brett For what is worth, vmprof and similar tools would love such field (there is an open question how can you use vmprof *and* another tool, but later) On Mon, Aug 29, 2016 at 11:38 PM, Brett Cannon wrote: > For quick background for those that don't remember, part of PEP 523 proposed > addin

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

For quick background for those that don't remember, part of PEP 523 proposed adding a co_extra field to code objects along with making the frame evaluation function pluggable ( https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject). The idea was that things like JITs and debuggers could