[issue31080] Allow `logging.config.fileConfig` to accept kwargs
New submission from Preston Landers:
The function `logging.config.fileConfig` accepts `args` but it would be nice if
it also accepted `kwargs`.
A simple patch seems to do it:
diff --git a/Lib/logging/config.py b/Lib/logging/config.py
index d692514..4672b48 100644
--- a/Lib/logging/config.py
+++ b/Lib/logging/config.py
@@ -145,7 +145,9 @@ def _install_handlers(cp, formatters):
klass = _resolve(klass)
args = section["args"]
args = eval(args, vars(logging))
-h = klass(*args)
+kwargs = section.get("kwargs", '{}')
+kwargs = eval(kwargs, vars(logging))
+h = klass(*args, **kwargs)
if "level" in section:
level = section["level"]
h.setLevel(level)
Unless there are any objections I plan to submit a pull request. In my use case
I have a Pyramid service which
uses `concurrent-log-handler` and it seems better to be able to name keyword
args for file configuration.
--
components: Library (Lib)
messages: 299502
nosy: planders
priority: normal
severity: normal
status: open
title: Allow `logging.config.fileConfig` to accept kwargs
type: enhancement
___
Python tracker
<http://bugs.python.org/issue31080>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31080] Allow `logging.config.fileConfig` to accept kwargs
Preston Landers added the comment: This is the current state of my patch: https://github.com/python/cpython/compare/master...Preston-Landers:bpo-31080-fileconfig It makes both `args` and `kwargs` optional in the config file. (Obviously, the actual handler may require args.) -- ___ Python tracker <http://bugs.python.org/issue31080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31080] Allow `logging.config.fileConfig` to accept kwargs
Changes by Preston Landers : -- pull_requests: +3021 ___ Python tracker <http://bugs.python.org/issue31080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31080] Allow `logging.config.fileConfig` to accept kwargs
Preston Landers added the comment: A colleague pointed out that I used single quotes in the defaults where the line uses double quotes for another argument. I'm not sure if this is considered a problem but I could submit an update if it is. -- ___ Python tracker <http://bugs.python.org/issue31080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6
Changes by Preston Landers : -- nosy: +planders ___ Python tracker <http://bugs.python.org/issue29097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution
Change by Preston Landers : -- nosy: +planders ___ Python tracker <https://bugs.python.org/issue23102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1378] fromfd() and dup() for _socket on WIndows
Preston Landers added the comment: I'm curious what happened with this issue. It says closed+accepted but it doesn't appear to be checked in. Was there a fatal problem implementing this feature on Windows? Is it hung up on the inability to dup SSL sockets? I'm highly interested in deploying Python web servers using FastCGI, SCGI, WSGI, etc on the Windows server platform. I wrote a simple Windows fromfd() patch for Python 2.1 which was successfully used by my organization for many years. Now we are trying to move to a newer version of Python and still facing the need to patch this in. Just wondering what happened with this feature and perhaps there is something I can do to help move it along again. Many Python projects like flup, python-scgi, etc would be able to support Windows via this feature. (PS if this question is more appropriately raised on a mailing list rather than the issue tracker, I apologize in advance.) -- nosy: +planders ___ Python tracker <http://bugs.python.org/issue1378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1378] fromfd() and dup() for _socket on WIndows
Preston Landers added the comment: Hmm... revision 59004 appears to be unrelated to the main issue at hand. As far as I can tell now the status is this: the dup() and fromfd() support appears to be present in Python 3000 for Windows - at least the py3k branch. I didn't check the releases. But it's not present in 2.6 or trunk. I guess as far as I'm concerned that's fine. I'm going to use a patch to 2.6.3 to implement it for my purposes anyway. Thanks. -- ___ Python tracker <http://bugs.python.org/issue1378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28906] Can't inherit sockets with multiprocessing on Windows
New submission from Preston Landers: I'm porting a Python 2.6 based application to Python 3.6. This app uses a customized version of the "flup" package to do FastCGI services on Windows using the multiprocessing package. This requires a few sockets to be inherited across processes - the main FastCGI protocol socket plus a control socket. In Python 2.6, the `socket.from_fd` function was not available on Windows. However I patched Python's socketmodule.c to provide that function using DuplicateHandle. In Python 2.6's version of multiprocessing it spawned a process with CreateProcess and bInheritHandles=True. This worked well for me. Now I'm trying to get this working after moving from Python 2.6 to 3.6 (currently using 3.6.0b4). Fortunately, the socket module now has a working `socket.from_fd` on Windows so I no longer have to patch that. Unfortunately for me, though, the multiprocessing module now calls CreateProcess with bInheritHandles=False. This causes my scenario to fail. Here's a short test script which illustrates this problem: https://gist.github.com/Preston-Landers/712fee10fb557cf0b5592b57561a7c08 If you run with an unpatched multiprocessing, it will fail with an error like: OSError: [WinError 10038] An operation was attempted on something that is not a socket If you patch multiprocessing to set bInheritHandles=True this now works. (Change is in popen_spawn_win32.py where it does _winapi.CreateProcess.) I'm sure there's a good reason for that change in multiprocessing, whether for security or for unrelated/undesired file handles being passed. https://www.python.org/dev/peps/pep-0446/#inheritance-of-file-descriptors-on-windows However it does break my scenario and I don't see a way to tell multiprocessing to allow certain handles to be inherited. The docs for multiprocessing say "In particular, unnecessary file descriptors and handles from the parent process will not be inherited." It would be nice to have a way to tell it that my sockets are "necessary." You would think that calling socket.set_inheritable(True) would do it. In fact you must do that, but you must also pass bInheritHandles=True to CreateProcess for it to actually work. There doesn't seem to be a way to pass through an argument to multiprocessing to tell it to set this flag. I do realize I could be going about this completely wrong, though. But right now it looks like my immediate options are: a) Go ahead and patch my copy of popen_spawn_win32.py to allow inherited handles despite other possible risks. b) Try to rewrite things to not use multiprocessing at all and directly spawn my processes instead. That's not attractive because multiprocessing otherwise does what I need to do. Are there any other options I'm missing? Maybe some way to duplicate the socket on the other end without relying on CreateProcess with bInheritHandles=True? Otherwise, I guess I'm asking for an option to be made available in multiprocessing to allow handles to be inherited on Windows. -- components: Library (Lib) messages: 282723 nosy: planders priority: normal severity: normal status: open title: Can't inherit sockets with multiprocessing on Windows type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue28906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28906] Can't inherit sockets with multiprocessing on Windows
Preston Landers added the comment: Wow, good call. That does work for me. Wish I had thought to try it. I assume you want me to go ahead and close the issue. Sorry for the noise, but this really helps! -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue28906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
