Replies: 1 comment 2 replies
-
Thanks for the suggestion. I can think of various types of support for
I'm guessing that 1 is most important to you, 2 is a "nice to have", and 3, 4 and 5 are less important. Is that a good guess? Item 1 would require some special-casing of the Items 2 and 3 would require special-casing in the language server (with potential support from the type checking logic). This is probably not something we'd do in pyright, but it's something the pylance team might consider adding. If you want one or both of these, I recommend filing a feature request in the pylance-release issue tracker. Item 4 would require special-casing in pyright. I'm reluctant to add this functionality because of the complexities involved in format specifiers. The edge cases for format specifiers are not well documented even for built-in classes like Item 5 would be possible if the rules were documented, but I don't think they are. One could look at the implementation in Python to try to reverse engineer them, but if they're not documented as part of the interface contract for |
Beta Was this translation helpful? Give feedback.
-
I work with a code base where we often pass around many different string literals that contain format fields. In order to resolve the strings with
.format
we have to look at the string's definition and fill out the method manually. This is quite unwieldy and hard to maintain.Would it be possible / not-to-difficult for pyright to provide enhanced typed information for
Literal[...].format
? E.g. giventhen
some_str.format
would have the following overloadsBeta Was this translation helpful? Give feedback.
All reactions