On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro
wrote:
> I've not attempted to make any changes to calling conventions. It
> occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be
> merged into a single opcode, but I haven't really thought about that.
> Perhaps there's a good
> > So, neither "research" nor "production" seems to be a correct
> > descriptor.
>
> Not even government funding agencies distinguish between "research"
> and "itch-scratching" as long as you self-promote enough! :-) I agree
> with Paul, feel free to call it "research"!
Along similar lines,
> a) You're working with CPython bleeding edge.
> b) You find that (bleeding edge) adding extra chore.
> c) Nobody told you to work on bleeding (nor boss, nor a maintainer who
> said "I'll merge it once you've done"),
>
> Then: why do you complicate your task by working on bleeding edge?
> Could
Skip Montanaro writes:
> So, neither "research" nor "production" seems to be a correct
> descriptor.
Not even government funding agencies distinguish between "research"
and "itch-scratching" as long as you self-promote enough! :-) I agree
with Paul, feel free to call it "research"!
Steve
Hi Skip, thanks for the proto-PEP which makes for an interesting reading.
While reading the PEP, I had these questions:
1) I understand the goal is to make CPython faster. But this is not stated
explicitly. Is there a way to make this more explicit in the beginning, and
also how this would be
Hello Skip,
On Mon, 22 Mar 2021 17:13:19 -0500
Skip Montanaro wrote:
> Thanks for the response. I will try to address your comments inline.
>
> > I guess it should be a good idea to answer what's the scope of this
> > project - is it research one or "production" one? If it's research
> > one,
Thanks for the response. I will try to address your comments inline.
> I guess it should be a good idea to answer what's the scope of this
> project - is it research one or "production" one? If it's research one,
> why be concerned with the churn of over-modern CPython versions?
> Wouldn't it be
> Yeah, that is old writing, so is probably less clear (no pun intended)
> than it should be. In frame_dealloc, Py_CLEAR is called for
> stack/register slots instead of just Py_XDECREF. Might not be
> necessary.
Also, the intent is not to change any semantics here. The
implementation of
> In the "Object Lifetime" section you say "registers should be cleared upon
> last reference". That isn't safe, since there can be hidden dependencies on
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
> output_process = process_objects[-1]
> return
As I wrote, Skip’s Porto+PEP is not proposing to delete locals that are not
used in the rest of the function, only registers. So the voiced concerns
don’t apply.
On Sun, Mar 21, 2021 at 23:59 Chris Angelico wrote:
> On Mon, Mar 22, 2021 at 5:37 PM Ben Rudiak-Gould
> wrote:
> >
> > On Sun, Mar
On Mon, Mar 22, 2021 at 5:37 PM Ben Rudiak-Gould wrote:
>
> On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico wrote:
>>
>> At what point does the process_objects list cease to be referenced?
>> After the last visible use of it, or at the end of the function?
>
>
> In Python as it stands, at the
On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico wrote:
> At what point does the process_objects list cease to be referenced?
> After the last visible use of it, or at the end of the function?
In Python as it stands, at the end of the function, as you say.
Skip Montanaro's PEP suggested that
On Mon, Mar 22, 2021 at 3:14 PM Guido van Rossum wrote:
>
> On Sun, Mar 21, 2021 at 3:35 PM Chris Angelico wrote:
>>
>> On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould wrote:
>> >
>> > In the "Object Lifetime" section you say "registers should be cleared upon
>> > last reference". That isn't
On Sun, Mar 21, 2021 at 3:35 PM Chris Angelico wrote:
> On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould
> wrote:
> >
> > In the "Object Lifetime" section you say "registers should be cleared
> upon last reference". That isn't safe, since there can be hidden
> dependencies on side effects of
On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould wrote:
>
> In the "Object Lifetime" section you say "registers should be cleared upon
> last reference". That isn't safe, since there can be hidden dependencies on
> side effects of __del__, e.g.:
>
> process_objects = create_pipeline()
>
In the "Object Lifetime" section you say "registers should be cleared upon
last reference". That isn't safe, since there can be hidden dependencies on
side effects of __del__, e.g.:
process_objects = create_pipeline()
output_process = process_objects[-1]
return output_process.wait()
Hello,
On Sat, 20 Mar 2021 10:54:10 -0500
Skip Montanaro wrote:
> Back in the late 90s (!) I worked on a reimagining of the Python
> virtual machine as a register-based VM based on 1.5.2. I got part of
> the way with that, but never completed it. In the early 2010s, Victor
> Stinner got much
It was (is). It was a VM idea. Taken from a 2001 April Fool's Day joke
about Python and Perl merging.
The goal of optimizing a register based VM independently of the grammars
compiled to it seems smart. For a certain time our wonderful Alison Randall
was even lead of it.
The Python grammar must
Yes, I remember Parrot. As I understand it their original goal was a
language-agnostic virtual machine, which might have complicated things.
I will do a bit of reading and add some text to the "PEP."
Skip
On Sat, Mar 20, 2021, 11:36 AM David Mertz wrote:
> The Parrot project was also intended
The Parrot project was also intended to be the same thing, and for a while
had a fair number of contributors. Unfortunately, it never obtained the
performance wins that were good for.
On Sat, Mar 20, 2021, 11:55 AM Skip Montanaro
wrote:
> Back in the late 90s (!) I worked on a reimagining of
20 matches
Mail list logo
