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

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

Kumar Aditya added the comment: The original issue is fixed on main branch with bpo-44011 GH-31275, It now only raises warnings but no exceptions: --- (env) @kumaraditya303 ➜ /workspaces/cpython (latin1 ✗) $ python main.py

[issue42206] Pegen: Raise errors occurred by the AST validator

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

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: New changeset 3af4b585527743e455145d294049c46b7c823ed9 by Batuhan Taskaya in branch 'master': bpo-42206: Propagate and raise errors from PyAST_Validate in the parser (GH-23035) https://github.com/python/cpython/commit

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: This will slow down the parser massively. The reason we went' with the assert is so we only do the check in debug mode. We could propagate if you want, but it needs to be surrounded by debug preprocessor checks. --

[issue42206] Pegen: Raise errors occurred by the AST validator

Pablo Galindo Salgado added the comment: > This will slow down the parser massively. The reason we went' with the assert > is so we only do the check in debug mode. We could propagate if you want, but > it needs to be surrounded by debug preprocessor checks. Oh, I just checked and it

[issue42206] Pegen: Raise errors occurred by the AST validator

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +21954 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23035 ___ Python tracker ___

[issue42206] Pegen: Raise errors occurred by the AST validator

`PyAST_Validate(res)' failed. Proposed: $ ./python t.py ValueError: Test AST error raised by the Python/ast.c -- components: Interpreter Core messages: 379941 nosy: BTaskaya, gvanrossum, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: Pegen: Raise errors occurred

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

Christian Heimes added the comment: This seems to be an asyncio problem. -- assignee: christian.heimes -> ___ Python tracker ___

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

Andrew Svetlov added the comment: Sorry, I'm not comfortable with such change just before the feature freeze. The idea is maybe good but let's discuss and implement it later. -- ___ Python tracker

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

Yury Selivanov added the comment: > Not sure if we have to drop this warning, it enforces writing good code that > controls all created resources lifecycle. Right, maybe we add "transport.terminate()" as well? Synchronously & immediately closing a transport is a valid use case. TBH I

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

Andrew Svetlov added the comment: It's not about streams only. The stream protocol can have such flag, sure. But transport emits a warning like "unclosed transport ..." Not sure if we have to drop this warning, it enforces writing good code that controls all created resources lifecycle.

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

Yury Selivanov added the comment: > Sorry, that's how asyncio is designed. Andrew, couldn't we provide a "stream.terminate()" method (not a coroutine) that would do the following: * close the transport * set a flag in the protocol that the stream has been terminated. When the flag is set,

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

Andrew Svetlov added the comment: The difference is that socket.close() is an instant call. After socket.close() the socket is done. But transport.close() doesn't close the transport instantly. asyncio requires at least one loop iteration for calling protocol.connection_lost() and actual

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

Tom Christie added the comment: Right, and `requests` *does* provide both those styles. The point more being that *not* having closed the transport at the point of exit shouldn't end up raising a hard error. It doesn't raise errors in sync-land, and it shouldn't do so in async-land

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

Andrew Svetlov added the comment: I would say that if requests a designed from scratch more idiomatic way could be with requests.Session() as session: session.get('https://example.com/') or session = requests.Session() session.get('https://example.com/') session.close() Like the

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

Tom Christie added the comment: > From my understanding, the correct code should close all transports and wait > for their connection_lost() callbacks before closing the loop. Ideally, yes, although we should be able to expect that an SSL connection that hasn't been gracefully closed

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

Andrew Svetlov added the comment: >From my understanding, the correct code should close all transports and wait >for their connection_lost() callbacks before closing the loop. -- ___ Python tracker

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

Tom Christie added the comment: This appears somewhat related: https://bugs.python.org/issue34506 As it *also* logs exceptions occuring during `_fatal_error` and `_force_close`. -- ___ Python tracker

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

already been closed uncleanly. Bought to my attention via: https://github.com/encode/httpcore/issues/16 -- assignee: christian.heimes components: SSL, asyncio messages: 340764 nosy: asvetlov, christian.heimes, tomchristie, yselivanov priority: normal severity: normal stat

[issue26685] Raise errors from socket.close()

STINNER Victor added the comment: New changeset 580cd5cd3603317d294a881628880a92ea221334 by Victor Stinner in branch '3.6': bpo-30319: socket.close() now ignores ECONNRESET (#2565) (#2566) https://github.com/python/cpython/commit/580cd5cd3603317d294a881628880a92ea221334 --

[issue26685] Raise errors from socket.close()

Changes by STINNER Victor : -- pull_requests: +2636 ___ Python tracker ___ ___

[issue26685] Raise errors from socket.close()

STINNER Victor added the comment: New changeset 67e1478dba6efe60b8e1890192014b8b06dd6bd9 by Victor Stinner in branch 'master': bpo-30319: socket.close() now ignores ECONNRESET (#2565) https://github.com/python/cpython/commit/67e1478dba6efe60b8e1890192014b8b06dd6bd9 --

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: >> Would you mind to open an issue specific for asyncio? > I'll open an issue on GH today to discuss with you/Guido/asyncio devs. Guido, Victor, please take a look: https://github.com/python/asyncio/pull/449 -- ___

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: > Ah, you became reasonable :-D Come on... :) > Would you mind to open an issue specific for asyncio? I'll open an issue on GH today to discuss with you/Guido/asyncio devs. -- ___ Python tracker

[issue26685] Raise errors from socket.close()

STINNER Victor added the comment: "After thinking about this problem for a while, I arrived to the conclusion that we need to fix asyncio." Ah, you became reasonable :-D "Essentially, when a user passes a socket object to the event loop API like 'create_server', they give up the control of

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: After thinking about this problem for a while, I arrived to the conclusion that we need to fix asyncio. Essentially, when a user passes a socket object to the event loop API like 'create_server', they give up the control of the socket to the loop. The loop

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: Maybe we should fix asyncio. Maybe if a user passes an existing socket object into loop.create_connection, it should duplicate the socket. -- ___ Python tracker

[issue26685] Raise errors from socket.close()

STINNER Victor added the comment: > My proposal: ignore EBADF in socket.close(). It means that the socket is > closed already. It doesn't matter why. As Martin explained, getting EBAD means that your code smells. Your code may close completely unrelated file descriptor... Say hello to race

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: My proposal: ignore EBADF in socket.close(). It means that the socket is closed already. It doesn't matter why. -- ___ Python tracker

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: Another example: some asyncio (run with uvloop) code: conn, _ = lsock.accept() f = loop.create_task( loop.connect_accepted_socket( proto_factory, conn)) # More code loop.run_forever()

[issue26685] Raise errors from socket.close()

Martin Panter added the comment: If libuv closes the FD (step 3), won’t you get the same sort of problem if the uvloop user tries to do something else with the Python socket object, e.g. call getpeername()? I see the fileno=... parameter for sockets as a parallel to the os.fdopen() function,

[issue26685] Raise errors from socket.close()

Martin Panter added the comment: I think your code example is not very robust, because the “sock” object refers to a freed file descriptor, and could easily close an unrelated file: $ python3.5 -q >>> import socket >>> sock0 = socket.socket() >>> sock = socket.socket(fileno=sock0.fileno()) >>>

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: IOW, what is happening in uvloop: 1. A user has a Python socket object and passes it asyncio (run with uvloop) API. 2. uvloop extracts the FD of the socket, and passes it to low-level libuv. 3. At some point of time, libuv closes the FD. 4. When user tries

[issue26685] Raise errors from socket.close()

Yury Selivanov added the comment: I think this patch should be reverted. It breaks backwards compatibility: import socket sock0 = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0) sock = socket.socket( socket.AF_INET, socket.SOCK_STREAM, 0, sock0.fileno())

[issue26685] Raise errors from socket.close()

Martin Panter added the comment: I tweaked the test again for Windows, anticipating that it will raise ENOTSOCK rather than EBADF. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue26685] Raise errors from socket.close()

Roundup Robot added the comment: New changeset bd665613ed67 by Martin Panter in branch 'default': Issue #26685: Raise OSError if closing a socket fails https://hg.python.org/cpython/rev/bd665613ed67 -- nosy: +python-dev ___ Python tracker

[issue26685] Raise errors from socket.close()

Martin Panter added the comment: Here is socket.close.v2.patch which hopefully fixes the test for Windows (still untested by me though) -- Added file: http://bugs.python.org/file42361/socket.close.v2.patch ___ Python tracker

[issue26685] Raise errors from socket.close()

Martin Panter added the comment: Victor suggested making these errors be reported by the finalize method (garbage collection). I started investigating this, but faced various test suite failures (test_io, test_curses), as well as many new unhandled exceptions printed out during the tests

[issue26685] Raise errors from socket.close()

STINNER Victor added the comment: I like the idea :-) -- nosy: +haypo ___ Python tracker ___ ___

[issue26685] Raise errors from socket.close()

Changes by Martin Panter : -- dependencies: +test_fileno of test_urllibnet intermittently fails ___ Python tracker ___

[issue26685] Raise errors from socket.close()

EBADF would be more easily noticed. -- components: Extension Modules files: socket.close.patch keywords: patch messages: 262735 nosy: martin.panter priority: normal severity: normal stage: patch review status: open title: Raise errors from socket.close() type: enhancement versions: Python 3.6

Re: raise errors

En Mon, 21 Sep 2009 06:17:20 -0300, daved170 daved...@gmail.com escribió: I need help with exceptions raising. My goal is to print at the outer functions all the errors including the most inner one. The default exception report contains a lot of information, you don't have to do anything

raise errors

Hi everybody, I need help with exceptions raising. My goal is to print at the outer functions all the errors including the most inner one. For example: def foo1(self): try: foo2() except ? : print outer Err at foo1 + ?? def foo2(self): try: error occured

Re: raise errors

daved170 wrote: I need help with exceptions raising. My goal is to print at the outer functions all the errors including the most inner one. For example: def foo1(self): try: foo2() except ? : print outer Err at foo1 + ?? def foo2(self): try:

Re: raise errors

daved170 wrote: I need help with exceptions raising. My goal is to print at the outer functions all the errors including the most inner one. For example: def foo1(self): try: foo2() except ? : print outer Err at foo1 + ?? def foo2(self): try:

Re: raise errors

On Mon, Sep 21, 2009 at 5:17 AM, daved170 daved...@gmail.com wrote: Hi everybody, I need help with exceptions raising. My goal is to print at the outer functions all the errors including the most inner one. For example: def foo1(self):   try:        foo2()   except ? :         print