[issue41483] Do not acquire lock in MemoryHandler.flush() if no target defined
Kostis Anagnostopoulos added the comment: Have nothing else to say on top of what iritkatriel discovered, a double-check would be needed, but may be a pointless speed up, if MemoryHandler is impossible to work without a `target`. Fixing the no-target error is more important. Actually that's how i came to notice this optimization. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue41483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41483] Do not acquire lock in MemoryHandler.flush() if no target defined
New submission from Kostis Anagnostopoulos : The `logging.handlers.MemoryHandler.flush()` method acquire the lock even if target has not been set, and the method is a noop: ``` def flush(self): # (Docstring skipped) self.acquire() try: if self.target: for record in self.buffer: self.target.handle(record) self.buffer..clear() finally: self.release() ``` An optimized version would re-arrrange the nesting to avoid the locking: ``` def flush(self): # (Docstring skipped) if self.target: self.acquire() try: for record in self.buffer: self.target.handle(record) self.buffer.clear() finally: self.release() ``` - There is no use-case, beyond the expected performance gain. - Without having searched, i would deem highly improbable the existence of code in the std-library or 3rdp code that depends on the current noop-locking when `flush()` is called. -- components: Library (Lib) messages: 374859 nosy: ankostis, penlect, vinay.sajip priority: normal severity: normal status: open title: Do not acquire lock in MemoryHandler.flush() if no target defined type: performance versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode
Kostis Anagnostopoulos added the comment: > > BTW, i went back to my code and pasted what seemed to cure the problem, > added in commit 2b99cec in my PR. But i don't have much time to track if it really works. I hope it will help you resolve the issue. Best, Kostis -- ___ Python tracker <https://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode
Kostis Anagnostopoulos added the comment: Dear Sanyam, My apologies, it's been almost a year that i don't need the fix for this code, my app has been graciously decommissioned, and i don;t have any time for it. Best, Kostis On Fri, 9 Aug 2019 at 21:35, Sanyam Khurana wrote: > > Sanyam Khurana added the comment: > > Hey ankostis, > > Please let us know if you've time to complete the PR. > > Thank you :) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue26543> > ___ > -- ___ Python tracker <https://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29757] The loop in utility `socket.create_connection()` swallows previous errors
Kostis Anagnostopoulos added the comment: The problem of not fixing this (and just add a suggestion in the docs saying that the user may re-implement this method) is that frequently this call is hidden at the core of many networking libraries. So monkey-patching is needed instead, which is not always nice or easy. > I just found an old bug in socket.create_connection(): > https://github.com/python/cpython/pull/3546 Regarding #3546, i'm surprised that a function-local variable keeps its contents alive, long after the frame of that function has gone. I thought that local-variables were deterministically (ref-countering) destructed. What is happening? -- ___ Python tracker <https://bugs.python.org/issue29757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] imaplib noop Debug
Changes by Kostis Anagnostopoulos : -- pull_requests: +1605 ___ Python tracker <http://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] imaplib noop Debug
Kostis Anagnostopoulos added the comment: That is a show-stopper, and the patch works fine. Should I submit a PR with a special test-case with debug >= 3 just for this? -- nosy: +ankostis ___ Python tracker <http://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Kostis Anagnostopoulos added the comment: Before merging `imaplib2` please consider making proper use of the Python's standard `logging` module. -- nosy: +ankostis ___ Python tracker <http://bugs.python.org/issue11245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29757] The loop in utility `socket.create_connection()` swallows previous errors
Kostis Anagnostopoulos added the comment: Just to remind that as it stands now(b39d4b1c6) it contains no API changes at all, so it should be considered for merge into 3.6.x line. -- ___ Python tracker <http://bugs.python.org/issue29757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29757] The loop in utility `socket.create_connection()` swallows previous errors
Kostis Anagnostopoulos added the comment: > This is a new feature, so we can only push it to 3.7. As it stands now(b39d4b1c6) it hardly contains any change - just in the case of multiple intermediate errors AND final failure, the exception raised is a bit different. AFAICS it would be a "change" for 3.7 if my one of the 3 options of my last comment gets implemented. Any ideas which one to implement? -- ___ Python tracker <http://bugs.python.org/issue29757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29757] The loop in utility `socket.create_connection()` swallows previous errors
Kostis Anagnostopoulos added the comment:
> When the list of errors is passed as a second argument to the exception, how
> is it rendered?
This is how my latest ec887c0c3 looks on Linux:
>>> import socket
>>> socket.create_connection(('localhost', 12345))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/socket.py", line 714, in create_connection
raise error("no connection possible due to %d errors" % nerr, errors)
OSError: [Errno no connection possible due to 2 errors]
[ConnectionRefusedError(111, 'Connection refused'), ConnectionRefusedError(111,
'Connection refused')]
And this is on Windows:
>>> socket.create_connection(('localhost', 12345), 1)
Traceback (most recent call last):
File
"D:\Apps\WinPython-64bit-3.5.3.0Qt5\python-3.5.3.amd64\lib\site-packages\IPython\core\interactiveshell.py",
line 2881, in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
File "", line 1, in
socket.create_connection(('localhost', 12345), 1)
File
"D:\Apps\WinPython-64bit-3.5.3.0Qt5\python-3.5.3.amd64\lib\socket.py", line
714, in create_connection
raise error("no connection possible due to %d errors" % nerr, errors)
OSError: [Errno no connection possible due to 2 errors] [timeout('timed
out',), timeout('timed out',)]
> Would it make sense to concatenate all error messages:
But then the user will not receive a list of errors to inspect, but just a big
string.
The biggest problem in my latest ec887c0c3 is that I'm abusing the 1st arg to
OSError() constructor, instead of being an `errno` it is a string.
But I got that from the existing code.[1]
And still, this PR is not yer finished because there is no feedback on any
intermediate errors in the case of success.
As suggested on the OP, this may happen (in my order of preference):
1. with a new argument for the user to provide the list to collect the errors
(changes the API backward-compatiblly);
2. with logging logs;
3. with warnings;
4. do nothing.
I prefer logging over warnings because they are more configurable.
[1] https://github.com/python/cpython/blob/master/Lib/socket.py#L724
--
___
Python tracker
<http://bugs.python.org/issue29757>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29757] The loop in utility `socket.create_connection()` swallows previous errors
New submission from Kostis Anagnostopoulos: ## Context The utility method `socket.create_connection()` currently works like that: 1. resolve the destination-address into one or more IP(v4 & v6) addresses; 2. loop on each IP address and stop to the 1st one to work; 3. if none works, re-raise the last error. ## The problem So currently the loop in `socket.create_connection()` ignores all intermediate errors and reports only the last connection failure, which might be irrelevant. For instance, when both IPv4 & IPv6 networks are supported, usually the last address is a IPv6 address and it frequently fails with an irrelevant error - the actual cause have already been ignored. ## Possible solutions & open questions To facilitate network debugging, there are at least 3 options: a. log each failure [as they happen](/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/socket.py#L717), but that would get the final failure twice: once as a (warning?) message, and once as an exception . b. collect all failures and log them only when connection fails to collect the errors, but that might miss important infos to the user; c. collect and return all failures in list attached to the raised exception. A question for cases (a) & (b) is what logging "means" to use: the `warnings` or `logging` module? And if `logging` is chosen, log them in `'DEBUG'` or `'WARNING'` level? Case (c) sidesteps the above questions. -- components: Library (Lib) messages: 289238 nosy: ankostis priority: normal pull_requests: 463 severity: normal status: open title: The loop in utility `socket.create_connection()` swallows previous errors versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
