[issue43892] Make match patterns explicit in the AST

Brandt Bucher added the comment: New changeset dbe60ee09dc5a624cfb78dff61ecf050a5b3f105 by Brandt Bucher in branch 'master': bpo-43892: Validate the first term of complex literal value patterns (GH-25735) https://github.com/python/cpython/commit/dbe60ee09dc5a624cfb78dff61ecf050a5b3f105

[issue43892] Make match patterns explicit in the AST

Change by Brandt Bucher : -- pull_requests: +24426 pull_request: https://github.com/python/cpython/pull/25735 ___ Python tracker ___

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: After the next docs build, the documentation for the explicit AST nodes should be available https://docs.python.org/dev/library/ast.html#pattern-matching -- resolution: -> fixed stage: commit review -> resolved status: open -> closed

[issue43892] Make match patterns explicit in the AST

Brandt Bucher added the comment: New changeset 1e7b858575d0ad782939f86aae4a2fa1c29e9f14 by Nick Coghlan in branch 'master': bpo-43892: Make match patterns explicit in the AST (GH-25585) https://github.com/python/cpython/commit/1e7b858575d0ad782939f86aae4a2fa1c29e9f14 --

[issue43892] Make match patterns explicit in the AST

Brandt Bucher added the comment: Sounds good. I'll probably be able to make time to review it today, or tomorrow at the latest. -- ___ Python tracker ___

[issue43892] Make match patterns explicit in the AST

Change by Nick Coghlan : -- assignee: ncoghlan -> brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43892] Make match patterns explicit in the AST

Change by Nick Coghlan : -- stage: patch review -> commit review ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: PR is green now, and I don't have any further changes I want to make, so Brandt, please feel free to merge if you're happy with the proposed AST nodes, and the way I've gone about implementing them. If you'd like some adjustments, it probably makes the most

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: PR against the main repo is now up: https://github.com/python/cpython/pull/25585 A couple of things in the unparser tripped me up (ast_unparse.c only handles annotation expressions, the way ast._Unparser.visit() is defined means NodeVisitor.generic_visit

[issue43892] Make match patterns explicit in the AST

Change by Nick Coghlan : -- pull_requests: +24305 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25585 ___ Python tracker ___

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: Working on the unparser picked up an inconsistency I had previously missed: aside from named expressions, "target" attributes in the AST are generally full expression subnodes, rather than identifier attributes. Identifier attributes on nodes are typically

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: Interesting idea - I had missed that you were suggested "identifier*" for the cls node. It's simple enough to check for Name-or-Attribute in the AST validator though, and sticking with a standard expr_ty node means getting a lot of standard handling in the

[issue43892] Make match patterns explicit in the AST

Brandt Bucher added the comment: I can probably find time to take a pass at the unparser, if you want. > cls needs to be an expression node to allow for attribute lookups That's why I suggested "identifier*"! Each identifier in the list would be one part of the dotted name, so we wouldn't

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: Setting clear timing expectations, given beta is so close: I'm not expecting to have time to finish the unparser work over the weekend, but I do expect to have time to finish it on Monday evening my time (UTC+10). --

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: https://github.com/ncoghlan/cpython/pull/9/commits/54940a3817df3046da3f9c51d4d426a73b2ec786 implements Brandt's suggestion of disallowing NULL keys in MatchMapping and instead passing in an explicit "rest" identifier to capture the extra keys. This did

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: To get the "0+0" matching case rejected again I had to flesh out a bit more of the AST validator. This initial piece of the validator replaces the previously pattern-matching-specific AST optimisation code that refused to fold BinOp expressions that weren't

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: Segfaults are fixed (I had a couple of cases where I wasn't checking for NULL, and another where I was looking up MatchMapping attributes on a MatchClass node). test_patma passes except for test cases 240, 241, and 242, which look like genuine regressions -

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: My proposed MatchConstant node name was bothering me, as most constants are actually matched by equality in MatchValue, the same way variables are. So I'm switching my proposed name for that node to be MatchSingleton, since that better reflects the key

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: I've removed the "?" from the end attributes for pattern nodes. The draft PR branch now compiles, but I've clearly made a mistake somewhere as it segfaults when trying to compile test_patma.py. -- ___ Python

[issue43892] Make match patterns explicit in the AST

Pablo Galindo Salgado added the comment: > I'm not really sure whether we should continue following this old tradition > of int? end_* attributes for new sum types like pattern, considering that it > was done for supporting the creation of old nodes 3.8< without any change on > 3.8>=.

[issue43892] Make match patterns explicit in the AST

Batuhan Taskaya added the comment: > | MatchStar(identifier? target) +1 on MatchStar(). Much more similiar to the existing node names, and also less semantically-named. > attributes (int lineno, int col_offset, int? end_lineno, int? > end_col_offset) I'm not really

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: The draft PR moved because I messed up the previous branch name: https://github.com/ncoghlan/cpython/pull/9/files It's to the point where everything except symtable.c compiles. I put an initial skeleton of a validator in, but only enough to check that the

[issue43892] Make match patterns explicit in the AST

Change by Nick Coghlan : -- stage: patch review -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43892] Make match patterns explicit in the AST

Change by Nick Coghlan : -- keywords: +patch pull_requests: +24241 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25521 ___ Python tracker

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: https://www.python.org/dev/peps/pep-0642/#representing-patterns-explicitly-in-the-abstract-syntax-tree covers the rationale for why it is potentially problematic to reuse expression nodes for match patterns: it doesn't semantically align with the fact that

[issue43892] Make match patterns explicit in the AST

Batuhan Taskaya added the comment: > Batuhan, perhaps we should change the linked issue for your AST validator PR > to this one. That way we can close the old catch-all PEP 634 implementation > issue and keep the discussion focused here. I think it might be better as a separate issue that

[issue43892] Make match patterns explicit in the AST

Change by Adrian Freund : -- nosy: +freundTech ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43892] Make match patterns explicit in the AST

Pablo Galindo Salgado added the comment: Also, I would like some more extensive argument or why not having context dependent nodes justifies the extra maintainance cost (I'm not against that of course, and I am sympathetic, but I think this needs some more extensive coverage or why we are

[issue43892] Make match patterns explicit in the AST

Brandt Bucher added the comment: Hm, for some reason I was thinking that this was safe to do after the feature freeze. Let's get to it then! Batuhan, perhaps we should change the linked issue for your AST validator PR to this one. That way we can close the old catch-all PEP 634

[issue43892] Make match patterns explicit in the AST

Change by Guido van Rossum : -- nosy: +Mark.Shannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43892] Make match patterns explicit in the AST

Change by Guido van Rossum : -- nosy: +Guido.van.Rossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: It's specifically the definition of "match_case" in the AST that is affected: match_case = (pattern pattern, expr? guard, stmt* body) pattern = MatchAlways | MatchValue(expr value) | MatchConstant(constant value) |

[issue43892] Make match patterns explicit in the AST

Nick Coghlan added the comment: Agreed. I had wanted the AST to be part of the PEPs specifically *because* it's a public API, but didn't check until today whether or not the original PEP 634 implementation had been merged as-is, or with a cleaned up AST definition.

[issue43892] Make match patterns explicit in the AST

Pablo Galindo Salgado added the comment: Given that the AST is a public interface, I would advise to implement this before beta freeze of 3.10 to avoid making this a breaking change in the future for linters and the like -- nosy: +pablogsal ___

[issue43892] Make match patterns explicit in the AST

New submission from Nick Coghlan : In the SC submission ticket for PEP 642 (https://github.com/python/steering-council/issues/43 ), Guido indicated he was in favour of the more explicit pattern matching AST changes suggested in that PEP. This ticket covers adapting the pattern matching