docs: clarify that text() max_nb_chars is an upper bound - #2438
Open
saimoon504 wants to merge 1 commit into
Open
docs: clarify that text() max_nb_chars is an upper bound#2438saimoon504 wants to merge 1 commit into
saimoon504 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #2389
Brief summary: documentation-only fix. The text() docstring now states
explicitly that max_nb_chars is an upper bound, not a target.
What was wrong
While testing Faker for a university software testing course, we noticed
that text(max_nb_chars=200) regularly returns strings of 100-190
characters, and even max_nb_chars=99999 returned 99908 characters. We
reported this in #2389.
Reading the implementation, this is by design: the output is assembled
from whole words/sentences/paragraphs and the last unit that would
exceed the limit is dropped, so the result is always under max_nb_chars
but can be well under it. The docstring only said the length is
"approximate", which reads as "close to N" rather than "at most N,
possibly much less" - that is what confused us and what the issue is
really about.
How this fixes it
The docstring now states that:
previously undocumented)
No behavior changes.