Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44037>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44206>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue42109>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue43413>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44276>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44283>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Seems like a good idea as long as we're careful about the implementation. I've
just jotted down a few notes here:
- We should probably break the table upon encountering a guard.
- We probably can't get away with storing a dictionary in th
Brandt Bucher added the comment:
Hm. I’m not sure if the HAMT makes much sense. We don’t really care about
efficient mutation or copies... constant-time lookups seem to be overwhelmingly
the most valuable factor here.
I personally think that creating some sort of hashable dict and teaching
Brandt Bucher added the comment:
> If I understand your proposal, that would mean that calling a function with a
> N-case constant-pattern match would require N hashes and N insertions into a
> dict (including memory allocation), followed by O(1) lookup. Wouldn't that
> e
Brandt Bucher added the comment:
Hm, that benchmark seems really noisy. Looking at your code, it appears that
you aren't actually iterating over the results.
I've attached a version of your benchmark rewritten to use pyperf. Here are the
results on a system with a fresh PGO/LT
Brandt Bucher added the comment:
For anyone curious, I had some free time today and took a stab at creating a
minimal _frozendict type (sharing as much implementation with dict as possible)
to see how difficult it would be.
It was actually much simpler than I thought... just a few dozen
Brandt Bucher added the comment:
I'm hoping we can get something close that for free by just waiting... the
faster-cpython folks are working on a tagged-pointer implementation of integers
as we speak.
I've been looking for a new project, so I'd love to help work on this is
Brandt Bucher added the comment:
> Are you sure you want to do this?
No, not yet. But there has been some positive feedback here, and it seems like
an interesting project to prototype. :)
> This optimisation is not applicable if the matched values are given symbolic
> names. You
New submission from Brandt Bucher :
Here are a few that I found. Not sure when they were introduced:
match ...:
case {**rest, "key": value}:
pass
match ...:
case {"first": first, **rest, "last": last}:
pass
match ...:
case {**_}:
Brandt Bucher added the comment:
Perhaps we need something like invalid_mapping_pattern or
invalid_mapping_pattern_double_star rules?
--
___
Python tracker
<https://bugs.python.org/issue44
Brandt Bucher added the comment:
Wow, that was quite a roller-coaster ride. Thanks Pablo. :)
--
___
Python tracker
<https://bugs.python.org/issue44368>
___
___
Brandt Bucher added the comment:
I found a similar one, by the way (not related to mapping patterns):
match ...:
case 42 as _:
pass
File "", line 2
case 42 as _:
^
SyntaxError: expected ':'
Is this
Brandt Bucher added the comment:
Could we just try parsing "as _" and raise if so? That wouldn't conflict with
any existing rules, and that way we could actually have a helpful error message.
--
___
Python tracker
<https
Brandt Bucher added the comment:
Like "SyntaxError: can't capture into a wildcard (consider removing)".
--
___
Python tracker
<https://bugs.pyt
Brandt Bucher added the comment:
Sorry, I’ve been out on vacation this weekend. I didn’t realize that there was
already a PR for this… I’m honestly not sure that it’s totally ready yet.
While I absolutely agree that compiling efficient decision trees lies in our
future, it certainly seems to
Brandt Bucher added the comment:
Also (because some of the people who might be interested are nosied on this
issue), I’ve been working a bit on general performance benchmarks for our
pattern-matching implementation:
https://github.com/brandtbucher/patmaperformance
I still need something
Brandt Bucher added the comment:
Yep, it's intentional.
And yep, I like the new error message better. :)
--
___
Python tracker
<https://bugs.python.org/is
Change by Brandt Bucher :
--
pull_requests: +25439
pull_request: https://github.com/python/cpython/pull/26864
___
Python tracker
<https://bugs.python.org/issue43
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44490>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue43564>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
New changeset ca2009d72a52a98bf43aafa9ad270a4fcfabfc89 by Brandt Bucher in
branch 'main':
bpo-43977: Properly update the tp_flags of existing subclasses when their
parents are registered (GH-26864)
https://github.com/python/cpyt
New submission from Brandt Bucher :
The generated bytecode for mapping patterns is more complicated than it needs
to be:
- Matching sub-patterns involves indexing into a tuple of values in order to
extract them. We already know the size of this tuple at compile-time, so we can
just unpack
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +25495
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26922
___
Python tracker
<https://bugs.python.org/issu
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44526>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
I don’t think this is a typo.
When x is 0, the point resides somewhere upon the vertical y axis. When y is 0,
the point resides somewhere upon the horizontal x axis.
Try plotting the points (0, 1) and (1, 0), for example
Brandt Bucher added the comment:
Nice find! In my opinion, we should do two things here:
- Update PEP 638 to specify that a SyntaxError is raised "if *any duplicate*
key patterns are literal patterns". This was absolutely our original
intention... I think the nuances were just l
Brandt Bucher added the comment:
Sorry, that should be PEP 634, not 638.
--
___
Python tracker
<https://bugs.python.org/issue44589>
___
___
Python-bugs-list m
Change by Brandt Bucher :
--
assignee: -> brandtbucher
___
Python tracker
<https://bugs.python.org/issue44589>
___
___
Python-bugs-list mailing list
Un
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue43838>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Thanks, I'll take a closer look at this soon (most likely this coming week).
Out of curiosity, do we have a standard way of writing regression tests for
correct line numbers like this? Of the top of my head, it seems like we could
either statically co
Brandt Bucher added the comment:
Thanks for the patch @jack__d! I'll try to find time to review it today.
I do wish you would have coordinated with me here before writing it, though.
I'd already begun working on a patch with a few new contributors yesterday, as
I mentioned in
Brandt Bucher added the comment:
New changeset 2693132292b2acf381ac6fa729bf3acf41d9d72b by Jack DeVries in
branch 'main':
bpo-44589: raise a SyntaxError when mapping patterns have duplicate literal
keys (GH-27131)
https://github.com/python/cpyt
Brandt Bucher added the comment:
Thanks, that test framework looks good for this.
My initial hunch (just from looking at this) is that this has to do with how we
handle cleanup after failed matches. Our "fail pop" blocks probably have
whatever the last line number compiled wa
Brandt Bucher added the comment:
Yeah, this is actively being worked on. Thanks for asking.
If anything changes, I’ll let you know and you can pick it up then!
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +25843
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27300
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
I believe that delegating to the actual underlying mapping without exposing it
is a bit of a lost cause, since for some type m we still need these to work:
>>> types.MappingProxyType(m({"a": 0)) | types.MappingProxyType(m({"b&
Brandt Bucher added the comment:
> Delegating operations to the underlying mapping is still OK, all we're
> wanting to bypass is the operand coercion dances in abstract.c and object.c
> that may expose the underlying mapping to the *other* operand.
But this won't work if
Brandt Bucher added the comment:
Two other things we realized while working on this:
- The first occurrence of line 15 in the example output should be marked as
incorrectly traced.
- We should emit a NOP to show coverage of "case _" (that fix will be part of
t
Brandt Bucher added the comment:
Yup, I plan on having it in this weekend.
--
___
Python tracker
<https://bugs.python.org/issue44600>
___
___
Python-bugs-list m
Brandt Bucher added the comment:
New changeset 4214f470f0cb9b6fef9a90758756fbc00ba95b5a by Charles Burkland in
branch 'main':
bpo-44600: Fix line numbers for pattern matching cleanup code (GH-27346)
https://github.com/python/cpython/commit/4214f470f0cb9b6fef9a90758756fb
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44741>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
(Raising the priority to "high" because any decision on this should ideally be
made before the 3.10 RCs.)
Hm, interesting. This is because we use UNPACK_EX for these patterns, so the
destructuring is basically the same as if you had written:
Brandt Bucher added the comment:
I agree, Pablo.
The only thing that makes me pause is that, depending on the pattern,
*sometimes* we use iteration and *sometimes* we use indexing. That might be
sort of surprising to classes like Seq if you change patterns or major Python
versions and this
Brandt Bucher added the comment:
> All the examples that are said to go into an infinite loop work fine in 3.9.
> [...] At the very least, the examples shouldn't swallow the IndexError and go
> into an infinite loop.
Note that the original example posted did not include a &qu
Change by Brandt Bucher :
--
pull_requests: +25929
pull_request: https://github.com/python/cpython/pull/27396
___
Python tracker
<https://bugs.python.org/issue44
Brandt Bucher added the comment:
New changeset 38ddc8beb38d9a685de296a58b0741850e4853e5 by Brandt Bucher in
branch 'main':
bpo-44600: Refactor new tracing tests (GH-27396)
https://github.com/python/cpython/commit/38ddc8beb38d9a685de296a58b0741
Brandt Bucher added the comment:
New changeset 31bec6f1b178dadec3cb43353274b4e958a8f015 by Batuhan Taskaya in
branch 'main':
bpo-43897: AST validation for pattern matching nodes (GH24771)
https://github.com/python/cpython/commit/31bec6f1b178dadec3cb43353274b4
Brandt Bucher added the comment:
Evaluating every key in every mapping pattern and checking them for duplicates
every time a match block is entered would be prohibitively expensive, for
negligible gain. The length check exists to avoid this step, replacing it with
a much cheaper O(1
Change by Brandt Bucher :
--
pull_requests: +25961
pull_request: https://github.com/python/cpython/pull/27432
___
Python tracker
<https://bugs.python.org/issue43
Brandt Bucher added the comment:
New changeset 8d0647485db5af2a0f0929d6509479ca45f1281b by Brandt Bucher in
branch 'main':
bpo-43897: Reject "_" captures and top-level MatchStar in the AST validator
(GH-27432)
https://github.com/python/cpython/commit/8d0647485db5af2a0f09
Change by Brandt Bucher :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Brandt Bucher :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44658>
___
___
Brandt Bucher added the comment:
Reopening as a release blocker.
It appears that this new rule is far too eager, and matches a much wider range
of inputs than intended. Here is a case where it changes an IndentationError
into a SyntaxError:
$ cat bug.py
print()
boom
On 3.9 (correct
New submission from Brandt Bucher :
PEP 626 says that "all expressions and parts of expressions are considered to
be executable code" for the purposes of tracing. However, folding constants at
compile-time can lose or change tracing events.
For example, these expressions (whic
Brandt Bucher added the comment:
Thanks for clarifying.
I'm worried, though, that the PEP's emphasis on "*all* lines of code executed
and *only* for lines of code that are executed" could be problematic for other
optimizations we perform. Consider:
if ( # <--
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue44772>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Yep, everything is working as intended here. Thanks, Dennis, for taking the
time to explain why.
Pablo, if you're still unsure of why your examples behave the way they do, I
strongly recommend reading through the official tutorial (PEP 636). It goes
th
Brandt Bucher added the comment:
I’m okay with closing as “won’t fix”.
--
___
Python tracker
<https://bugs.python.org/issue43838>
___
___
Python-bugs-list mailin
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue37596>
___
___
Python-bugs-list mailing list
Unsubscribe:
Brandt Bucher added the comment:
Could this issue be fixed in marshal itself? Off the top of my head, one
possible option could be to use the marshalled bytes of each elements as a sort
key, rather than the elements themselves. So serialize, *then* sort
Brandt Bucher added the comment:
Ah, yeah.
Could we add a flag to disable the reference mechanism, just for frozenset
elements? It would make marshalled frozensets a bit bigger (unless we
re-marshalled each one after sorting)... but I still prefer that to adding more
logic/subclasses to
Brandt Bucher added the comment:
This rough proof-of-concept seems to have the desired effect:
diff --git a/Python/marshal.c b/Python/marshal.c
index 1260704c74..70f9c4b109 100644
--- a/Python/marshal.c
+++ b/Python/marshal.c
@@ -503,9 +503,23 @@ w_complex_object(PyObject *v, char flag, WFILE
Change by Brandt Bucher :
--
pull_requests: +26377
pull_request: https://github.com/python/cpython/pull/27926
___
Python tracker
<https://bugs.python.org/issue37
Brandt Bucher added the comment:
Hm, not quite sure what you mean. Are you talking about just replacing each of
the new gotos with “Py_DECREF(pairs); return;”?
Error handling for this whole module is a bit unconventional. Some of the error
paths in this function decrement the recursion depth
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue34561>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
pull_requests: +26512
pull_request: https://github.com/python/cpython/pull/28068
___
Python tracker
<https://bugs.python.org/issue37
Brandt Bucher added the comment:
Thanks, this is awesome.
FYI, there's probably more low-hanging fruit like this scattered about the
pattern matching implementation. It's all very new code, mostly written by one
person ;).
(I wouldn't worry too much about the pattern c
Brandt Bucher added the comment:
I'm also in the process of creating some pattern matching benchmarks. You might
find them useful for benching optimizations like this in the future:
https://github.com/brandtbucher/patmaperformance
In particular, I'm curious to see the impact of t
Brandt Bucher added the comment:
New changeset 51999c960e7fc45feebd629421dec6524a5fc803 by Brandt Bucher in
branch 'main':
bpo-37596: Clean up the set/frozenset marshalling code (GH-28068)
https://github.com/python/cpython/commit/51999c960e7fc45feebd629421dec6
Brandt Bucher added the comment:
Thanks for finding this, Victor.
That failure is surprising to me. Is it really possible for the order of the
elements in a set to vary based on platform or build configuration (even with a
fixed PYTHONHASHSEED at runtime)?
Really, this looks like it’s only
Brandt Bucher added the comment:
I'm compiling Clang now to try to reproduce using a UBSan build (I'm on Ubuntu,
though).
I'm not entirely familiar with how these sanitizer builds work... could the
implication be that we're hitting undefined behavior at some point?
Brandt Bucher added the comment:
Found it. This particular build is configured with HAVE_ALIGNED_REQUIRED=1,
which forces it to use fnv instead siphash24 as its string hashing algorithm.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Brandt Bucher :
--
pull_requests: +26586
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/28147
___
Python tracker
<https://bugs.python.org/issu
Change by Brandt Bucher :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37596>
___
___
Pyth
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue45152>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue45155>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher
___
Python tracker
<https://bugs.python.org/issue45330>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher2
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Brandt Bucher :
--
nosy: +brandtbucher -brandtbucher2
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailin
New submission from Brandt Bucher :
...as discussed in https://github.com/faster-cpython/ideas/issues/101.
This change merges all BINARY_*/INPLACE_* instructions, except for a few
special cases:
- BINARY_ADD/INPLACE_ADD, which interact with sq_concat/sq_inplace_concat and
already have their
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +27519
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29255
___
Python tracker
<https://bugs.python.org/issu
Brandt Bucher added the comment:
Slower (29):
- unpack_sequence: 43.7 ns +- 0.9 ns -> 45.7 ns +- 1.1 ns: 1.04x slower
- float: 80.5 ms +- 0.9 ms -> 83.5 ms +- 1.3 ms: 1.04x slower
- regex_effbot: 3.15 ms +- 0.03 ms -> 3.26 ms +- 0.04 ms: 1.04x slower
- go: 165 ms +- 1 ms -> 17
Change by Brandt Bucher :
--
pull_requests: +27617
pull_request: https://github.com/python/cpython/pull/29357
___
Python tracker
<https://bugs.python.org/issue44
Change by Brandt Bucher :
--
pull_requests: +27671
pull_request: https://github.com/python/cpython/pull/29418
___
Python tracker
<https://bugs.python.org/issue45
Brandt Bucher added the comment:
I have a hunch that this is caused in optimize_basic_block. In general, we
don't bother clearing the oparg when peepholing instructions into NOPs.
We could either start becoming more principled about that and fix all of the
existing NOPs, or just u
New submission from Brandt Bucher :
Here's a weird one: for the last 8 years, we've defined a function called
"PyNumber_InMatrixMultiply" in abstract.c. It's a pretty clear misspelling of
"PyNumber_InPlaceMatrixMultiply", which is *also* defined in that
Change by Brandt Bucher :
--
pull_requests: +27733
pull_request: https://github.com/python/cpython/pull/29482
___
Python tracker
<https://bugs.python.org/issue45
Brandt Bucher added the comment:
I don't think that it does, since oparg gets totally reassigned each time we
load a new instruction. EXTENDED_ARG actually needs to hack around this by
advancing the instruction itself, updating oparg, and jumping straight into the
next o
New submission from Brandt Bucher :
The following code hangs during compilation on 3.11 and 3.10:
>>> while True or spam: pass
Our peepholer gets stuck in a loop, repeatedly "optimizing" instruction 4
(POP_JUMP_IF_TRUE -> JUMP_ABSOLUTE):
1 0 JUMP_ABSOL
Change by Brandt Bucher :
--
nosy: +brandtbucher
nosy_count: 3.0 -> 4.0
pull_requests: +27755
pull_request: https://github.com/python/cpython/pull/29505
___
Python tracker
<https://bugs.python.org/issu
Change by Brandt Bucher :
--
keywords: +patch
pull_requests: +27756
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29505
___
Python tracker
<https://bugs.python.org/issu
201 - 300 of 543 matches
Mail list logo
