Skip to content

format replaced with f-strings #29701

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

Merged
merged 3 commits into from
Nov 21, 2019
Merged

Conversation

lucassa3
Copy link
Contributor

@lucassa3 lucassa3 commented Nov 18, 2019

  • tests added / passed
  • passes black pandas
  • passes git diff upstream/master -u -- "*.py" | flake8 --diff

ref #29547

@@ -1751,7 +1749,7 @@ def nth(self, n: Union[int, List[int]], dropna: Optional[str] = None) -> DataFra
raise ValueError(
"For a DataFrame groupby, dropna must be "
"either None, 'any' or 'all', "
"(was passed {dropna}).".format(dropna=dropna)
f"(was passed {dropna})."
Copy link
Member

Choose a reason for hiding this comment

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

@datapythonista do we have a preferred usage for cases where this line needs the "f" and the preceeding does not? I could imagine we might want to put the "f" on all of them anyway

Copy link
Member

Choose a reason for hiding this comment

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

I think this is correct - should just keep it on lines where needed

Copy link
Member

Choose a reason for hiding this comment

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

Agree with @WillAyd, my preference is to just have the f were it's needed. Even in strings splitted in different lines.

Copy link
Member

Choose a reason for hiding this comment

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

As described in pep-498-concatenating-strings, regular strings are concatenated at compile time, and f-strings are concatenated at run time.

I think what we should not concatenate regular strings with f-strings because this could lead to unexpected results.

@@ -212,13 +208,13 @@ def groups(self):

def __repr__(self) -> str:
attrs_list = (
"{name}={val!r}".format(name=attr_name, val=getattr(self, attr_name))
f"{attr_name}={getattr(self, attr_name)!r}"
Copy link
Member

Choose a reason for hiding this comment

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

can you do this in two steps so as to not have the getattr inside the fstring

Copy link
Contributor Author

@lucassa3 lucassa3 Nov 19, 2019

Choose a reason for hiding this comment

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

@jbrockmendel Not really sure how to do this in two steps since attr_name is generated from a list comprehension. Do I just drop list comprehension usage in that case?

Copy link
Member

Choose a reason for hiding this comment

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

attr_tups = ((name, getatttr(self, name)) for name in self._attributes)
attr_tups = (x for x in attr_tups if x[1] is not None)
attrs_list = (f"{attr_name}={attr_val!r}" of attr_name, attr_val in attr_tups)

Copy link
Contributor

Choose a reason for hiding this comment

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

this usage seems ok to me

"len(data)\nresult: {grper}".format(
grper=pprint_thing(self.grouper)
)
f"len(data)\nresult: {pprint_thing(self.grouper)}"
Copy link
Member

Choose a reason for hiding this comment

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

pls take the pprint_thing outside of fspace

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

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

Nice PR. Lgtm once @jbrockmendel concerns are addressed

@WillAyd WillAyd added the Clean label Nov 19, 2019
@WillAyd WillAyd added this to the 1.0 milestone Nov 19, 2019
Copy link
Member

@datapythonista datapythonista left a comment

Choose a reason for hiding this comment

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

lgtm, nice clean up

There is a comment not addressed regarding a getattr inside an f-string. I'm happy with or without that.

@lucassa3
Copy link
Contributor Author

@datapythonista @WillAyd Great! Thanks for the approval. One more thing, I'm not sure what went wrong with the CI tests, but it doesn't seem related to these changes. What should I do?

Cheers

@jbrockmendel
Copy link
Member

One more thing, I'm not sure what went wrong with the CI tests, but it doesn't seem related to these changes. What should I do?

The affected builds are being flaky for unrelated reasons. We're trying to fix them, and will probably ask you to rebase when that is done

@lucassa3
Copy link
Contributor Author

One more thing, I'm not sure what went wrong with the CI tests, but it doesn't seem related to these changes. What should I do?

The affected builds are being flaky for unrelated reasons. We're trying to fix them, and will probably ask you to rebase when that is done

No problem!

@jbrockmendel
Copy link
Member

alright can you rebase and we'll see if the CI goes through

@lucassa3 lucassa3 force-pushed the replace-to-f-strings branch from 1706e90 to dd51a3a Compare November 21, 2019 10:56
@lucassa3
Copy link
Contributor Author

alright can you rebase and we'll see if the CI goes through

Rebased

@jreback jreback merged commit 5698462 into pandas-dev:master Nov 21, 2019
@jreback
Copy link
Contributor

jreback commented Nov 21, 2019

thanks @lucassa3

proost pushed a commit to proost/pandas that referenced this pull request Dec 19, 2019
proost pushed a commit to proost/pandas that referenced this pull request Dec 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants