[issue45384] Accept Final as indicating ClassVar for dataclass
Michael Sullivan added the comment: I tend to agree with Carl that making Final imply ClassVar for dataclass would make things worse. For better or worse (mostly better, but there are downsides like this!), dataclass class bodies are essentially written in their own domain specific language, and allowances need to be made in how typing things are interpreted in such a case, and I think that Carl is right that the right interpretation in the case of dataclasses is that the annotation describes the eventual instance attribute. At least, I feel this way 80% of the time. I can definitely see the argument for wanting consistency in the interpretation. >From a more directly practical perspective, though, the change would also be a >breaking one (though /arguably/ only of broken code), and so maybe not worth >it even if we would prefer the changed behavior. I think the right approach is probably to just append the PEP and then maybe also support ClassVar[Final[Whatever]]. It shouldn't need intersection types or anything; if it's a pain to implement it would be for annoying reasons and not deep ones. -- nosy: +msully4321 ___ Python tracker <https://bugs.python.org/issue45384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore
Michael Sullivan added the comment: I think there will be one more PR to disallow non-ASCII characters immediately after a `# type: ignore`, but otherwise I think this is done -- ___ Python tracker <https://bugs.python.org/issue36878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore
Change by Michael Sullivan : -- pull_requests: +13391 ___ Python tracker <https://bugs.python.org/issue36878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore
Change by Michael Sullivan : -- keywords: +patch pull_requests: +13148 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore
New submission from Michael Sullivan : Per discussion during the typing summit at PyCon, it would be a good idea to allow extra information to be included in `# type: ignore` comments, in order to allow behavior such as suppressing individual errors (for example, with syntax like `# type: ignore[E1000]`, to suppress error 1000). My proposal, then, is to generalize the definition of type: ignore comments to be `# type: ignore followed by a non-alphanumeric character. Then `# type: ignore[E1000]` and `# type: ignore E1000` would be valid type ignore comments while `# type: ignoreE1000` would not be. Now that ast.parse can parse type_comments, this needs to make it into 3.8, basically, if we want to do this and be able to use the ast type_comment feature. Ideally, the text of the type ignore would be actually included in the produced AST. As a bare minimum first step, we need to recognize type ignores with extra information and report them (and, critically, not detect them as regular type comments and produce errors when they appear in unexpected places). I'll put up a PR to do the second part shortly. -- components: Interpreter Core messages: 342130 nosy: gvanrossum, levkivskyi, msullivan priority: normal severity: normal status: open title: ast.parse with type_comments=True should allow extra text after # type: ignore type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35975] Put back the ability to parse files where async/await aren't keywords
Change by Michael Sullivan : -- nosy: +msullivan ___ Python tracker <https://bugs.python.org/issue35975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments
Michael Sullivan added the comment: A downside of the "allow $ twice" approach is that it means splitting up the positional arguments, and a lot of the processing loop is built around the assumption that the index into the keyword list and the index into the argument tuple coincide (for positional arguments). It can certainly be done, but I worry it'll be an invasive change -- ___ Python tracker <https://bugs.python.org/issue34235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments
Michael Sullivan added the comment: The point about a performance penalty is fair---my PR does add a search for the '@' (which I spelled as '`' in my example above) sigil whenever it encounters a '|'. (Though I'm not sure how big the impact would be? Format strings are small so a quick scan through it should be pretty fast. Could be measured.) I am missing how my PR changes the current behavior, though? As far as I can tell it should behave exactly the same unless there is a '@' in the format string. -- ___ Python tracker <https://bugs.python.org/issue34235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments
Change by Michael Sullivan : -- keywords: +patch pull_requests: +11865 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34235] PyArg_ParseTupleAndKeywords: support required keyword arguments
Michael Sullivan added the comment: How about adding another sigil that indicates that subsequent keyword-only arguments are required? So then your example becomes (using ` as a totally strawman option): PyArg_ParseTupleAndKeywords(args, kwds, "O|O$O`O", kwlist, , , , ) It's a little complicated but so is Python argument processing, so maybe that makes sense. I can submit a PR for this. -- nosy: +msullivan ___ Python tracker <https://bugs.python.org/issue34235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
