docs/reference/speed_python: Clarify RAM usage of string concatenation. - #19602
Open
agatti wants to merge 1 commit into
Open
docs/reference/speed_python: Clarify RAM usage of string concatenation.#19602agatti wants to merge 1 commit into
agatti wants to merge 1 commit into
Conversation
Josverl
reviewed
Aug 11, 2026
| the concatenation do not appear elsewhere, that's RAM that could have been saved | ||
| by storing the final version of the string in the source to begin with. Long | ||
| strings can be split using the string concatenation operator ``\`` and still be | ||
| considered one single string by MicroPython: |
Contributor
There was a problem hiding this comment.
Perhaps worth pointing out that string continuation ( "A" "B" """"C"""" ) is a Python feature, and works with both single and triple quoted strings.
Contributor
Author
There was a problem hiding this comment.
Thanks for mentioning triple-quoted strings, I've added a mention to them (along with cleaning things up).
I originally added a triple-quoted string to the code snippet, but then decided against, since they're meant to be used to encode multi-line strings. Combining regular and multiline strings would then need a brief mention of the fact that the latter will have embedded newlines in them, and so on. It felt a bit out of place in a section that mentioned performance and memory savings.
agatti
force-pushed
the
update-string-folding-docs
branch
2 times, most recently
from
August 11, 2026 13:54
9d8917c to
8f97d41
Compare
This commit adds a brief clarification of what happens when strings are concatenated, and how that should be avoided if concatenation occurs between string literals. The parser won't perform any literal folding, so multiple string literal fragments concatenated together will be added to the QSTR table even if all they are used for is to build another string. Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
agatti
force-pushed
the
update-string-folding-docs
branch
from
August 11, 2026 13:59
8f97d41 to
31d0253
Compare
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
2 participants
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.
Summary
This PR adds a brief clarification of what happens when strings are concatenated, and how that should be avoided if concatenation occurs between string literals.
The parser won't perform any literal folding, so multiple string literal fragments concatenated together will be added to the QSTR table even if all they are used for is to build another string.
This is a follow-up of #19598, in which having literal strings folding in the parser was deemed not worthwhile, and a documentation update could have served a similar purpose.
Testing
The documentation was built with
make htmlto be sure it looked correct.Generative AI
I did not use generative AI tools when creating this PR.