Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-50948: IDLE: Warn if saving a file will overwrite a newer version#17578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
ZackerySpytz wants to merge6 commits intopython:main
base:main
Choose a base branch
Loading
fromZackerySpytz:bpo-6699-idle-overwrite-file

Conversation

ZackerySpytz
Copy link
Contributor

@ZackerySpytzZackerySpytz commentedDec 12, 2019
edited by bedevere-bot
Loading

Co-Authored-By: Guilherme Polo <ggpolo@gmail.com>Co-Authored-By: Priya Pappachan <priyapappachan010@gmail.com>
@hauntsaninjahauntsaninja changed the titlebpo-6699: IDLE: Warn the user if a file will be overwritten when savinggh-50948: IDLE: Warn the user if a file will be overwritten when savingJan 7, 2023
Copy link
Member

@serhiy-storchakaserhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

./python -m idlelib newfile.py fails, becauseio.set_filename() is called with non-existing file name.

@serhiy-storchaka
Copy link
Member

@terryjreedy, please take a look. I tested this change and fixed it. It LGTM now.

@terryjreedyterryjreedy changed the titlegh-50948: IDLE: Warn the user if a file will be overwritten when savinggh-50948: IDLE: Warn if saving a file will overwrite a newer versionDec 27, 2023
@terryjreedy
Copy link
Member

  1. loadfile twice calls stat, saving to temp local and thence to self.xxx. Is there an advantage to doing the stat call while the file is open? (Faster?)

  2. One of four stat calls is wrapped in try-except. Should all 4 be so wrapped? Or at least the other save call?

  3. Insave, the comparison != might just as well be<. See 4.

  4. The default return for SaveAs and SaveCopyAs is the current file. So I think the stat call and check should either be moved towritefile or put in a new method or function. Not sure of the best option yet.

@serhiy-storchaka
Copy link
Member

  1. I I initially was going to useos.fstat() (it is safer), but it cannot be used in other two places, so I leave it for now. Only one of them is called, the second way is executed if the first one fails. It is also more reliable to call here, in try/except blocks.
  2. This one is only can easily fail. All three others are very unlikely to fail, because they are called immediately after reading or writing a file. The two inloadfile are also in try/except blocks.
  3. I also thought about this, but it is better to keep!=. Imagine that you restored the earlier version of the file from archive or backup.
  4. SaveAs updates the current file name and the timestamp. SaveCopyAs keeps the current file name and the timestamp. Both callwritefile. Initially updating the timestamp was inset_filename, but I separated them, because it failed ifset_filename was called with the name of non-existing file (seegh-50948: IDLE: Warn if saving a file will overwrite a newer version #17578 (review)).

@hugovkhugovk removed the needs backport to 3.11only security fixes labelApr 22, 2024
@serhiy-storchakaserhiy-storchaka added the needs backport to 3.13bugs and security fixes labelMay 9, 2024
@hugovkhugovk removed the needs backport to 3.12only security fixes labelApr 10, 2025
@serhiy-storchakaserhiy-storchaka added the needs backport to 3.14bugs and security fixes labelMay 8, 2025
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@serhiy-storchakaserhiy-storchakaserhiy-storchaka approved these changes

@terryjreedyterryjreedyAwaiting requested review from terryjreedyterryjreedy is a code owner

Assignees
No one assigned
Labels
awaiting mergeneeds backport to 3.13bugs and security fixesneeds backport to 3.14bugs and security fixes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

7 participants
@ZackerySpytz@serhiy-storchaka@terryjreedy@hugovk@the-knights-who-say-ni@ezio-melotti@bedevere-bot

[8]ページ先頭

©2009-2025 Movatter.jp