-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Pretty Terminal Output #2787
base: main
Are you sure you want to change the base?
Pretty Terminal Output #2787
Conversation
This enum can be used with `black.out.output()` to create pretty output logs, backward compatibility is ensured and if both, manual styles and `style=` kwarg is passed, the manually passed styles would overwrite the styles of the `style=`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all, I like the change especially for the easy access to predefined styles. Some comments below.
src/black/const.py
Outdated
|
||
|
||
class OutputLevels(Enum): | ||
null: Any = dict() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed, I prefer literals. This way the flake8 config doesn't have to change as well. I'll include it here as well so that others may comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also none
could be a more pythonic name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None
would be more pythonic agreed, but I would need to add some additional logic to _out
function, I wanted to keep it simple hence using am using an empty dict
here.
Regarding the dict
literals, I am using function calls here as I found them more readable compared to literals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant none: dict = {}
!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should either use dict literals here or decide that we globally don't care for this flake8 setting and disable it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant
none: dict = {}
!
Ah, that would work 👍🏻 (the name, mypy complains about : dict
as it needs the parameters)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Flake8 rule is definitely useful. So maybe we'll sacrifice a bit of readability and use literals here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure, either way is fine. We could even safely ignore the rule since very few people use functional calls over literals for normal use cases (which can be caught in reviews), otherwise, they are only used for some specific reasons like readability/explicitness (this case).
**_styles: Any, | ||
) -> None: | ||
styles = style.value.copy() | ||
if style: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me this is redundant because .update
with an empty dict does nothing. Also discussed before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, but I wanted to keep the .update()
change explicit hence keeping it in an if
block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems wrong, doesn't it mean we ignore _styles
if style == LogLevel.none
?
Also, the variable names style
, styles
, and _styles
here are pretty confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Umm, can't think of a better name for _styles
, these are the "styles" which the user explicitly passes as kwargs to overwrite the style defined by the LogLevel
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest style_overrides
.
src/black/report.py
Outdated
@@ -55,7 +62,7 @@ def failed(self, src: Path, message: str) -> None: | |||
|
|||
def path_ignored(self, path: Path, message: str) -> None: | |||
if self.verbose: | |||
out(f"{path} ignored: {message}", bold=False) | |||
out(f"{path} ignored: {message}", style=OutputLevels.warning) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this should be some other level, like info
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to highlight them, I could use dim yellow though, by changing to OutputLevels.info
and fg="yellow"
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any particular reason as to why you'd want to highlight them? Don't get me wrong, it could be nice. But this is why we define the styles right? 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wanted them to be easily recognizable from the crowd of "wasn't modified logs".
I don't think a |
Co-authored-by: felix-hilden <felix.hilden@gmail.com>
When we do `from black.output import out`, we get a object `out` pointing to function `black.output.out` function. But now when we _assign_ a new function to it via mock patching on `black.output.out`, the `out` object we had earlier still points to `black.output.out` (the old function, before patching). This is why when you are patching `black.output.out`, it wouldn"t be patched correctly, resulting in these errors. Nedbat has got a better explaination at https://nedbatchelder.com/blog/201908/why_your_mock_doesnt_work.html, in case this was a bouncer to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking better, but let's address all the comments!
That's a lot of bright green 👀 Anyways, regarding your second point, do you want to make all And regarding the third point, I don't |
I don't think you should change anything just yet, would be better to get more feedback first. |
This now has heavy merge conflicts. Should we still pursue this change? |
This introduces a style helper for styling your logs to get a bit pretty output in the terminal.
It adds an
OutputLevels
enum which can be used to define the level of the message "log" you are outputting. You can still use the old manual styles by passingfg
,bold
,dim
, etc. individually to the functionblack.output.out()
, but if they are specified alongside withstyle=
kwarg (which specifies theOutputLevels
) the manual styles would over-write the style specified by thestyle=
kwarg. An example use case is:The current terminal output looks like this:
This PR needs discussion regarding the colour styling, currently, I just picked up what I think would be okay for the level.
Checklist - did you ...