Re: [Python-Dev] frame evaluation API PEP

2016-06-21 Thread Nick Coghlan
On 20 June 2016 at 13:32, Dino Viehland via Python-Dev wrote: > It doesn’t help with the issue of potentially multiple consumers of that field > that has been brought up before but I’m not sure how concerned we should be > about that scenario anyway. Brett's comparison

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Dino Viehland via Python-Dev
On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > wrote: MRAB's response made me think of a possible approach: the co_extra field could be the very last field of the PyCodeObject struct and only present if a certain flag is set in co_flags. This is

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Guido van Rossum
Couple uses of "it" here are ambiguous -- are you saying we don't need co_extra after all, or that we can safely insist it's a dict, or...? On Mon, Jun 20, 2016 at 1:20 PM, Dino Viehland via Python-Dev < python-dev@python.org> wrote: > Mark wrote: > > > Dino and I thought of two potential

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Dino Viehland via Python-Dev
Mark wrote: > > Dino and I thought of two potential alternatives, neither of which we > > have taken the time to implement and benchmark. One is to simply have > > a hash table of memory addresses to JIT data that is kept on the JIT > > side of things. Obviously it would be nice to avoid the

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Brett Cannon
On Mon, 20 Jun 2016 at 13:43 Christian Heimes wrote: > On 2016-06-20 22:18, Guido van Rossum wrote: > > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > > wrote: > > > > MRAB's response made me think of a possible

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Christian Heimes
On 2016-06-20 22:18, Guido van Rossum wrote: > On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon > wrote: > > MRAB's response made me think of a possible approach: the > co_extra field could be the very last field of the PyCodeObject >

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Guido van Rossum
On Mon, Jun 20, 2016 at 12:59 PM, Brett Cannon wrote: > MRAB's response made me think of a possible approach: the co_extra field >> could be the very last field of the PyCodeObject struct and only present if >> a certain flag is set in co_flags. This is similar to a trick used

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Brett Cannon
On Sun, 19 Jun 2016 at 19:37 Guido van Rossum wrote: > On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon wrote: > >> >> >> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote: >> >>> Hi Brett, >>> >>> I've got a few questions about the specific

Re: [Python-Dev] frame evaluation API PEP

2016-06-20 Thread Brett Cannon
On Sun, 19 Jun 2016 at 21:01 Mark Shannon wrote: > > > On 19/06/16 18:29, Brett Cannon wrote: > > > > > > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum > > wrote: > > > > Hi Brett, > > > > I've got a few questions about the

Re: [Python-Dev] frame evaluation API PEP

2016-06-19 Thread Mark Shannon
On 19/06/16 18:29, Brett Cannon wrote: On Sat, 18 Jun 2016 at 21:49 Guido van Rossum > wrote: Hi Brett, I've got a few questions about the specific design. Probably you know the answers, it would be nice to have them in the PEP. Once

Re: [Python-Dev] frame evaluation API PEP

2016-06-19 Thread Guido van Rossum
On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon wrote: > > > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote: > >> Hi Brett, >> >> I've got a few questions about the specific design. Probably you know the >> answers, it would be nice to have them in the

Re: [Python-Dev] frame evaluation API PEP

2016-06-19 Thread MRAB
On 2016-06-20 02:29, Brett Cannon wrote: On Sat, 18 Jun 2016 at 21:49 Guido van Rossum > wrote: [snip] Could you figure out some other way to store per-code-object data? It seems you considered this but decided that the co_extra field was

Re: [Python-Dev] frame evaluation API PEP

2016-06-19 Thread Brett Cannon
On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote: > Hi Brett, > > I've got a few questions about the specific design. Probably you know the > answers, it would be nice to have them in the PEP. > Once you're happy with my answers I'll update the PEP. > > First, why not

Re: [Python-Dev] frame evaluation API PEP

2016-06-18 Thread Guido van Rossum
Hi Brett, I've got a few questions about the specific design. Probably you know the answers, it would be nice to have them in the PEP. First, why not have a global hook? What does a hook per interpreter give you? Would even finer granularity buy anything? Next, I'm a bit (but no more than a

Re: [Python-Dev] frame evaluation API PEP

2016-06-17 Thread Brett Cannon
I have taken PEP 523 for this: https://github.com/python/peps/blob/master/pep-0523.txt . I'm waiting until Guido gets back from vacation, at which point I'll ask for a pronouncement or assignment of a BDFL delegate. On Fri, 3 Jun 2016 at 14:37 Brett Cannon wrote: > For those

[Python-Dev] frame evaluation API PEP

2016-06-03 Thread Brett Cannon
For those of you who follow python-ideas or were at the PyCon US 2016 language summit, you have already seen/heard about this PEP. For those of you who don't fall into either of those categories, this PEP proposed a frame evaluation API for CPython. The motivating example of this work has been