On Fri, Nov 27, 2020 at 06:59:40AM -0000, [email protected] wrote:
> Some examples for what I have in mind:
[...]
> file = open('move.py')
> read_and_close_file(file)
> file.read() # Mistake, file is already closed, static analyzer cah check that
That's not a good example for this proposed Move semantics, because it's
not access to `file` itself that is a problem. There would be nothing
wrong with this:
file = open('move.py')
read_and_close(file)
assert file.closed()
print(file.name)
It's only read (or write) after close that is problematic.
We already have this hypothetical issue, with no "move" or transfer of
ownership required:
file = open('move.py')
file.close()
file.read()
So your Move semantics is both *too strict* (prohibiting any access to
file, when only a couple of methods are a problem) and *insufficient*
(it does nothing to prevent the same use-after-close error in slightly
different scenarios).
Your example also makes my hackles rise: to my mind, it's just bad,
overly fragile code. You are splitting the responsibility for a single
conceptual action over distant (in time and space) pieces of code, e.g.
- caller opens the file
- callee reads and closes it
which is just an invitation for trouble.
There's a very good reason that the Python community has pretty much
settled on the `with open(...) as f` idiom as best practice for file
handling, it eliminates this sort of use-after-close entirely.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/IS76LMAN5PWHITYKDM4LFLLF45BJG4BD/
Code of Conduct: http://python.org/psf/codeofconduct/
