Pythonic way to run the asyncio loop forever in python 3.10

outside the loop. While doing so, I have bumped against some common (I think) use-cases which seem to have no elegant solution anymore. At least I can't find one that seems "pythonic" or "correct". Problem: Before 3.10, asyncio.get_event_loop() was a convenient way to manag

[issue221129] makesetup loop

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

[issue489513] asyncore docs: no loop(), funny structur

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

[issue524804] breaking file iter loop leaves file in stale state

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

[issue489514] asyncore docs: no loop(), funny structur

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

[issue439993] infinite loop in re.match

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

[issue523859] unexpected endless loop

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

[issue462937] continue inside try confuses while loop

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

[issue463359] Interpreter generates infinite loop

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

[issue473223] Fix infinite getattr loop in asyncore

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

[issue452973] Tcl event loop callback woes

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

[issue439997] infinite loop in re.match

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

[issue216267] zlib.decompress memory allocation "infinite" loop

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue401138] 'for i indexing a in l': exposing the for-loop counter

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue221129] makesetup loop

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

[issue216267] zlib.decompress memory allocation "infinite" loop

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

[issue401138] 'for i indexing a in l': exposing the for-loop counter

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

[issue47210] './configure --help' causes infinite loop

ripspin added the comment: Bug closed because I get the same loop with python-3.10.4 -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/i

[issue47210] './configure --help' causes infinite loop

Ned Deily added the comment: Python 3.9.6 is no longer supported, 3.9.12 is the most recent 3.9.x release. Do you get the same results with 3.9.12? But, for what it's worth, ./configure --help of that 3.9.6 tarball works just fine on other current Linux systems I have available. --

[issue47210] './configure --help' causes infinite loop

ripspin added the comment: GNU bash, version 4.3.42(1)-release (x86_64-unknown-linux-gnu) uname -a Linux xenial64-sda1 4.9.58 #1 SMP PREEMPT Mon Nov 13 15:54:01 GMT 2017 x86_64 x86_64 x86_64 GNU/Linux -- ___ Python tracker

[issue47210] './configure --help' causes infinite loop

6654 nosy: ripspin5 priority: normal severity: normal status: open title: './configure --help' causes infinite loop type: compile error versions: Python 3.9 Added file: https://bugs.python.org/file50717/ttt1 ___ Python tracker <https://bugs.python.org/iss

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Jakub Kuczys added the comment: I'm not sure why this issue was mentioned in GH-32166 since it doesn't really address this but regardless, it appears that my issue has been fixed in PR-31388 and PR-31403 when Serhiy fixed the issue from bpo-46777 so thanks :) --

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Yury Selivanov added the comment: > I have a feeling that we need a low-level API section that describes > *supported* API that is intended to task extenders only (guys who want to > provide an alternative task factory for example). I'm not sure how exposing all private methods spiraled out

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

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

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Andrew Svetlov added the comment: New changeset ab89ccff3ca6efc2a8e6f5f45c30d568fb3d212f by Andrew Svetlov in branch 'main': bpo-45099: Document asyncio internal API (GH-32166) https://github.com/python/cpython/commit/ab89ccff3ca6efc2a8e6f5f45c30d568fb3d212f --

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Change by Andrew Svetlov : -- versions: +Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Change by Andrew Svetlov : -- keywords: +patch pull_requests: +30244 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32166 ___ Python tracker ___

[issue44036] asyncio SSL server can be DOSed, event loop gets blocked: busy loops and uses 100% CPU

Andrew Svetlov added the comment: Could you check Python 3.11? It has a new asyncio SSL implementation rewritten from scratch. -- ___ Python tracker ___

[issue47077] test_asyncio ignores exception in _ProactorBasePipeTransport.__del__: RuntimeError('Event loop is closed')

Andrew Svetlov added the comment: Perhaps the proactor should just silently skip protocol events if the event loop is closed. Selector-based event loops do it implicitly already. -- ___ Python tracker <https://bugs.python.org/issue47

[issue47014] ProactorEventLoop ignores Ctrl+C after closing unrelated loop

Change by Andrew Svetlov : -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue25489] sys.exit() caught in async event loop exception handler

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25489] sys.exit() caught in async event loop exception handler

Guido van Rossum added the comment: Andrew, thanks for explaining this. The key thing I was missing was that the root cause of the problem is that Future.__del__ is trying to log an error about the un-awaited task by calling the exception handler directly. That actually feels a little

[issue25489] sys.exit() caught in async event loop exception handler

Andrew Svetlov added the comment: Guido, perhaps you had problems with the problem detection because the asyncio uses _asyncio C Extesions by default. It drops some calls from the python stack trace. -- ___ Python tracker

[issue25489] sys.exit() caught in async event loop exception handler

an endless recursion. c) asyncio loop can call `loop.stop()` if an exception is raised by `loop.call_exception_handler()` from __del__. I think this behavior is terrible: a subtle error can terminate asyncio program. d) Assume that a custom exception handler should not raise an exception. Catch all

[issue47077] test_asyncio ignores exception in _ProactorBasePipeTransport.__del__: RuntimeError('Event loop is closed')

y", line 758, in call_soon self._check_closed() File "D:\buildarea\3.x.ware-win81-release.refleak\build\Lib\asyncio\base_events.py", line 519, in _check_closed raise RuntimeError('Event loop is closed') ^^ RuntimeError: Event loop

[issue25489] sys.exit() caught in async event loop exception handler

Change by Gregory P. Smith : -- title: sys.exit() caught in exception handler -> sys.exit() caught in async event loop exception handler ___ Python tracker <https://bugs.python.org/issu

[issue44075] Add a PEP578 audit hook for Asyncio loop stalls

Andrew Svetlov added the comment: I am still not convinced that audit events should be used. Maybe support of explicit callbacks pair (on_start() + on_finish()) with `None` for fast-and-cheap "do nothing flag" is a better alternative for catching stale coroutines? --

[issue42838] Wait for cleanup coroutines before event loop is closed.

Change by xloem <0xl...@gmail.com>: -- resolution: wont fix -> out of date ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42838] Wait for cleanup coroutines before event loop is closed.

Change by xloem <0xl...@gmail.com>: -- resolution: out of date -> wont fix ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42838] Wait for cleanup coroutines before event loop is closed.

xloem <0xl...@gmail.com> added the comment: hey, I don't have the capacity to stay on this, but thanks for the attention, time, and clear response. there are of course other situations such as returning a resource to library code or manual loop management, but I don't have the us

[issue46223] asyncio cause infinite loop during debug

Andrew Svetlov added the comment: Fixed by #47039 -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Normalize asyncio future and task repr() ___ Python tracker

[issue42838] Wait for cleanup coroutines before event loop is closed.

Andrew Svetlov added the comment: asyncio.run() present since Python 3.7 After the main coroutine finish, it cancels all background tasks and waits for their termination. Background tasks can use old good `try/finally` for resources cleanup. An additional API is not required IMHO.

[issue42838] Wait for cleanup coroutines before event loop is closed.

xloem <0xl...@gmail.com> added the comment: I'm sorry, is this closure an error? Could you explain more how to use asyncio.run() to clean up resources when an unhandled exception is thrown? Is this new with a recent python improvement? -- status: closed -> open

[issue42683] asyncio should handle keyboard interrupt while the event loop is running

Andrew Svetlov added the comment: Duplicate for #39622 -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> KeyboardInterrupt is ignored when await asyncio.sleep(0) ___ Python tracker

[issue42838] Wait for cleanup coroutines before event loop is closed.

Andrew Svetlov added the comment: asyncio.run() does the task -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___

[issue42941] Infinite loop in asyncio sslproto

Andrew Svetlov added the comment: sslproto was rewritten from scratch in Python 3.11 -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker

Re: basic question on loop & type casting / list/str/array

Kiran Kumar wrote: Hi. Pls check on below poython 3.9.x code & suggest how can i keep the string intactst in 2nd loop... ? these are aws ec2 ids Don't loop through it then. -- https://mail.python.org/mailman/listinfo/python-list

basic question on loop & type casting / list/str/array

Hi. Pls check on below poython 3.9.x code & suggest how can i keep the string intactst in 2nd loop... ? these are aws ec2 ids >>> INSTANCE_ID = ['i-0dccf1ede229ce1','i-0285506fee62051'] >>> for i in INSTANCE_ID: ... print (i) ... i-0dccf1ede229ce1 i-0285506fee62051

[issue47014] ProactorEventLoop ignores Ctrl+C after closing unrelated loop

Andrew Svetlov added the comment: Ctrl-C handling is added by #23057 It uses signal.set_wakeup_fd() https://github.com/asvetlov/cpython/blob/main/Lib/asyncio/proactor_events.py#L631-L634 So, the last event loop steals Ctrl+C handling. Not sure if we can improve it. Running two concurrent

[issue47014] ProactorEventLoop ignores Ctrl+C after closing unrelated loop

loop fixes the behavior. I couldn't find any shared/global objects in asyncio/windows_events.py, so I'm not sure what is causing this, or why the wakeup task helps. FWIW, the second event loop in our code base originated from a stray `get_event_loop()` call, one more example that speaks in favor

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: Thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

Jonathan Fine added the comment: My main concern is that the door not be closed on improving the user experience relating to this behaviour of the compiler. This issue was raised as a bug for the compiler (which is C-coded). I'd be very happy for this issue to be closed as 'not a bug' for

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

Pablo Galindo Salgado added the comment: Unfortunately that's not how the parser works. I insist, for the compiler to raise the propper error the parser needs to succeed first. That would require us to modify the input string in arbitrary ways (many times we don't know exactly what went

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

, line 18, in compile_fix(src.read(), filename, 'exec') File "funny_break_error_fix.py", line 9, in compile_fix compile(new_source, filename, 'exec') File "funny_break_error.py", line 5 break ^ SyntaxError: 'break' outside loop === And in this case we've got

[issue46908] Debugger jumps to a wrong instruction in for loop

Vedran Čačić added the comment: pdb on Py3.10.2 works fine with that code. -- nosy: +veky ___ Python tracker ___ ___

[issue46908] Debugger jumps to a wrong instruction in for loop

Change by Brandt Bucher : -- nosy: +brandtbucher ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

Pablo Galindo Salgado added the comment: Unfortunately, we cannot do much here. The reason is that the parser allows break and continue outside loops as they count as statements. As these are associated with control flow, is the compiler the one that will show the Syntax warning once it

[issue46908] Debugger jumps to a wrong instruction in for loop

Mark Shannon added the comment: Which debugger? Which version of Python? Please provide all the steps required to reproduce, otherwise there is little we can do. -- nosy: +Mark.Shannon ___ Python tracker

[issue45065] test_asyncio failed (env changed) on s390x RHEL8 Refleaks 3.10: RuntimeError('Event loop is closed') in _SSLProtocolTransport.__del__

STINNER Victor added the comment: I didn't see this issue recently, I close the issue. -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue45065] test_asyncio failed (env changed) on s390x RHEL8 Refleaks 3.10: RuntimeError('Event loop is closed') in _SSLProtocolTransport.__del__

Kumar Aditya added the comment: asyncio ssl implementation has been rewritten with bpo-44011: This is outdated now and should be closed @vstinner. -- nosy: +kumaraditya303 ___ Python tracker

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

/cpython/main.py:12: DeprecationWarning: There is no current event loop loop = asyncio.get_event_loop() /workspaces/cpython/env/lib/python3.11/site-packages/certifi/core.py:36: DeprecationWarning: path is deprecated. Use files() instead. Refer to https://importlib-resources.readthedocs.io/en/latest

[issue46910] Expect IndentationError, get SyntaxError: 'break' outside loop

move the last two lines and you get the more helpful error === $ python3.8 funny_break_error.py File "funny_break_error.py", line 5 break ^ SyntaxError: 'break' outside loop === Python3.6 and 3.7 also behave as above. Note. I've heard that blind Python programmers prefer a

[issue46908] Debugger jumps to a wrong instruction in for loop

New submission from Francisco Arenas Afán de Rivera : I found that the debugger doesn't follow the normal program order when executing a foor loop with more than 3 instructions inside and one loop. code example: a = 0 b = 0 c = 0 for i in range(1): a += 1 b += 1 # Set breakpoint here

[issue46796] Simplify handling of removed parameter "loop" in asyncio

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

[issue46796] Simplify handling of removed parameter "loop" in asyncio

Andrew Svetlov added the comment: New changeset 195a46d6ffd4cec6c5fb69c5890f8b1758ac91ca by Serhiy Storchaka in branch 'main': bpo-46796: Simplify handling of removed parameter "loop" in asyncio (GH-31431) https://github.com/python/cpython/commit/195a46d6ffd4cec6c5fb69c5890f8b

[issue46796] Simplify handling of removed parameter "loop" in asyncio

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +29566 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31431 ___ Python tracker

[issue46796] Simplify handling of removed parameter "loop" in asyncio

New submission from Serhiy Storchaka : Before 3.10 many asyncio classes did have an optional parameter "loop". It was deprecated in 3.8. To simplify the code, such classes inherited a constructor from _LoopBoundMixin which set the _loop attribute and (since 3.8) emitted a warning i

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Andrew Svetlov added the comment: I have a feeling that we need a low-level API section that describes *supported* API that is intended to task extenders only (guys who want to provide an alternative task factory for example). I love to contribute but not sure when I can find time for this

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

jack1142 added the comment: I'm aware, I'm reporting this because as long as the instantiation of a Task is documented, the documentation should still contain accurate up-to-date information. -- ___ Python tracker

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

Andrew Svetlov added the comment: User code should not create Task objects explicitly. Please use `asyncio.create_task()` (or shiny new TaskGroup.create_task()) instead. They doesn't have 'loop' argument. -- ___ Python tracker <ht

[issue46565] Delete module-level loop variables when no longer needed

Serhiy Storchaka added the comment: New changeset 0cbdd2131195b0d313762968f604e80a3e65ca9f by Nikita Sobolev in branch 'main': bpo-46565: `del` loop vars that are leaking into module namespaces (GH-30993) https://github.com/python/cpython/commit/0cbdd2131195b0d313762968f604e80a3e65ca9f

[issue46565] Delete module-level loop variables when no longer needed

Alex Waygood added the comment: I agree that the typeshed issue is less important than the output of dir() and help(). I also agree that we shouldn't make a fetish of typing. However, I see the typeshed issue less as an issue specific to typing, and more as an example that illustrates a

[issue46565] Delete module-level loop variables when no longer needed

Nikita Sobolev added the comment: Thanks for the better wording, Terry! > Leaving loop variables available is an intended feature of python. Just to be clear: it sure is! But, sometimes we don't want to polute a global namespace with this variable. A common practice across CPython's sou

[issue46565] Delete module-level loop variables when no longer needed

Terry J. Reedy added the comment: I am opposed at this time. Leaving loop variables available is an intended feature of python. After reading point 1, I was tempted to say that you are making a fetish of typing or making the tail wag the dog. I mention this because others might have

[issue46565] Multiple modules leak `for` loop variables into module's namespace

Alex Waygood added the comment: +1 for the proposed PR. Loop variables leaking into the global namespace creates an extra burden for typeshed when we have to wade through a long list of objects that our tests report are present at runtime but not in the typeshed stubs. It's not the end

[issue46565] Multiple modules leak `for` loop variables into module's namespace

Change by Zachary Ware : -- nosy: +zach.ware ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46565] Multiple modules leak `for` loop variables into module's namespace

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29173 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30993 ___ Python tracker ___

[issue46565] Multiple modules leak `for` loop variables into module's namespace

Change by Nikita Sobolev : -- nosy: +AlexWaygood ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46565] Multiple modules leak `for` loop variables into module's namespace

New submission from Nikita Sobolev : Some variables created as `for X in ...` leak into module's namespace, where the loop is defined. I wrote a simple `flake8` plugin to find names that are used in `ast.Module` in `ast.For`, but not under `if __name__ == '__main__'` and are not used in `del

[issue46547] `pydoc.Helper` leaks several `for` loop variables

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29136 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30957 ___ Python tracker ___

[issue46547] `pydoc.Helper` leaks several `for` loop variables

: ``` >>> import pydoc >>> pydoc.Helper.symbol 'J' >>> pydoc.Helper.topic 'COMPLEX' >>> pydoc.Helper.symbols_ ('j', 'J') ``` There's also `topics` var, but it is shadowed later. So, I propose deleting all intermediate variables right after the `for` loop. -

[issue38487] expat infinite loop

. In a way, the current approach is equivalent to walking up the stack as expected but never going back down. Once I make the code use a stack, the loop goes away. I'm pasting the patch inline (with two spaces indented globally) below. During debugging, these are commands I used to compare internal

[issue46536] Better for loop

Eric V. Smith added the comment: Thank you for the suggestion. This is unlikely to gain acceptance. zip is usable in places outside of for loops, whereas your suggestion appears to be only useful in for loops. In addition, I don't see a way to specify the "strict" option using your syntax.

[issue46536] Better for loop

Change by Anonymous : -- nosy: +me -vividnversatile1 resolution: -> not a bug ___ Python tracker ___ ___ Python-bugs-list mailing

[issue46536] Better for loop

tter for loop type: enhancement ___ Python tracker <https://bugs.python.org/issue46536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/opti

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Change by Dong-hee Na : -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Dong-hee Na added the comment: New changeset 38afeb1a336f0451c0db86df567ef726f49f6438 by Erlend Egeberg Aasland in branch 'main': bpo-46249: Move set lastrowid out of the sqlite3 query loop (GH-30489) https://github.com/python/cpython/commit/38afeb1a336f0451c0db86df567ef726f49f6438

[issue46223] asyncio cause infinite loop during debug

aaron added the comment: '@reprlib.recursive_repr' decorator to 'events.Handle.__repr__()' could you tell me which file should I change? and why? -- ___ Python tracker ___

[issue46223] asyncio cause infinite loop during debug

aaron added the comment: "When running code in debug mode" means we're debug the code. We have used both vscode and pycharm. Same result. -- ___ Python tracker ___

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Marc-Andre Lemburg added the comment: On 11.01.2022 21:30, Erlend E. Aasland wrote: > >> I'd suggest to deprecate the cursor.lastrowid attribute and >> instead point people to the much more useful [...] > > Yes, I think mentioning the RETURNING ROWID trick in the sqlite3 docs is a > very

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Erlend E. Aasland added the comment: > You don't know on which cursor the last row was inserted [...] SQLite has no concept of cursors :) > It also seems that the function really only works for INSERTs and > not for UPDATEs. Yes, hence it's name: sqlite3_last_insert_rowid() ! > I'd suggest

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Marc-Andre Lemburg added the comment: On 11.01.2022 20:46, Erlend E. Aasland wrote: > > If we are to revert to this behaviour, we'll have to start examining the SQL > we are given (search for INSERT and REPLACE keywords, determine if they are > valid (i.e. not a comment, not part of a column

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Erlend E. Aasland added the comment: > OTOH, the SQLite API is tied to the _connection_ object, so it may not make > sense to align it with lastrowid which is a _cursor_ attribute. That came out weird; let's try again: The SQLite API is tied to the _connection_ object, so it may not make

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

Erlend E. Aasland added the comment: > Is 0 a valid row ID in SQLite ? If not, then I guess this would be > an alternative to None as suggested by the DB-API. Yes. Any 64 bit signed integer value is a valid row id in SQLite. > If it is a valid row ID, I'd suggest to go back to resetting to

[issue46249] [sqlite3] move set lastrowid out of the query loop and enable it for executemany()

ing to the UPDATE and not a previous operation, since code will now know whether the condition was met or not. -- Marc-Andre Lemburg eGenix.com ------ title: [sqlite3] lastrowid improvements -> [sqlite3] move set lastrowid out of the query loop and enable it for executema

[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`

Andrew Svetlov added the comment: New changeset fc75bfb8be8494e22123f2c14d1ab497c77cc22d by Nikita Sobolev in branch 'main': bpo-46310: simplify `for` loop in `asyncio/windows_events` (GH-30334) https://github.com/python/cpython/commit/fc75bfb8be8494e22123f2c14d1ab497c77cc22d

[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`

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

[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`

Change by Kumar Aditya : -- components: +asyncio -Library (Lib) nosy: +kumaraditya303, yselivanov ___ Python tracker ___ ___

[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`

Change by Nikita Sobolev : -- keywords: +patch pull_requests: +28701 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30334 ___ Python tracker ___

[issue46310] Simplify `for` loop in `.close()` method in `asyncio/windows_events`

, because unused variables are not created And since it does not break anything, I think it is safe to refactor. -- assignee: sobolevn components: Library (Lib) messages: 410136 nosy: asvetlov, eric.araujo, sobolevn priority: normal severity: normal status: open title: Simplify `for` loop

  1   2   3   4   5   6   7   8   9   10   >