Add non-docstring alternative for prompts #1338
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Not sure if there's any appetite for this but I figured after diving into it I might as well float it out there.
This PR adds a way to define a prompt that does not exclude the possibility of adding a docstring. It seems reasonable enough to assume that users of the library might want to provide docstrings for their arguments to the prompt that is not itself a part of the prompt.
In addition, making special use of a dunder attribute seems like it could be good to avoid (granted that the suggested parsing of bytecode doesn't seem much more agreeable).
I considered another name for the variable like
TEMPLATE
but was stopped in my tracks by flake8 who understandably gave me anF841
unused variable warning. Obviously not something you'd want to pass down to library consumers so_
it is.Worth noting this doesn't actually fix automatic doc generation like withActually, after using functools.update_wrapper, the docstring actually can be made to be helpful for these tools.pydoc
because that looks at the after-the-prompt-wrapper instance of thePrompt
class and gives less than helpful information.