Undeprecate literal_(de)stringizer #6943
Merged
+0
−21
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.
I propose to rescind the deprecation of
gml.literal_stringizer
andgml.literal_destringizer
.These functions have been deprecated since 2.5 but were never removed because it is not possible to do so without breaking tests. I spent a frustrating couple hours diving into this and gained a few insights. Currently,
literal_stringizer
is necessary to handle two specific cases that are tested:The first one is relatively easy to "fix" without literal stringizer. For completeness sake, it would involved adding the following snippet:
before L761.
The 2nd one is really tough to crack. The default
stringizer
function has anin_list
function to decide how to handle elements inside lists, but this only works for "1D" lists - nested sequences break this pattern and will end up raising an exception.literal_stringizer
gets around this by only unpacking the outermost list, then directly repr-ing everything inside it. I'm not even sure that the GML standard supports nested lists as attributes! However, this currently "works" according totest_data_types
, even if the result isn't actually valid, standards-compliant gml.IMO, the simplest thing to do would be to revert the deprecation. On the off-chance that there are users depending on this behavior,
literal_stringizer
is currently the only simple way to achieve it. It looks like the original motivation for deprecating theliteral_*stringizer
functions was Python 2->3 cleanup, but these corner cases are still relevant and unrelated to Python 2. Furthermore, I think reverting the deprecation will be relatively painless, as the deprecation warnings aren't currently visible due to the stack level.