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

Replace open+read/write with pathlib's read/write_text/bytes #3263

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

happz
Copy link
Collaborator

@happz happz commented Oct 5, 2024

Pull Request Checklist

  • implement the feature

@happz happz added code | style Code style changes not affecting functionality code | no functional change "No Functional Change" intended. Patch should not change tmt's behavior in any way. labels Oct 5, 2024
@happz happz added this to the 1.38 milestone Oct 5, 2024
with open(ref_filepath, encoding='utf-8') as datafile:
data = tmt.utils.yaml_to_dict(datafile.read())
data = tmt.utils.yaml_to_dict(ref_filepath.read_text(encoding='utf-8'))

Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe utf8 is default, so could be dropped since we're "modernizing"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I’d love to, but I’m not sure about the default:

… the contents of the file are returned as str, the bytes having been first decoded using a platform-dependent encoding or using the specified encoding if given.

It may not necessarily be utf-8, IIUIC. I’m not sure what’s better, whether we should leave it to OS and Python to pick a sane default, or whether we should enforce the default as we see it, or whether we should always enforce UTF-8, without any exception. I also think we still ignore the problem of locales when parsing output of various commands, too, so far we were able to get away with it. Seems like we have several topics to discuss :)

Copy link
Collaborator

@thrix thrix Oct 8, 2024

Choose a reason for hiding this comment

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

Yeah, I believe another patch or discussion topic rather?

@happz happz added the ci | full test Pull request is ready for the full test execution label Oct 7, 2024
@happz happz marked this pull request as ready for review October 7, 2024 14:14
except OSError as error:
raise FileError(f"Failed to write '{path}'.\n{error}")
raise FileError("Failed to write into '{path}' file.") from error
Copy link
Collaborator

Choose a reason for hiding this comment

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

@happz why is f-string not needed here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed in 9068dc4.

hash=hash_value,
hashtype=used_hash.lower()
), source_name))
for line in (cwd / self.sources_file_name).read_text().splitlines():
Copy link
Collaborator

Choose a reason for hiding this comment

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

Seems there is a pattern here, could we add

def read_lines(path: Path) -> list[str]:
    return path.read_text().splitlines()

To our utils? So it would become:

            for line in read_path_lines(cwd / self.sources_file_name):

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm, if nothing else, for line in sys.stdin works. No idea whether pathlib has some alternative, maybe we can add a similar iterator to our custom class.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added in 187f79d. Iterator is not possible because both read_text() and splitlines() have their own options.

@happz happz force-pushed the drop-open-fot-read-write-text-bytes branch from 9e9e0be to 187f79d Compare October 8, 2024 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci | full test Pull request is ready for the full test execution code | no functional change "No Functional Change" intended. Patch should not change tmt's behavior in any way. code | style Code style changes not affecting functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants