[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Change by Marc Mueller : -- nosy: +cdce8p ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Guido van Rossum added the comment: Honestly if someone manages to get a PR in I won’t be a spoilsport. So make me +0.-- --Guido (mobile) -- ___ Python tracker ___

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Adrian Freund added the comment: I already brought this up on the main pattern matching issue some time ago (https://bugs.python.org/issue42128#msg388554), where the consensus was that not using a Name is consistent with other parts of the ast, such as `import ... as identifier`, `except

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Anthony Sottile added the comment: at least for static analysis of other python constructs it's very convenient to know from a `Name` node alone whether it's being used in a read or write context -- without this information an ast traversal needs to maintain more information about whether

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Guido van Rossum added the comment: I'm -0.5 on reusing Name(ctx=Store). The reason we're using that in assignments is that in the past (before the PEG parser) the parser literally used the same grammar for the LHS and RHS of assignments, and a second pass was used to rule out invalid

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Change by Brandt Bucher : -- nosy: +freundTech ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Brandt Bucher added the comment: + Nick and Guido The only benefit I see on our side is that it leaves the door open for complex assignment targets in the future, like (a, b), a[b], etc. (If I recall correctly, this is also why NamedExpr uses an expr target rather than just an identifier.)

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Anthony Sottile added the comment: and actually, now that I look close it would be useful for `MatchStar` and `MatchMapping` to also use a `Name(..., ctx=Store())` for their respective parameters as well -- ___ Python tracker

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Anthony Sottile added the comment: I'm suggesting instead of: MatchAs(pattern=None, name='foo') to have MatchAs(pattern=None, name=Name('foo', ctx=Store())) -- ___ Python tracker

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Brandt Bucher added the comment: FWIW, I'm never used pyflakes, but I'm not really sure how it would be able to provide useful linting by just treating patterns as expressions (which is what I assume is desired here). I assume that these are the three lines you're trying to get rid of?

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

Brandt Bucher added the comment: Do you mind providing a bit more context? I'm sort of confused what exactly is being proposed here (as far as I can tell, it's not really possible to represent " as " with a single Name node). Also, I'm not sure if you're aware, but we just completed a huge

[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`

New submission from Anthony Sottile : I'm looking at adding support to `match` for pyflakes, and the first impression I have is that `MatchAs` is unnecessarily different from `Name` with `ctx=Store()` if it were represented as the latter pyflakes would not require special handling of