-
-
Notifications
You must be signed in to change notification settings - Fork 672
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
📝 Fix outdated optional *CLI argument* section in tutorial #983
base: master
Are you sure you want to change the base?
Conversation
To match the example, description is updated
📝 Docs preview for commit 729182b at: https://1d0969a6.typertiangolo.pages.dev Modified Pages |
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.
Thanks for the PR! The text has indeed gotten a bit out of date as the example code now uses Annotated
.
I've rewritten the text again, because we shouldn't focus on the Optional
part of the type annotation, as that is not what is making the CLI argument optional 🙃 We need to focus the reader on the fact that there is a default value; whether that is None
or not and whether or not the type is Optional[X]
is irrelevant. We could also have had
name: Annotated[str, typer.Argument()] = "Rick"
for example. This is sufficiently explained in various parts of the documentation so doesn't need repeating here, but we just need to make sure to avoid confusion with the rephrasing.
Anyway - thanks again for spotting this!
@@ -113,7 +113,7 @@ name: str | |||
|
|||
Now, finally what we came for, an optional *CLI argument*. | |||
|
|||
To make a *CLI argument* optional, use `typer.Argument()` and pass a different "default" as the first parameter to `typer.Argument()`, for example `None`: | |||
To make a *CLI argument* optional, use `typer.Argument()` and make sure to provide a "default" value, for example `None`: |
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've now rewritten it so that it covers both Annotated
and non-Annotated code snippets:
name: Optional[str] = typer.Argument(default=None)
&
name: Annotated[Optional[str], typer.Argument()] = None
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.
From the point of someone, who were reading the tutorial for the first time (me), that's still confusing if you go from the previous examples:
name: Annotated[str, typer.Argument()]...that works exactly the same as
name: str
where you only see typer.Argument()
used inside the type definition. And peeking in the next example from the phrase in subject, you see only:
Now we have:
name: Annotated[Optional[str], typer.Argument()] = None
So I'd suggest adding both variants you mentioned in tutorial, like:
name: Annotated[Optional[str], typer.Argument()] = None...that works exactly the same as
name: Optional[str] = typer.Argument(default=None)
And placing the Annotated version first as it is recommended in the rest of the tutorial.
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.
Hm, I see.
I wonder whether it would be less confusing if the first example of an optional argument doesn't actually use None
as default, but some other random value. I think that would help enforce the idea that the default is all that matters, and that Optional
is only used to support None
as a potential value. What do you think?
📝 Docs preview for commit 014882c at: https://a3d15f63.typertiangolo.pages.dev Modified Pages |
To match the example, description is updated