Evgeny <ev2g...@gmail.com> added the comment:
Dear all, thank you very much for the discussion, I will just try to summarize the results of it. In my PR I used solution, proposed by Eryk. My solution involves introduction of the extra flag delete_on_close and making sure, that new situation is fully backwards compatible, because I did not feel I have an authority to propose anything which would break backwards compatibility (as Python 4.0 I think is not on the horizon yet) As I see from the discussion, the following decisions need to be taken: WHICH FLAG TO USE Eryk was proposing that it shall be delete_on_close (which I have implemented) Jason thinks, that we shall introduce flag delete_when, however when I read his proposal, the functionality which he proposes is not that different from what I implemented with delete_on_close. Ethan however thinks, that no extra flags are necessary at all USAGE OF O_TEMPORARY ON WINDOWS Ethan, Steve thinks, it is not needed Eryk prefers to provide a way to omit O_TEMPORARY, but still use it by default, when it's omitted CHANGING OF THE CURRENT BEHAVIOUR / BREAKING BACKWARDS COMPATIBILITY Ethan thinks, that we shall slightly change backwards compatibility in a way that if CM is used, than file is deleted on CM exit and not on close as now Jason thinks that backwards compatibility shall be changed gradually over several releases with the advanced depreciation warning Question: does everybody definitely agree then, that backwards compatibility shall definitely be altered, whether immediately or gradually? Any other decision to be taken which I missed? CONCLUSION: There seems to be still disagreements and I don't really know how to move this forward as I am not sure I understand the decision making mechanism in the Python community (especially when it comes to breaking backwards compatibility). Any thoughts on this? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue14243> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
