This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ev2geny
Recipients Carl Osterwisch, Gabi.Davar, John Florian, chary314, dabrahams, davide.rizzo, dlenski, eric.araujo, eric.smith, eryksun, ethan smith, ethan.furman, ev2geny, jaraco, jwilk, martin.panter, ncoghlan, njs, paul.moore, piotr.dobrogost, pitrou, r.david.murray, sbt, steve.dower, tim.golden, zach.ware
Date 2021-04-28.19:58:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1619639903.53.0.437592022601.issue14243@roundup.psfhosted.org>
In-reply-to
Content
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?
History
Date User Action Args
2021-04-28 19:58:23ev2genysetrecipients: + ev2geny, paul.moore, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, jwilk, eric.araujo, r.david.murray, njs, dabrahams, ethan.furman, davide.rizzo, sbt, Gabi.Davar, martin.panter, piotr.dobrogost, zach.ware, dlenski, eryksun, steve.dower, Carl Osterwisch, ethan smith, John Florian, chary314
2021-04-28 19:58:23ev2genysetmessageid: <1619639903.53.0.437592022601.issue14243@roundup.psfhosted.org>
2021-04-28 19:58:23ev2genylinkissue14243 messages
2021-04-28 19:58:23ev2genycreate