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
On Mon, Mar 22, 2021 at 5:37 PM Ben Rudiak-Gould
wrote: On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico
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 in his register machine, locals would be dereferenced after their last visible use. I don't think that's intrinsically a bad idea, but it's not backward compatible. The thing with
wrote: the process objects was just an example of currently working code that would break.
The example has nothing to do with PyQt5 really. I just happen to know
that QProcess objects kill the controlled process when they're collected. I think it's a bad design, but that's the way it is.
Another example would be something like
td = tempfile.TemporaryDirectory() p = subprocess.Popen([..., td.name, ...], ...) p.wait()
where the temporary directory will hang around until the process exits
with current semantics, but not if td is deleted after the second line. Of course you should use a with statement in this kind of situation, but there's probably a lot of code that doesn't.
Thanks for the clarification. I think the tempfile example will be a lot easier to explain this with, especially since it requires only the stdlib and isn't implying that there's broken code in a third-party library.
I don't like this. In a bracey language (eg C++), you can declare that a variable should expire prior to the end of the function by including it in a set of braces; in Python, you can't do that, and the normal idiom is to reassign the variable or 'del' it. Changing the semantics of when variables cease to be referenced could potentially break a LOT of code. Maybe, if Python were a brand new language today, you could define the semantics that way (and require "with" blocks for anything that has user-visible impact, reserving __del__ for resource disposal ONLY), but as it is, that's a very very sneaky change that will break code in subtle and hard-to-debug ways.
(Not sure why this change needs to go alongside the register-based VM, as it seems to my inexpert mind to be quite orthogonal to it; but whatever, I guess there's a good reason.)
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/C3CUQY... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)