[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

[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/issue36

[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:

[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> ___ _

[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

[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:

[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 coi

[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

[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> ___ _

[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, &a, &