GeezerVison

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@Ev2geny

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

I just can't figure out why bedevere/issue-number check is failing. Where do I have to mention it?

Hmm, I'm not sure I like the API in this solution. If I want to write portable code (Linux and Windows), I would then have to use delete=True and delete_on_close=False in every since call, right? This is going to look at bit convoluted. I'd much rather this was a distinct type of NamedTemporaryFile.

Hmm, I'm not sure I like the API in this solution. If I want to write portable code (Linux and Windows), I would then have to use delete=True and delete_on_close=False in every since call, right? This is going to look at bit convoluted. I'd much rather this was a distinct type of NamedTemporaryFile.

@blais , yes, this PR assumes, you would need to use delete_on_close=False (delete=True is already a default), if you want to write a portable code (Linux and Windows), but only if you need to refer to a created temporary file by its name, not by a file object. And this is a new functionality all together, as current functionality of the NamedTemporaryFile implicitly assumes, that you need to refer to a file by its file object (at least on Windows). Though I agree with you, that in test modules, one needs to often refer to temporary file by its name (hence the PR).

There were a lot of suggestions on how to fix this in the original issue14243 discussion with no clear conclusion on what is the best approach. I have chosen this one as it is backwards compatible and does not change philosophy of existing code. I will wait for code reviews to provide their feedback. There must be someone, who takes a final decision on this.

It would be wiser to create an alternative interface for this that is safe to use between platforms by default, even if it is more constrained, even if that means providing a completely different context manager.

OK. So I read the comments in the bug and the workaround here.
Here is what I did though (on Windows) - Created a temporary directory - put my temp file in there - script ends - all is gone
Hope that helps

@zooba Do you have time to take a look at this PR?

@zooba , just checking whether you managed to look at this

Can you re-target for 3.12 (Doc/whatsnew/3.10.rst) please?
Also, in NEWS I don't think you need double back ticks (``).

Also, in NEWS I don't think you need double back ticks (``).

@MaxwellDupre this is incorrect. Double backticks are usually preferred over single backticks in .rst files, unless a specific ReST role is being used.

Please read https://devguide.python.org/documenting/ for a full guide on ReST syntax.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Looks like you made a git mistake. Hopefully someone else can help you (maybe just close this PR and create a new one from a fresh clone of the main branch).

Looks like you made a git mistake. Hopefully someone else can help you (maybe just close this PR and create a new one from a fresh clone of the main branch).

Yes, this was something with git. I merged master branch into my PR, but it marked lots of files as being changed. I reverted this meanwhile. But I need some guidelines how to move forward.
Since there is a conflict between my PR and a master branch I guess I have to merge or rebase it with master somehow

Below is the the fixed up Improved Modules section, with each item in proper alphabetical order. I could not commit it because git requires all conflicts fixed in one merge, and I have no idea how to merge your tempfile change with what someone else did since your patch. Use git log or git blame to find the issue that made the alternative change and what it was meant to do.

Note: a few months ago, you did a force push instead of a simple update merge and push. Force pushes sometimes result in the behavior experienced today and are seldom needed. Unclear exactly what you did today. I recommend you fix conflict in your local clone, then merge upstream/main, then push to fork.

@terryjreedy , thanks for this information, but I am afraid I don't think I understand what to do with it and how exactly to move forward.

What I want is to refresh my pull request with whatever is latest in the current main branch. so did merge with the current main, which obviousely introduced a lot of new files, but when I pushed it to github it looks like it made impression, that I tried to modify them, whilst I only transfered them fom the main.
I now have reverted the change, but I still sit with the situation that I want to refresh by PR with whatever is the current main (and yes, a couple of merge conflicts will have to be resolved).

Also, the work on PR is not finished yet, as there were some more recent reviews from @eryksun

There are still conflicts. I'd recommend closing this PR and starting over with the changes you want to make.

Note: a few months ago, you did a force push instead of a simple update merge and push. Force pushes sometimes result in the behavior experienced today and are seldom needed. Unclear exactly what you did today. I recommend you fix conflict in your local clone, then merge upstream/main, then push to fork.

Just for the record: back then I did rebasing from the master (rather than merge). And then I had to do force push, if I remember correctly

Based on the suggestions of @gvanrossum and @JelleZijlstra I will close this PR and create a new one

I new PR 97015 has been created to replace this one.