Repository navigation
Allow string unpacking again. #13823
Description
String unpacking has been disallowed in #6406, where some comments ask for it to be allowed again. I'm opening an issue to track this better than comments in a closed issue.
Bug Report
I think mypy should allow string unpacking, as it's normal Python semantic.
To Reproduce
QUOTE_PAIRS = [
"''",
'""',
"<>",
"()",
"[]",
"{}",
]
for opening, closing in QUOTE_PAIRS:
print(opening, closing)Expected Behavior
I expected this to pass.
Actual Behavior
$ mypy pairs.py
pairs.py:10: error: Unpacking a string is disallowed
pairs.py:11: error: Cannot determine type of "opening"
pairs.py:11: error: Cannot determine type of "closing"
Found 3 errors in 1 file (checked 1 source file)
Your Environment
- Mypy version used: mypy 0.971 (compiled: yes)
- Mypy command-line flags: ø
- Mypy configuration options from
mypy.ini(and other config files): ø - Python version used: irrelevant, but reproduced in 3.9, 3.10, 3.11.
Activity
hauntsaninja commentedon Oct 6, 2022
At a minimum it should have its own error code, so you can do
--disable-error-code string-unpacking. Maybe the thing that should have a special case error is multi-assignment to a dict[str, something]sfc-gh-tteixeira commentedon Jun 22, 2023
At the core of this feature request is the question: Is MyPy a type-checker, or a combination of type-checker and linter?
If it's purely a type-checker (as I assume), then I agree with the @JulienPalard 's post: String unpacking is valid Python code, and it's a perfectly well-defined operation in terms of typing.
If MyPy is both a type-checker and a linter, then it becomes a matter of taste.
Make str unpacking check opt-in
Fix str unpack type propagation, use dedicated error code (python#20325)