> 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 ta
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 b
> 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 RETURN_VAL
> 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_pr
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
