Skip to content

Conversation

Iqrar99
Copy link

@Iqrar99 Iqrar99 commented Mar 4, 2020

Based on #5338 , I just replaced some old-school string formatting with f-strings because f-strings are readable, more concise, and less prone to error than other ways of formatting, and also faster.
It's still in progress.

  • demo
  • jvm-packages
  • python-package
  • tests

@hcho3
Copy link
Collaborator

hcho3 commented Mar 4, 2020

Note that there’s still discussion ongoing about when to drop Python 3.5. This pull request will have to wait until the discussion concludes.

@Iqrar99
Copy link
Author

Iqrar99 commented Mar 4, 2020

okay, no problem. :)

@Iqrar99 Iqrar99 changed the title [WIP] Replacing old-school string formatting with f-strings Replacing old-school string formatting with f-strings Mar 15, 2020
@hcho3 hcho3 mentioned this pull request May 26, 2020
@hcho3
Copy link
Collaborator

hcho3 commented May 26, 2020

@Iqrar99 We are moving forward with this PR.

@hcho3
Copy link
Collaborator

hcho3 commented May 26, 2020

Pylint throws warning for using f-strings in loggers. I removed f-strings from loggers to pass lint check.

python-package/xgboost/dask.py:410: warning (W1203, logging-fstring-interpolation, 
  train.dispatched_train) Use lazy % formatting in logging functions

@codecov-commenter
Copy link

codecov-commenter commented May 26, 2020

Codecov Report

Merging #5388 into master will increase coverage by 0.02%.
The diff coverage is 56.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5388      +/-   ##
==========================================
+ Coverage   82.24%   82.26%   +0.02%     
==========================================
  Files          12       12              
  Lines        2726     2724       -2     
==========================================
- Hits         2242     2241       -1     
+ Misses        484      483       -1     
Impacted Files Coverage Δ
python-package/xgboost/__init__.py 88.88% <ø> (+2.52%) ⬆️
python-package/xgboost/compat.py 54.96% <0.00%> (ø)
python-package/xgboost/data.py 73.26% <0.00%> (ø)
python-package/xgboost/rabit.py 67.10% <0.00%> (ø)
python-package/xgboost/core.py 79.30% <30.43%> (ø)
python-package/xgboost/dask.py 83.68% <66.66%> (ø)
python-package/xgboost/callback.py 88.18% <100.00%> (+0.18%) ⬆️
python-package/xgboost/sklearn.py 91.31% <100.00%> (ø)
python-package/xgboost/tracker.py 93.97% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f145241...67607ec. Read the comment docs.

@hcho3 hcho3 self-requested a review May 27, 2020 01:36
@hcho3 hcho3 requested a review from a team May 27, 2020 01:37
@hcho3 hcho3 changed the title Replacing old-school string formatting with f-strings Drop Python 3.5; Require Python 3.6+; Replace old-school string formatting with f-strings May 27, 2020
Copy link
Member

@terrytangyuan terrytangyuan left a comment

Choose a reason for hiding this comment

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

.

@hcho3
Copy link
Collaborator

hcho3 commented May 27, 2020

I understand that this PR is intrusive, changing a large part of the codebase. I'd like to get approval from 2-3 committers before we merge this PR. An alternative is to merely allow f-strings in the future and keep old string formatting code as is.

Copy link
Member

@trivialfis trivialfis left a comment

Choose a reason for hiding this comment

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

It's just a feature, you can use it or don't. Alternatives are not going away or being obsoleted. I'm not sure what's the point of choosing one for the whole code base over the others. Is it a requirement that we need to choose it in the future for consistency?

I would love to use Python type hint. But that doesn't mean we will have a code base completely type hinted in future..

@hcho3
Copy link
Collaborator

hcho3 commented May 27, 2020

I changed my mind now. This PR ended up being quite intrusive, touching all Python files. Whole-sale change like this may introduce unintended breakage.

@hcho3
Copy link
Collaborator

hcho3 commented May 27, 2020

I opened #5715 to replace this PR.

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

Successfully merging this pull request may close these issues.

5 participants