You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that the speed-up PR landed, it should be safe for us to enable pattern matching by default as the last grammar case to try. This would still make us initially test the 3.7+ and 3.0-3.6 grammars first before we try to run with the backtracking.
@JelleZijlstra / @ichard26 / @felix-hilden what do you think about this? I recall there was some prior discussion on discord before, but that later got dismissed due to performance worries.
As far as I recall, blackbench did not contain anything too heavy with match/case. So it might not be a good indicator. On regular invocations, it should not be really problematic (only when the file is already broken or using 3.10 syntax, since we add it as the last choice).
For some match/case heavy non PEP 634 code (hand crafted by @ichard26, example it is almost 1.7X slower (compared to 9X before). I'll try to see whether we could improve this even more!
Yeah blackbench honestly needs a rewrite as its current design makes it hard to use / extend. I overengineered it unfortunately. I'd argue the performance slowdown is not that important at this point, it's quite low now and it should get even lower with PR #2763.
Anyway this issue is also important as its resolution would mean we could safely go ahead with making parenthesized with a 3.10 feature without risking the world, providing a resolution path for #1948.
Stability is probably the biggest question mark right now, but I'm fairly confident in @isidentical's implementation as it has passed their own suite of testing and also diff-shades. Short of doing some case crafting by hand, there's not much to explore (though we could always throw more code at it I suppose, in particular buggy code?). A rerun of diff-shades against the most recent implementation wouldn't hurt tho. I'd suspect remaining issues are only edge cases.
Activity
isidentical commentedon Jan 10, 2022
(this was actually supposed be a feature request not a bug)
isidentical commentedon Jan 10, 2022
@JelleZijlstra / @ichard26 / @felix-hilden what do you think about this? I recall there was some prior discussion on discord before, but that later got dismissed due to performance worries.
JelleZijlstra commentedon Jan 10, 2022
I'm fine with doing this if we think it's stable and fast enough. Perhaps @ichard26's blackbench can help make the decision.
isidentical commentedon Jan 11, 2022
As far as I recall, blackbench did not contain anything too heavy with match/case. So it might not be a good indicator. On regular invocations, it should not be really problematic (only when the file is already broken or using 3.10 syntax, since we add it as the last choice).
For some
match/caseheavy non PEP 634 code (hand crafted by @ichard26, example it is almost 1.7X slower (compared to 9X before). I'll try to see whether we could improve this even more!ichard26 commentedon Jan 13, 2022
Yeah blackbench honestly needs a rewrite as its current design makes it hard to use / extend. I overengineered it unfortunately. I'd argue the performance slowdown is not that important at this point, it's quite low now and it should get even lower with PR #2763.
Anyway this issue is also important as its resolution would mean we could safely go ahead with making parenthesized with a 3.10 feature without risking the world, providing a resolution path for #1948.
Stability is probably the biggest question mark right now, but I'm fairly confident in @isidentical's implementation as it has passed their own suite of testing and also diff-shades. Short of doing some case crafting by hand, there's not much to explore (though we could always throw more code at it I suppose, in particular buggy code?). A rerun of diff-shades against the most recent implementation wouldn't hurt tho. I'd suspect remaining issues are only edge cases.