Tone-down the case of default=True for flags in documentation#3049
Tone-down the case of default=True for flags in documentation#3049Rowlando13 merged 1 commit intopallets:mainfrom
default=True for flags in documentation#3049Conversation
|
@Rowlando13 As you are deep into the documentation side of Click, I'll be happy to have your feedback about the general wording here! :) |
704fa64 to
7cfcd3f
Compare
7cfcd3f to
e5dc6a9
Compare
a9120cc to
a245613
Compare
|
@Rowlando13 This is ready to be merged upstream! :) |
|
Good to merge, but I did mean to ask, is there a legitimate problem I'm not seeing here regarding typing/behavior? Or is it only a matter of being explicit with the code? |
Nothing about typing in this PR as most of the internals are already typed to Wait. Are you referring to typing as in text editing and not Python's type system? 😂 In which case I'm just requesting a quick review as I am not a native English speaker, so there's a non-zero chance my prose can end up a bit convoluted. 😬 |
|
I just meant that in the original comments/discussion, you seemed to be saying there was an issue with the default. Is this something we should change in the future, or just a matter of consistency in |
You mean In which case I was just warning that a flag cannot have its default value set to Maybe we will refine the concepts in the future with a better separation of concerns but that's really far away. We have more important things to do. So no big deal. |
|
Thanks @Rowlando13 for the merge! |
This PR reduce the strong langage around the behavior of
default=Truealigning toflag_valuefor flag options. There is not need to declare that case legacy as it has been Click's behavior for a long time.This address issues uncovered by @davidism in #3030 (comment) .
Context
This is a follow-up on #3030, which has been merged a little bit early and needs some polishing before Click 8.3.0 release.
Amends: 06847da