[issue46841] Inline bytecode caches

Change by Brandt Bucher : -- pull_requests: +29986 pull_request: https://github.com/python/cpython/pull/31888 ___ Python tracker <https://bugs.python.org/issue46

[issue46841] Inline bytecode caches

Brandt Bucher added the comment: New changeset 49e1e1e1bd59cac1855b1ef4dec05d649ebcd81a by Mark Shannon in branch 'main': bpo-46841: Don't scan backwards in bytecode (GH-31901) https://github.com/python/cpython/commit/49e1e1e1bd59cac1855b1ef4d

[issue46817] Add a line-start table to the code object.

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue46817> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47046] Add `f_state` attribute to FrameObjects.

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue47046> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46841] Inline bytecode caches

Change by Brandt Bucher : -- pull_requests: +30057 pull_request: https://github.com/python/cpython/pull/31968 ___ Python tracker <https://bugs.python.org/issue46

[issue46864] Deprecate ob_shash in BytesObject

Brandt Bucher added the comment: Just a note: as of this week (GH-31888), we no longer use bytes objects to store bytecode. Instead, the instructions are stored as part of the PyCodeObject struct. (Of course, we still use bytes objects for the various exception handling and debugging

[issue47172] Make virtual opcodes in the compiler > 256 and is_jump() identify only proper jumps

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue47172> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46841] Inline bytecode caches

Change by Brandt Bucher : -- pull_requests: +30280 pull_request: https://github.com/python/cpython/pull/32205 ___ Python tracker <https://bugs.python.org/issue46

[issue47177] Frames should store next_instr instead of lasti

New submission from Brandt Bucher : Rather than maintaining the offset of the "last instruction" (`f_lasti`), interpreter frames should instead just maintain a pointer to the true next instruction. This has several benefits, most notably reducing the register pressure associated wi

[issue47177] Frames should store next_instr instead of lasti

Change by Brandt Bucher : -- keywords: +patch pull_requests: +30283 pull_request: https://github.com/python/cpython/pull/32208 ___ Python tracker <https://bugs.python.org/issue47

[issue46841] Inline bytecode caches

Change by Brandt Bucher : -- pull_requests: +30297 pull_request: https://github.com/python/cpython/pull/3 ___ Python tracker <https://bugs.python.org/issue46

[issue47120] Make all jump opcodes relative

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue47120> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47120] Make all jump opcodes relative

Brandt Bucher added the comment: Another benefit of this work is that we'll be able to remove `first_instr` from the eval loop. -- ___ Python tracker <https://bugs.python.org/is

[issue47233] show_caches option affects code positions reported by dis.get_instructions(...)

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue47233> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47233] show_caches option affects code positions reported by dis.get_instructions(...)

Brandt Bucher added the comment: Nice catch. The fix should be pretty simple: just move this line... https://github.com/python/cpython/blob/c1d93b6411f975d67e43942f1a2745a22983c18c/Lib/dis.py#L425 ...up to the top of the for loop. Are you interested in working on this

[issue47250] Add object.__getstate__() introduced refleaks

Brandt Bucher added the comment: Found it. This line should be removed: https://github.com/python/cpython/blob/4c92427fb85e420404a9bd26347e32acc1bbd3b7/Objects/typeobject.c#L5033 -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.

[issue45542] Using multiple comparison operators can cause performance issues

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue45542> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue47177] Frames should store next_instr instead of lasti

Brandt Bucher added the comment: New changeset ef6a482b0285870c45f39c9b17ed827362b334ae by Brandt Bucher in branch 'main': bpo-47177: Replace `f_lasti` with `prev_instr` (GH-32208) https://github.com/python/cpython/commit/ef6a482b0285870c45f39c9b17ed82

[issue47177] Frames should store next_instr instead of lasti

Change by Brandt Bucher : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue26868] Document PyModule_AddObject's behavior on error

Brandt Bucher added the comment: It looks like the idiom of calling PyModule_AddObject without Py_DECREF'ing on the error condition (or even checking for it at all) has spread quite a bit since this first reported. I'm preparing a PR to fix the other call sites. -

[issue26868] Document PyModule_AddObject's behavior on error

Change by Brandt Bucher : -- pull_requests: +15380 pull_request: https://github.com/python/cpython/pull/15725 ___ Python tracker <https://bugs.python.org/issue26

[issue38310] Opcode predictions for asserts, class definitions, and some calls.

Change by Brandt Bucher : -- keywords: +patch pull_requests: +16051 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16467 ___ Python tracker <https://bugs.python.org/issu

[issue38310] Opcode predictions for asserts, class definitions, and some calls.

New submission from Brandt Bucher : This patch adds four new opcode predictions: BUILD_MAP_UNPACK_WITH_CALL -> CALL_FUNCTION_EX: - Emitted whenever more than one map of **kwargs is unpacked into a call. - Pair *always* occurs together. LOAD_BUILD_CLASS -> LOAD_CONST: - Emitted when

[issue38328] Speed up the creation time of constant list literals.

New submission from Brandt Bucher : The attached PR contains a small change to the peephole optimizer that converts sequences of: LOAD_CONST(a), LOAD_CONST(b), ..., BUILD_LIST(n) to LOAD_CONST((a, b, ...)), BUILD_LIST_UNPACK(1) The improvement quickly becomes significant for lists larger

[issue33325] Optimize sequences of constants in the compiler

Change by Brandt Bucher : -- pull_requests: +16086 pull_request: https://github.com/python/cpython/pull/16498 ___ Python tracker <https://bugs.python.org/issue33

[issue38328] Speed up the creation time of constant list literals.

Change by Brandt Bucher : -- keywords: +patch pull_requests: +16087 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16498 ___ Python tracker <https://bugs.python.org/issu

[issue38328] Speed up the creation time of constant list literals.

Brandt Bucher added the comment: Yes, I was thinking about that (and BUILD_CONST_KEY_MAP as well). I'll open another PR with those as soon as this one is in. -- ___ Python tracker <https://bugs.python.org/is

[issue34938] Fix mimetype.init() to account for from import

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue34938> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38328] Speed up the creation time of constant list literals.

Brandt Bucher added the comment: ...unless you'd prefer that I add them to this PR. But I think it's a better idea to add and review them separately. -- ___ Python tracker <https://bugs.python.o

[issue38373] List overallocation strategy

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue38373> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38307] Provide Class' end line in readmodule module

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue38307> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38109] Missing constants in Lib/stat.py

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue38109> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38436] Improved performance for list addition.

New submission from Brandt Bucher : The attached PR adds a fast path for BINARY_ADD instructions involving two lists, where the left list has a refcount of exactly 1. In this case, we instead do a PySequence_InPlaceConcat operation. This has the affect of avoiding quadratic complexity for

[issue38436] Improved performance for list addition.

Change by Brandt Bucher : -- keywords: +patch pull_requests: +16289 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16705 ___ Python tracker <https://bugs.python.org/issu

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Change by Brandt Bucher : -- pull_requests: +16290 pull_request: https://github.com/python/cpython/pull/16705 ___ Python tracker <https://bugs.python.org/issue36

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Change by Brandt Bucher : -- pull_requests: -16290 ___ Python tracker <https://bugs.python.org/issue36229> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38438] argparse "usage" overly-complex with nargs="*"

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue38438> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38422] Clarify docstrings of pathlib suffix(es)

Change by Brandt Bucher : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue38422> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue38438] argparse "usage" overly-complex with nargs="*"

Brandt Bucher added the comment: I’m happy to write one. This seems like a pretty straightforward fix. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38438] argparse "usage" overly-complex with nargs="*"

Brandt Bucher added the comment: For backward compatibility with 2 metavars, the two-name form should still be possible. Just pass metavar=("FOO", "FOO"). -- ___ Python tracker <https://bug

[issue38436] Improved performance for list addition.

Brandt Bucher added the comment: Thanks, Pablo, for providing that. So the changes look like mostly a wash on these benchmarks. Serhiy: I do not see any significant change in + operator timing on my machine (again, just a rough test): $ ./python.exe -m timeit -s z=0 z+0 # master

[issue38436] Improved performance for list addition.

Brandt Bucher added the comment: ...and obviously the gains are more pronounced for more/longer lists. In general I'm not married to this change, though. If the consensus is "not worth it", I get it. But it seems like too easy

[issue36229] Avoid unnecessary copies for list, set, and bytearray ops.

Change by Brandt Bucher : -- pull_requests: +16298 pull_request: https://github.com/python/cpython/pull/16705 ___ Python tracker <https://bugs.python.org/issue36

[issue38436] Improved performance for list addition.

Brandt Bucher added the comment: Serhiy, here are the better performance measurements: $ ./python.exe -m pyperf timeit --duplicate=1000 -s z=0 z+0 # list-add . Mean +- std dev: 17.3 ns +- 0.3 ns $ ./python.exe -m pyperf timeit --duplicate=1000 -s z=0 z+0 # master

[issue38436] Improved performance for list addition.

Brandt Bucher added the comment: I went ahead and ran an instrumented build on some random production code (mostly financial data processing), just because I was curious: BINARY_ADD ops: 3,720,776 BINARY_ADD ops with two lists: 100,452 (2.7% of total) BINARY_ADD with new fast path: 26,357

[issue38436] Improved performance for list addition.

Brandt Bucher added the comment: I'm going to go ahead and close this, since the payoff doesn't seem to be worth the effort. Thanks for the benchmarking and feedback! -- resolution: -> rejected stage: patch review -> resolved status

[issue38328] Speed up the creation time of constant list literals.

Change by Brandt Bucher : -- pull_requests: +16423 pull_request: https://github.com/python/cpython/pull/16878 ___ Python tracker <https://bugs.python.org/issue38

[issue38560] Allow iterable argument unpacking after a keyword argument?

New submission from Brandt Bucher : Calls of the form f(name=value, *args) are currently legal syntax. The resulting argument binding is awkward, and almost never does what you want/expect it to: >>> def f(x, y, z): ... print(x, y, z) ... >>> f(x=0, *(1, 2)) Traceback

[issue38560] Allow iterable argument unpacking after a keyword argument?

Brandt Bucher added the comment: I've found one occurrence of this in the CPython codebase, in test_ast.py. Basically it makes sure that the following expression parses and compiles correctly: f(1,2,c=3,*d,**e) I doubt that this is to protect against regressions in this specific s

[issue38580] select()'s documentation claims only sequences are accepted, but it allows all iterables

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue38580> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38560] Disallow iterable argument unpacking after a keyword argument?

Brandt Bucher added the comment: I’ve thought about it and I’m +1 on DeprecationWarning in 3.9 and SyntaxError in 3.10. Removing any type of legal function call is tricky, but this is such obscure, sneaky syntax that it’s likely an accident/bug if it does pop up (that’s how I discovered it

[issue38637] fix GROWTH_RATE comments bug

Brandt Bucher added the comment: This PR was closed as invalid for the same reasons Steven mentioned above. -- nosy: +brandtbucher resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bug

[issue9495] argparse unittest tracebacks are confusing if an error is raised when not expected

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue9495> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15243] Misleading documentation for __prepare__

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue15243> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: Not a much thought went into that decision, honestly. The main reason I chose an identifier there was because "as" always stores a simple name, so allowing it to potentially be other contexts or expressions (which are illegal) just seemed

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: Yup, I agree we should explore this area further. See my comment here on Adrian’s mypy PR: https://github.com/python/mypy/pull/10191#issuecomment-797841945 -- ___ Python tracker <https://bugs.python.org/issue42

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: @BTaskaya, do you have any interest in helping me iterate on new AST nodes? -- ___ Python tracker <https://bugs.python.org/issue42

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: Cool. Today or tomorrow I'll create an issue in Guido's patma repo and we can move our discussion there. I'll also create a branch and add you to my fork. -- ___ Python tracker <https://bugs.pyt

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: Also, given that pattern matching is now shipped and documented, perhaps this issue should be closed? At this point I think dedicated issues are probably better for any new bugs/enhancements/etc. -- ___ Python

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: Actually, I didn't see that there are still 2 open linked PRs. I'll wait until those are merged. -- ___ Python tracker <https://bugs.python.o

[issue43574] Regression in overallocation for literal list initialization in v3.9+

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue43574> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42128] Structural Pattern Matching (PEP 634)

Change by Brandt Bucher : -- pull_requests: +23942 pull_request: https://github.com/python/cpython/pull/25203 ___ Python tracker <https://bugs.python.org/issue42

[issue42128] Structural Pattern Matching (PEP 634)

Brandt Bucher added the comment: New changeset f84d5a113680c5a6aaaf9130aed7a34d611748ff by Brandt Bucher in branch 'master': bpo-42128: __match_args__ can't be a list anymore (GH-25203) https://github.com/python/cpython/commit/f84d5a113680c5a6aaaf9130a

[issue43754] Eliminate bindings for partial pattern matches

Change by Brandt Bucher : -- keywords: +patch pull_requests: +23966 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25229 ___ Python tracker <https://bugs.python.org/issu

[issue43754] Eliminate bindings for partial pattern matches

New submission from Brandt Bucher : This draft PR contains a couple of pattern matching improvements I'm experimenting with. Most significantly, it implements behavior that several people requested during the PEP 634 feedback process: no more name bindings for partial matches. (One c

[issue43684] Add combined opcodes

Brandt Bucher added the comment: > I collected a few different sets of statistics: static stats for the stdlib > and for mypy, dynamic stats for running mypy and a few of the benchmarks in > pyperformance. I'm sure you've considered this, but I'd be *very* careful

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: I agree with Eric. You can already disable the automatic creation of __match_args__ by setting it yourself on the class being decorated, and "__match_args__ = ()" will make the class behave the exact same as if __match_args__ is not defined at all.

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: > Note that setting compare=False on a dataclass.field already excludes that > field from __match_args__... It appears you did find a genuine bug though! I was surprised by this comment, and after digging a bit deeper into _process_class found that we

[issue43754] Eliminate bindings for partial pattern matches

Brandt Bucher added the comment: Guido informed me that Mark is currently maintaining a PEP 653 implementation branch. I checked it out today, and it looks like it has *lots* of conflicts with this one. For the time being, I'm going to experiment with other ways of accomplishing this

[issue43764] Turning off generation of __match_args__ for dataclasses

Change by Brandt Bucher : -- pull_requests: +24020 pull_request: https://github.com/python/cpython/pull/25284 ___ Python tracker <https://bugs.python.org/issue43

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: New changeset d92c59f48680122ce0e4d1ccf69d92b983e8db01 by Brandt Bucher in branch 'master': bpo-43764: Fix `__match_args__` generation logic for dataclasses (GH-25284) https://github.com/python/cpython/commit/d92c59f48680122ce0e4d1ccf69d92

[issue39702] PEP 614: Relaxing Grammar Restrictions On Decorators

Brandt Bucher added the comment: New changeset 1e051a21b7106a93c30b74aad7e1f40d6c0c477b by Saiyang Gou in branch 'master': bpo-39702: Remove dotted_name from decorator documentation (GH-25234) https://github.com/python/cpython/commit/1e051a21b7106a93c30b74aad7e1f4

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: > init=False is used to make sure there's no __init__ defined, because there's > a difference between a class with an __init__ and one without. If there was a > difference between __match_args__ being not present and __match_args__=(), &

[issue43764] Turning off generation of __match_args__ for dataclasses

Brandt Bucher added the comment: I just realized that in my first two examples, all that's really needed is a "del Child.__match_args__" following each class definition. The main point still stands though: this may be a more common issue than I previously thought. If it is, t

[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching

Brandt Bucher added the comment: If we end up adding a “match_args=False” option to the dataclass decorator (issue 43764), then the docs for that option would probably be sufficient for this purpose. I’m imagining something like the docs for the “init” option, just substituting

[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching

Brandt Bucher added the comment: > For named tuples, there isn't an include/exclude option, so no extra mention > is warranted. I think a note in the docs could still be valuable, if only because defining __match_args__ for named tuples changes the inherited tuple behavior for

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

[issue42128] Structural Pattern Matching (PEP 634)

Change by Brandt Bucher : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Pyth

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

[issue43754] Eliminate bindings for partial pattern matches

Brandt Bucher added the comment: Since the feature freeze is coming up (and this changes the bytecode), I'd like to open this up for review now. It probably shouldn't actually be merged before the AST changes in issue 43892, though. There will be quite a few conflicts that need

[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 <https://bugs.python.org/is

[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/1e7b858575d0ad782939f86aae4a2f

[issue43977] Implement the latest semantics for PEP 634 for matching collections

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue43977> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43977] Implement the latest semantics for PEP 634 for matching collections

Change by Brandt Bucher : -- pull_requests: +24425 pull_request: https://github.com/python/cpython/pull/25734 ___ Python tracker <https://bugs.python.org/issue43

[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 <https://bugs.python.org/issue43

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

[issue43989] Enum deprecation breaks SSL tests

Change by Brandt Bucher : -- keywords: +patch nosy: +brandtbucher nosy_count: 6.0 -> 7.0 pull_requests: +24451 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25759 ___ Python tracker <https://bugs.p

[issue43989] Enum deprecation breaks SSL tests

Change by Brandt Bucher : -- pull_requests: -24451 ___ Python tracker <https://bugs.python.org/issue43989> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43989] Enum deprecation breaks SSL tests

Brandt Bucher added the comment: Whoops. I just meant to reference this issue, but I guess if the GitHub bots see an issue number in a PR comment they link that PR as a patch. -- stage: patch review -> needs patch ___ Python tracker <

[issue43950] Include column offsets for bytecode instructions

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue43950> ___ ___ Python-bugs-list mailing list Unsubscribe:

[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

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

[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())`

Change by Brandt Bucher : -- nosy: +freundTech ___ Python tracker <https://bugs.python.org/issue43994> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43754] Eliminate bindings for partial pattern matches

Brandt Bucher added the comment: New changeset 0ad1e0384c8afc5259a6d03363491d89500a5d03 by Brandt Bucher in branch 'master': bpo-43754: Eliminate bindings for partial pattern matches (GH-25229) https://github.com/python/cpython/commit/0ad1e0384c8afc5259a6d03363491d

[issue43754] Eliminate bindings for partial pattern matches

Change by Brandt Bucher : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43754> ___ ___ Pyth

[issue43977] Implement the latest semantics for PEP 634 for matching collections

Brandt Bucher added the comment: New changeset 9387fac100db359cbb6ec2a76f8a5eba8f9d7b65 by Brandt Bucher in branch 'master': bpo-43977: Document the new pattern matching type flags (GH-25734) https://github.com/python/cpython/commit/9387fac100db359cbb6ec2a76f8a5e

[issue44109] missing dataclass decorator in match-statement example

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue44109> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44109] missing dataclass decorator in match-statement example

Brandt Bucher added the comment: I don't really think there is anything wrong with the documentation. I can copy-and-paste all of the code from the PEP 634 section of the 3.10 What's New into the REPL without any issues (provided that named subjects like point/points/test_variable

[issue28307] Accelerate 'string' % (value, ...) by using formatted string literals

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker <https://bugs.python.org/issue28307> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    1   2   3   4   5   6   >