Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

starfile.write ignores overwrite=True argument in the newest versions #72

Closed
rsanchezgarc opened this issue Oct 23, 2024 · 5 comments
Closed
Labels
good first issue Good for newcomers

Comments

@rsanchezgarc
Copy link

  • starfile version: 0.5.8 and master branch
  • Python version: 3.11
  • Operating System: Ubuntu 22.04

Description

The line star file.write(data, name, overwrite=True) generates a backup file of the original file named fname+"~". In past versions, it just overwrote the file if overwrite was True; otherwise, it raised an exception.

This happens here

self.backup_if_file_exists()

It would be great if the overwrite=True behaviour were returned to the API so that unwanted files are not generated.

@alisterburt
Copy link
Collaborator

ahh, good catch - thanks for the report!

@alisterburt alisterburt added the good first issue Good for newcomers label Oct 23, 2024
@alisterburt
Copy link
Collaborator

seems this was part of a larger change in #36 - I changed to defaulting to overwriting because we're adults and shouldn't be writing files programmatically without care...

I think the solution I like most is to get rid of the backup mechanism, what do you think?

cc @jojoelfe

@jojoelfe
Copy link
Collaborator

I kind of like the backup mechanism. But not super attached to it. I think my ideal behavior would be:

  • Default: Overwrite, but create backup and print warning
  • overwrite=True: Overwrite no warning or backup
  • overwrite=False: Fail with error message if file already exists

@rsanchezgarc
Copy link
Author

both options seem sensible to me. I just want it to keep the old behaviour if overwrite=True

@alisterburt
Copy link
Collaborator

closed by #76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants