test: moved from percent format to proper format for consistency #19586

Simple changes some of the python test related files. I converted from the old % format, ex: "test %s" % "hello" to the new str.format: "test {}".format("hello")

This is more modern, as well as more consistent with the rest of the codebase (I have looked around and seen str.format used)

@sanjaykdragon How were these 15 instances chosen? :) AFAICT we have 247 instances of the old printf-style string formatting in our codebase:

$ git grep "['\"] % " -- "*.py" | wc -l
247

If we are to do something like this I suggest looking at pyupgrade which can perform automatic conversion from the old printf-style string formatting to .format(…) :)

pyupgrade is a tool (and pre-commit hook) to automatically upgrade syntax for newer versions of the language. Try pip3 install pyupgrade && pyupgrade $(git ls-files -- "*.py") && git diff to see the suggested changes.

(Personally I don't have any strong opinion about this: just suggesting the proper tooling.)

Welcome @sanjaykdragon and thank you for your contribution.

For more information about stylistic cleanup, see:

• CONTRIBUTING.md#refactoring

"Pull requests that refactor the code should not be made by new contributors. It requires a certain level of experience to know where the code belongs to and to understand the full ramification (including rebase effort of open pull requests)."

If you're looking for ways to start contributing to the project, here is a great place to begin:

• CONTRIBUTING.md#getting-started

+1 what @practicalswift said, as long as this doesn't conflict with other changes.

TBH, that contributing guide statement to not submit refactoring PRs stopped me from doing so for the first full year, and meanwhile I've seen a number of new contributors begin with refactoring critical code and seen it both appreciated and merged. So I'm not sure if that statement is valid and should be in the guide.

Here though, it's a pure style change. Once again maybe wrongly, I thought that they weren't accepted from new people. Maybe I should not have read the docs as much :smile:

@jonatack I welcome style changes if then are in separate commit and simplify the PR while avoiding unnecessary style comments.

@sanjaykdragon How were these 15 instances chosen? :) AFAICT we have 247 instances of the old printf-style string formatting in our codebase:

$ git grep "['\"] % " -- "*.py" | wc -l
247

If we are to do something like this I suggest looking at pyupgrade which can perform automatic conversion from the old printf-style string formatting to .format(…) :)

pyupgrade is a tool (and pre-commit hook) to automatically upgrade syntax for newer versions of the language. Try pip3 install pyupgrade && pyupgrade $(git ls-files -- "*.py") && git diff to see the suggested changes.

(Personally I don't have any strong opinion about this: just suggesting the proper tooling.)

I lowkey fear using automated tools on a big repo. I changed the files manually, although I probably should have automated it. pyugprade looks pretty interesting though

TBH, that contributing guide statement to not submit refactoring PRs stopped me from doing so for the first full year, and meanwhile I've seen a number of new contributors begin with refactoring critical code and seen it both appreciated and merged. So I'm not sure if that statement is valid and should be in the guide.

Here though, it's a pure style change. Once again maybe wrongly, I thought that they weren't accepted from new people. Maybe I should not have read the docs as much 😄

I have seen a pretty mixed bag on this, and I don't know if i would consider this file critical code. I expect refactoring the consensus area would be more scrutinized

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #16365 (Log RPC parameters (arguments) if -debug=rpcparams by LarryRuane)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

~0. This is what is stated in the style guidelines for the functional tests, but there's a chance these will all be changed again, to f"something {arg}" once we move to supporting 3.6+ (#13718), so I don't think theres' any rush to go through and chance all these now.