Re: SyntaxError: multiple statements found while compiling a single statement

Sohail Ahmad writes: > kindly please help me about issues > SyntaxError: multiple statements found while compiling a single statement > how to solve this issues Please post the code that got the error. Preferably several lines before the actual error, and the line with the err

[issue453677] statements should return a value

Change by admin : -- github: None -> 35018 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45138] [sqlite3] expand bound values in traced statements when possible

miss-islington added the comment: New changeset e801e88744f34508aa338f9f7f3f3baee012f813 by Erlend Egeberg Aasland in branch 'main': bpo-45138: Revert GH-28240: Expand traced SQL statements (GH-31788) https://github.com/python/cpython/commit/e801e88744f34508aa338f9f7f3f3baee012f813

[issue45138] [sqlite3] expand bound values in traced statements when possible

Change by Erlend E. Aasland : -- pull_requests: +29892 pull_request: https://github.com/python/cpython/pull/31788 ___ Python tracker ___

[issue45138] [sqlite3] expand bound values in traced statements when possible

Change by Erlend E. Aasland : -- pull_requests: +29888 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/31783 ___ Python tracker ___

[issue45138] [sqlite3] expand bound values in traced statements when possible

Erlend E. Aasland added the comment: Ah, one of my very first contributions, bpo-40318, comes back to haunt me: In bpo-40318, we migrated from the old SQLite trace API (sqlite3_trace) to SQLite trace v2 API (sqlite3_trace_v2). GH-19581, which introduced this change, introduced a bug: the

[issue45138] [sqlite3] expand bound values in traced statements when possible

Erlend E. Aasland added the comment: Reopening bco. broken buildbots. -- status: closed -> open ___ Python tracker ___ ___

[issue45138] [sqlite3] expand bound values in traced statements when possible

Jelle Zijlstra added the comment: Thanks for the contribution! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45138] [sqlite3] expand bound values in traced statements when possible

Jelle Zijlstra added the comment: New changeset d1777515f9f53b452a4231d68196a7c0e5deb879 by Erlend Egeberg Aasland in branch 'main': bpo-45138: Expand traced SQL statements in `sqlite3` trace callback (GH-28240) https://github.com/python/cpython/commit

[issue46091] IndendationError from multi-line indented statements

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Change by Pablo Galindo Salgado : -- pull_requests: +29078 pull_request: https://github.com/python/cpython/pull/30899 ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: New changeset 3fc8b74ace033a17346a992f661928ba619e61e8 by Pablo Galindo Salgado in branch '3.10': [3.10] bpo-46091: Correctly calculate indentation levels for whitespace lines with continuation characters (GH-30130). (GH-30898)

[issue46091] IndendationError from multi-line indented statements

Change by Pablo Galindo Salgado : -- pull_requests: +29077 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30898 ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: New changeset a0efc0c1960e2c49e0092694d9839270914c by Pablo Galindo Salgado in branch 'main': bpo-46091: Correctly calculate indentation levels for whitespace lines with continuation characters (GH-30130)

[issue44958] [sqlite3] only reset statements when needed

Change by Erlend E. Aasland : -- pull_requests: +28589 pull_request: https://github.com/python/cpython/pull/30379 ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg408657 ___ Python tracker ___ ___ Python-bugs-list

[issue46091] IndendationError from multi-line indented statements

Jeremy added the comment: Wow, this was a fast turnaround! I was going to spin some cycles on this, but would have not seen the solution in 50m. -- ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: nevermind, I am convinced is a bug. I filed a PR for it -- stage: patch review -> ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +28349 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30130 ___ Python tracker

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: Actually, I am not sure if this is a bug, at least according to this comment: https://bugs.python.org/msg370812 What are your thoughts on this Guido? -- nosy: +gvanrossum ___ Python tracker

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: Unfortunately I am not sure if this is going to be easier to retrofit for the reasons exposed in the issue. I will try to take a look, but if you have some cycles to spare, a PR would be welcomed. -- ___

[issue46091] IndendationError from multi-line indented statements

Pablo Galindo Salgado added the comment: This is a side effect on the fix in: https://bugs.python.org/issue40847 -- ___ Python tracker ___

[issue46091] IndendationError from multi-line indented statements

lementation is not following the spec? [1]: https://docs.python.org/3/reference/lexical_analysis.html#indentation -- components: Parser files: nodent.py messages: 408651 nosy: lys.nikolaou, pablogsal, ucodery priority: normal severity: normal status: open title: IndendationError from multi-line

[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

Change by Mark Shannon : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Change by Andrew Svetlov : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Andrew Svetlov added the comment: New changeset e99c5e039b380199843db4e06974883d9f3ddad0 by Miss Islington (bot) in branch '3.10': bpo-45896: Fix docs default asyncio event loop on Windows (GH-29857) (GH-29877) https://github.com/python/cpython/commit/e99c5e039b380199843db4e06974883d9f3ddad0

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Andrew Svetlov added the comment: New changeset 4203a5d1918ca874e305806b787e3c8c6fc35e3e by Miss Islington (bot) in branch '3.9': bpo-45896: Fix docs default asyncio event loop on Windows (GH-29857) (GH-29878) https://github.com/python/cpython/commit/4203a5d1918ca874e305806b787e3c8c6fc35e3e

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Change by miss-islington : -- pull_requests: +28103 pull_request: https://github.com/python/cpython/pull/29878 ___ Python tracker ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Change by miss-islington : -- nosy: +miss-islington nosy_count: 4.0 -> 5.0 pull_requests: +28102 pull_request: https://github.com/python/cpython/pull/29877 ___ Python tracker

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Andrew Svetlov added the comment: New changeset f27bef30438d2f07f19de91e021f34b77ccc4b20 by Rob in branch 'main': bpo-45896: Fix docs default asyncio event loop on Windows (GH-29857) https://github.com/python/cpython/commit/f27bef30438d2f07f19de91e021f34b77ccc4b20 --

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Change by Rob : -- keywords: +patch pull_requests: +28085 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29857 ___ Python tracker ___

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by theeshallnotknowethme : -- pull_requests: +28012 pull_request: https://github.com/python/cpython/pull/29775 ___ Python tracker ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Rob added the comment: Ok will do. Thanks for confirming. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Andrew Svetlov added the comment: You are correct, the first statement is outdated. Please feel free to make a pull request. -- ___ Python tracker ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

Change by Alex Waygood : -- nosy: +asvetlov, yselivanov type: -> behavior versions: +Python 3.11, Python 3.9 ___ Python tracker ___

[issue45896] Conflicting statements in docs about default support for asyncio subprocesses on Windows

here are conflicting statements about default support for asyncio subprocesses on Windows. It seems the first statement listed above, is wrong or outdated since the default event loop on Windows is the ProactorEventLoop which does support subprocesses. Thank you! -- assignee: do

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by theeshallnotknowethme : -- pull_requests: +27765 pull_request: https://github.com/python/cpython/pull/29513 ___ Python tracker ___

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by Andre Roberge : -- nosy: +aroberge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45759] Improve error messages for non-matching `elif`/`else` statements

Change by Alex Waygood : -- title: non-matching `elif`/`else` statements with uninformative errors -> Improve error messages for non-matching `elif`/`else` statements ___ Python tracker <https://bugs.python.org/issu

[issue45759] non-matching `elif`/`else` statements with uninformative errors

Change by Alex Waygood : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45759] non-matching `elif`/`else` statements with uninformative errors

theeshallnotknowethme added the comment: I'd like to expand this to more than just `elif`/`else statements inside `if` statement blocks and make an error for other cases as well. I currently have a PR that has a general error to accommodate those cases. -- title: `elif` inside

[issue44958] [sqlite3] only reset statements when needed

Pablo Galindo Salgado added the comment: New changeset 7b88f63e1dd4006b1a08b9c9f087dd13449ecc76 by Erlend Egeberg Aasland in branch 'main': bpo-44958: Revert GH-27844 (GH-28574) https://github.com/python/cpython/commit/7b88f63e1dd4006b1a08b9c9f087dd13449ecc76 --

[issue44958] [sqlite3] only reset statements when needed

Change by Erlend E. Aasland : -- pull_requests: +26956 pull_request: https://github.com/python/cpython/pull/28574 ___ Python tracker ___

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: I'll revert PR 27844 for now (except the tests). Since SQLite works better when we keep the number of non-reset statements to a minimum, we need to ensure that we reset statements when we're done with them (sqlite3_step() returns SQLITE_DONE or an error

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: Explicitly resetting statements when we're done with them removes the performance regression; SQLite works more efficient when we keep the number of non-reset statements low. -- ___ Python tracker <ht

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: > I'm unable to reproduce this regression on my machine (macOS, debug build, no > optimisations) [...] Correction: I _am_ able to reproduce this. -- ___ Python tracker

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: I'm unable to reproduce this regression on my machine (macOS, debug build, no optimisations). Are you able to reproduce, Ken? -- ___ Python tracker

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: Ouch, that's quite a regression! Thanks for the heads up! I'll have a look at it right away. -- ___ Python tracker ___

[issue44958] [sqlite3] only reset statements when needed

Ken Jin added the comment: Erlend, I suspect that 050d1035957379d70e8601e6f5636637716a264b may have introduced a perf regression in pyperformance's sqlite_synth benchmark: https://speed.python.org/timeline/?exe=12==sqlite_synth=1=50=off=on=on The benchmark code is here

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: > Now that pysqlite_statement_reset() is only used in cursor.c, I suggest to > move it to cursor.c and make it a static function. I'll wait until PR 25984 is merged before opening a PR for relocating pysqlite_statement_reset(). --

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: Now that pysqlite_statement_reset() is only used in cursor.c, I suggest to move it to cursor.c and make it a static function. -- ___ Python tracker

[issue44958] [sqlite3] only reset statements when needed

miss-islington added the comment: New changeset 3e3ff09058a71b92c32d1d7dc32470c0cf49300c by Erlend Egeberg Aasland in branch 'main': bpo-44958: Fix ref. leak introduced in GH-27844 (GH-28490) https://github.com/python/cpython/commit/3e3ff09058a71b92c32d1d7dc32470c0cf49300c -- nosy:

[issue44958] [sqlite3] only reset statements when needed

Change by Erlend E. Aasland : -- pull_requests: +26886 pull_request: https://github.com/python/cpython/pull/28490 ___ Python tracker ___

[issue44958] [sqlite3] only reset statements when needed

Pablo Galindo Salgado added the comment: New changeset 050d1035957379d70e8601e6f5636637716a264b by Erlend Egeberg Aasland in branch 'main': bpo-44958: Only reset `sqlite3` statements when needed (GH-27844) https://github.com/python/cpython/commit/050d1035957379d70e8601e6f5636637716a264b

[issue45138] [sqlite3] expand bound values in traced statements when possible

Change by Erlend E. Aasland : -- title: [sqlite3] expand bound values in traced statements if possible -> [sqlite3] expand bound values in traced statements when possible ___ Python tracker <https://bugs.python.org/issu

[issue45138] [sqlite3] expand bound values in traced statements if possible

Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +26660 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28240 ___ Python tracker

[issue45138] [sqlite3] expand bound values in traced statements if possible

- assignee: erlendaasland components: Extension Modules messages: 401383 nosy: erlendaasland priority: low severity: normal status: open title: [sqlite3] expand bound values in traced statements if possible type: enhancement versions: Python 3.11 ___ Python track

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: In msg399939, item 2 lacks one more "reset path": > 2. at cursor exit, if there's an active statement Rewording this to: 2. when a statement is removed from a cursor; that is either at cursor dealloc, or when the current statement is replaced.

[issue44965] [sqlite3] early exit for non-DML statements in executemany()

Change by Pablo Galindo Salgado : -- nosy: -pablogsal resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44965] [sqlite3] early exit for non-DML statements in executemany()

Pablo Galindo Salgado added the comment: New changeset 878e7267016ba25d05d8736349fb897c756f311d by Erlend Egeberg Aasland in branch 'main': bpo-44965: Early exit for non-DML statements in sqlite3.Cursor.executemany() (GH-27865) https://github.com/python/cpython/commit

[issue44965] [sqlite3] early exit for non-DML statements in executemany()

Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +26320 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27865 ___ Python tracker

[issue44965] [sqlite3] early exit for non-DML statements in executemany()

, built the row cast map, and created the description tuple, all before raising the "executemany() can only execute DML statements." So, the error message currently is not quite true, because we already executed the statement once. Checking for this earlier will prevent a (possibly time

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: I did a quick count of sqlite3_reset()s in the sqlite3 test suite: - main: 2976 calls - PR 27844: 1730 calls Since we never call sqlite3_reset() with a NULL pointer, all sqlite3_reset() calls we execute hold the SQLite db mutex; reducing the number of

[issue44958] [sqlite3] only reset statements when needed

Change by Erlend E. Aasland : -- Removed message: https://bugs.python.org/msg399931 ___ Python tracker ___ ___ Python-bugs-list

[issue44958] [sqlite3] only reset statements when needed

Erlend E. Aasland added the comment: Ref. Serhiy's msg387858 in bpo-43350: "Maybe the code could be rewritten in more explicit way and call pysqlite_statement_reset() only when it is necessary [...]" Currently, we try to reset statements in all "statement exit" ro

[issue43350] [sqlite3] Active statements are reset twice in _pysqlite_query_execute()

duplicate stage: patch review -> resolved status: open -> closed superseder: -> [sqlite3] only reset statements when needed ___ Python tracker <https://bugs.python.org/issue43350> ___ __

[issue44958] [sqlite3] only reset statements when needed

Change by Erlend E. Aasland : -- keywords: +patch pull_requests: +26307 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27844 ___ Python tracker

[issue44958] [sqlite3] only reset statements when needed

New submission from Erlend E. Aasland : Ref. Serhiy's msg387858 in bpo-43350: "Maybe the code could be rewritten in more explicit way and call pysqlite_statement_reset() only when it is necessary [...]" Currently, we try to reset statements in all "statement exit" ro

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Łukasz Langa added the comment: New changeset 5502ee052fb4257ad7438dd1130c80e1a9c4bc7f by Miss Islington (bot) in branch '3.10': bpo-44600: Refactor new tracing tests (GH-27396) (GH-27404) https://github.com/python/cpython/commit/5502ee052fb4257ad7438dd1130c80e1a9c4bc7f -- nosy:

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- pull_requests: +25937 pull_request: https://github.com/python/cpython/pull/27404 ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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/38ddc8beb38d9a685de296a58b0741850e4853e5 --

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- pull_requests: +25930 pull_request: https://github.com/python/cpython/pull/27397 ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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

[issue44600] match/case statements trace incorrectly in 3.10.0b4

miss-islington added the comment: New changeset 01601aa7360ae51e74a64dbe957288096bb364fd by Miss Islington (bot) in branch '3.10': [3.10] bpo-44600: Fix line numbers for pattern matching cleanup code (GH-27346) (GH-27356)

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Brandt Bucher : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +25897 pull_request: https://github.com/python/cpython/pull/27356 ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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/4214f470f0cb9b6fef9a90758756fbc00ba95b5a

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Charles Burkland : -- keywords: +patch nosy: +chaburkland nosy_count: 6.0 -> 7.0 pull_requests: +25887 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27346 ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Brandt Bucher added the comment: Yup, I plan on having it in this weekend. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Pablo Galindo Salgado : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Pablo Galindo Salgado added the comment: The release candidate is soon, so I would recommend to land a fix as soon as possible so it can be tested for some time before is released, if that is possible. -- nosy: +pablogsal ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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 the same PR). --

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Jack DeVries added the comment: @brandtbucher, is anyone working on this yet? I'd like to take a crack at it this week if it's still available! -- nosy: +jack__d ___ Python tracker

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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 was (which I

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Ammar Askar added the comment: Brandt, maybe this regression test from a previous tracing bug might be useful for the test writing: https://github.com/python/cpython/pull/22026/files#diff-8b73bfc55514d8add8904c5f4d1d24b7b644ebfccba8d846085303577aa94dd6 -- nosy: +ammar2

[issue44600] match/case statements trace incorrectly in 3.10.0b4

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 compare

[issue44600] match/case statements trace incorrectly in 3.10.0b4

Change by Mark Shannon : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44600] match/case statements trace incorrectly in 3.10.0b4

New submission from Ned Batchelder : Some simple match/case statements show incorrect tracing. Below is the code to run, as well as the output. Output lines with initial stars are incorrect: they incorrectly indicate that case bodies are executing when they are not. Sorry for the bulk here

[issue38146] QVariant NULL returns anomalous values in equality statements

Change by Irit Katriel : -- stage: -> resolved status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38146] QVariant NULL returns anomalous values in equality statements

Irit Katriel added the comment: This looks like an issue with the way QVariant is defined. I'm not sure why you are reporting it as a Python bug? -- nosy: +iritkatriel resolution: -> third party status: open -> pending ___ Python tracker

[issue14445] Providing more fine-grained control over assert statements

Irit Katriel added the comment: I am closing this because there was no followup for over 9 years. If you are still interested in pursuing this, please raise it for discussion on python-ideas and open a new issue once there is agreement on how to proceed. -- nosy: +iritkatriel

[issue44283] Add jump table for certain safe match-case statements

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

[issue44283] Add jump table for certain safe match-case statements

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

[issue44283] Add jump table for certain safe match-case statements

Mark Shannon added the comment: This is going in the wrong direction. Rather than add more complex instructions for use only by pattern matching, we need to simplify the individual operations and re-use existing instructions. That way pattern matching can benefit from the general performance

[issue44283] Add jump table for certain safe match-case statements

Raymond Hettinger added the comment: > How common match-case statements with literal integers? Nothing is common yet because the feature hasn't been released ;-) I suspect that if match-case were optimized for integer constants, they would be used. In discussions about case stateme

[issue44283] Add jump table for certain safe match-case statements

Serhiy Storchaka added the comment: How common match-case statements with literal integers? I expect that in most cases such magic numbers are not used directly, but as named constants. -- nosy: +serhiy.storchaka ___ Python tracker <ht

[issue44283] Add jump table for certain safe match-case statements

Dennis Sweeney added the comment: Here are some benchmarks: PS C:\Users\sween\Source\Repos\cpython2\cpython> .\python.bat -m pyperf compare_to .\main.json .\PR-26697.json Running Release|x64 interpreter... 1: Mean +- std dev: [main] 117 us +- 4 us -> [PR-26697] 122 us +- 3 us: 1.04x slower

[issue44283] Add jump table for certain safe match-case statements

Change by Dennis Sweeney : -- keywords: +patch pull_requests: +25282 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26697 ___ Python tracker ___

[issue44283] Add jump table for certain safe match-case statements

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   3   4   5   6   7   8   9   10   >