[issue39467] Allow to deprecate CLI arguments in argparse
New submission from hervé : Today it's not possible to deprecate CLI arguments designed with argparse, it could be useful to introduce deprecation feature in argparse to allow developers to inform their apps's users when an argument is planed to be removed in the future. -- components: Library (Lib) messages: 360786 nosy: 4383 priority: normal severity: normal status: open title: Allow to deprecate CLI arguments in argparse type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39467] Allow to deprecate CLI arguments in argparse
Change by hervé : -- keywords: +patch pull_requests: +17585 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18208 ___ Python tracker <https://bugs.python.org/issue39467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39467] Allow to deprecate CLI arguments in argparse
hervé added the comment: First, thanks Raymond for your worth useful comment. * Concerning the usage of the warning module what do you suggest to use then? To use "print"? * Concerning "hook or flag" and the 3 new params in my PR, I think developers would appreciate to give a customized message to their users to inform that something will be removed for X reasons in the X release. The "pending" notion could be removed to keep the API lightweight, but with a well documented feature I don't seen terrible thing to understand here, maybe we need to put more effort on documentation and example (related to my changes). * Concerning the fact to move deprecation management outside the declaration of the argument, I think it could be misleading to deprecate something in another place in the code, in other words it could introduce some more difficulties to understand the code. If the deprecation is declared in the argument declaration then all the info are centralized in one place and the parser know what to do in this situation. Thoughts? -- nosy: +4383 ___ Python tracker <https://bugs.python.org/issue39467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39467] Allow to deprecate CLI arguments in argparse
hervé added the comment: hello, First thanks everyone to took time to discute about this proposal. This topic is now opened since ~1 months so I don't think we will more feedback about this, then I will address all your comments in my changes soon to match an implementation more consensually based. -- nosy: +4383 ___ Python tracker <https://bugs.python.org/issue39467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33927] Allow json.tool to have identical infile and outfile
Change by hervé : -- pull_requests: +12015 ___ Python tracker <https://bugs.python.org/issue33927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)
Change by hervé : -- pull_requests: +7536 ___ Python tracker <https://bugs.python.org/issue33671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10660] format() to lower and uppercase
New submission from Hervé Cauwelier :
Hexadecimals can be formatted to lower and uppercase:
>>> '{0:x}'.format(123)
'7b'
>>> '{0:X}'.format(123)
'7B'
I would like the same thing for strings:
>>> '{0.lastname:u} {0.firstname}'.format(user)
'DOE John'
I first thought using "S" for uppercase, but "s" is not available for
lowercase. So I thought about "u" and "l".
The alternative is to write:
>>> '{0} {1}'.format(user.lastname.upper(), user.firstname)
'DOE John'
But I find it less compact and elegant.
--
components: Interpreter Core
messages: 123684
nosy: Hervé Cauwelier
priority: normal
severity: normal
status: open
title: format() to lower and uppercase
type: feature request
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue10660>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10660] format() to lower and uppercase
Hervé Cauwelier added the comment: Thanks for the example. The Python 2.7 documentation about the mini-language doesn't clearly state that it is extensible and how. we see examples of formatting but not of extending. Your example would be welcome in the documentation. -- ___ Python tracker <http://bugs.python.org/issue10660> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8199] zipfile.py: consistency between "write" and "writestr"
New submission from Hervé Cauwelier : Hi, In class "ZipFile", method "write" accepts "compress_type" parameter but not the "writestr" method. I see no reason for this limitation and the change is trivial. This is needed for generating ODF documents since the mimetype file must not be compressed, contrary to other parts. For now, I've copied the block of code that create a "ZipInfo" object in that "writestr" method. The attached patch shows the desired change. Thanks -- components: Library (Lib) files: writestr-compress_type.diff keywords: patch messages: 101486 nosy: he...@itaapy.com severity: normal status: open title: zipfile.py: consistency between "write" and "writestr" type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file16620/writestr-compress_type.diff ___ Python tracker <http://bugs.python.org/issue8199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14284] unicodeobject error on macosx in build process
New submission from Hervé Coatanhay : On a fresh install from mercurial on macosx. ./python -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 369. make: *** [Lib/_sysconfigdata.py] Abort trap: 6 This is reproduced with the following mercurial changesets: changeset reproduced 368a5d7d8a15no (3.2 branch) fafe12f2a030no (3.2 branch) 4a5eafcdde11yes 6b8dd7724ec0yes 0df295d590a8yes 7e576ad85663yes (tip on default) When compiled with pydebug I've got the following in gdb: #0 0x7fff86c0282a in __kill () #1 0x7fff8e61aa9c in abort () #2 0x7fff8e64d5de in __assert_rtn () #3 0x0001000d5589 in _PyUnicode_CheckConsistency (op=0x101024c40, check_content=0) at unicodeobject.c:369 #4 0x0001000df567 in unicode_dealloc (unicode=0x101024c40) at unicodeobject.c:1503 #5 0x00010009f025 in _Py_Dealloc (op=0x101024c40) at object.c:1765 #6 0x00010019df6a in decode_unicode (c=0x7fff5fbf6d58, s=0x10087cc36 "ois Pinard]\n\nHeaps are arrays for which a[k] <= a[2*k+1] and a[k] <= a[2*k+2] for\nall k, counting elements from 0. For the sake of comparison,\nnon-existing elements are considered to be infinite. Th"..., len=4720, rawmode=0, encoding=0x1002c6710 "utf-8") at ast.c:3759 #7 0x00010019e3c6 in parsestr (c=0x7fff5fbf6d58, n=0x10103a118, bytesmode=0x7fff5fbf6944) at ast.c:3829 #8 0x00010019e839 in parsestrplus (c=0x7fff5fbf6d58, n=0x10103a0d0, bytesmode=0x7fff5fbf6944) at ast.c:3874 #9 0x00010019597a in ast_for_atom (c=0x7fff5fbf6d58, n=0x10103a0d0) at ast.c:1869 #10 0x00010019744d in ast_for_power (c=0x7fff5fbf6d58, n=0x10103a088) at ast.c:2228 #11 0x000100197fa6 in ast_for_expr (c=0x7fff5fbf6d58, n=0x10103a088) at ast.c:2428 #12 0x000100198a11 in ast_for_testlist (c=0x7fff5fbf6d58, n=0x1007c1c90) at ast.c:2584 #13 0x000100198fbe in ast_for_expr_stmt (c=0x7fff5fbf6d58, n=0x10048b868) at ast.c:2680 #14 0x00010019d248 in ast_for_stmt (c=0x7fff5fbf6d58, n=0x10048b868) at ast.c:3600 #15 0x000100191530 in PyAST_FromNode (n=0x10048b280, flags=0x7fff5fbf6f60, filename=0x100794ee0 "/Users/herve/Documents/workspace/mercurial_repository/python-vanilla/Lib/heapq.py", arena=0x10051f8f0) at ast.c:760 #16 0x00010021b86f in PyParser_ASTFromFile (fp=0x7fff77c75140, filename=0x100794ee0 "/Users/herve/Documents/workspace/mercurial_repository/python-vanilla/Lib/heapq.py", enc=0x0, start=257, ps1=0x0, ps2=0x0, flags=0x7fff5fbf6f60, errcode=0x0, arena=0x10051f8f0) at pythonrun.c:1982 #17 0x0001001f6d04 in parse_source_module (pathname=0x1007a5320, fp=0x7fff77c75140) at import.c:1186 #18 0x0001001f822d in load_source_module (name=0x1007bd178, pathname=0x1007a5320, fp=0x7fff77c75140) at import.c:1509 #19 0x0001001fd345 in load_module (name=0x1007bd178, fp=0x7fff77c75140, pathname=0x1007a5320, type=1, loader=0x0) at import.c:2477 #20 0x0001002011f7 in import_submodule (mod=0x100340f80, subname=0x1007bd178, fullname=0x1007bd178) at import.c:3338 #21 0x0001001ffb97 in load_next (mod=0x100340f80, altmod=0x100340f80, inputname=0x1007bd178, p_outputname=0x7fff5fbf7350, p_prefix=0x7fff5fbf7338) at import.c:3149 #22 0x0001001fe5c7 in import_module_level (name=0x1007bd178, globals=0x10077cbe8, locals=0x10077cbe8, fromlist=0x100340f80, level=0) at import.c:2842 #23 0x0001001feb00 in PyImport_ImportModuleLevelObject (name=0x1007bd178, globals=0x10077cbe8, locals=0x10077cbe8, fromlist=0x100340f80, level=0) at import.c:2904 #24 0x00010019fd85 in builtin___import__ (self=0x100607420, args=0x10079e9f0, kwds=0x0) at bltinmodule.c:195 #25 0x000100096214 in PyCFunction_Call (func=0x100607510, arg=0x10079e9f0, kw=0x0) at methodobject.c:84 #26 0x000100010656 in PyObject_Call (func=0x100607510, arg=0x10079e9f0, kw=0x0) at abstract.c:2150 #27 0x0001001c597d in PyEval_CallObjectWithKeywords (func=0x100607510, arg=0x10079e9f0, kw=0x0) at ceval.c:3932 #28 0x0001001ba572 in PyEval_EvalFrameEx (f=0x10052f5d0, throwflag=0) at ceval.c:2332 #29 0x0001001c3681 in PyEval_EvalCodeEx (_co=0x1007b9dc0, globals=0x10077cbe8, locals=0x10077cbe8, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at ceval.c:3426 #30 0x0001001aaf0b in PyEval_EvalCode (co=0x1007b9dc0, globals=0x10077cbe8, locals=0x10077cbe8) at ceval.c:771 #31 0x0001001f2d62 in PyImport_ExecCodeModuleObject (name=0x10077b9e0, co=0x1007b9dc0, pathname=0x10060ed60, cpathname=0x10060ed60) at import.c:868 #32 0x0001001f820e in load_source_module (name=0x10077b9e0, pathname=0x1004bbbf8, fp=0x7fff77c750a8) at import.c:1505 #33 0x0001001fd345 in load_module (name=0x10077b9e0, fp=0x7fff77c750a8, pathname=0x1004bbbf8, type=1,
[issue14296] Compilation error on CentOS 5.8
New submission from Hervé Coatanhay : Linux Version: 2.6.18-238.19.1.el5 / CentOS release 5.8 (Final) Since changeset 71704:89e92e684b37 , I have the following compilation error: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function ‘cpu_set_dealloc’: ./Modules/posixmodule.c:4769: attention : implicit declaration of function ‘CPU_FREE’ ./Modules/posixmodule.c: In function ‘make_new_cpu_set’: ./Modules/posixmodule.c:4786: attention : implicit declaration of function ‘CPU_ALLOC_SIZE’ ./Modules/posixmodule.c:4787: attention : implicit declaration of function ‘CPU_ALLOC’ ./Modules/posixmodule.c:4787: attention : assignment makes pointer from integer without a cast ./Modules/posixmodule.c:4793: attention : implicit declaration of function ‘CPU_ZERO_S’ ./Modules/posixmodule.c: In function ‘cpu_set_set’: ./Modules/posixmodule.c:4847: attention : implicit declaration of function ‘CPU_SET_S’ ./Modules/posixmodule.c: In function ‘cpu_set_count’: ./Modules/posixmodule.c:4858: attention : implicit declaration of function ‘CPU_COUNT_S’ ./Modules/posixmodule.c: In function ‘cpu_set_clear’: ./Modules/posixmodule.c:4871: attention : implicit declaration of function ‘CPU_CLR_S’ ./Modules/posixmodule.c: In function ‘cpu_set_isset’: ./Modules/posixmodule.c:4885: attention : implicit declaration of function ‘CPU_ISSET_S’ ./Modules/posixmodule.c: In function ‘cpu_set_richcompare’: ./Modules/posixmodule.c:4910: attention : implicit declaration of function ‘CPU_EQUAL_S’ ./Modules/posixmodule.c: In function ‘do_cpu_set_and’: ./Modules/posixmodule.c:4946: attention : implicit declaration of function ‘CPU_AND_S’ ./Modules/posixmodule.c: In function ‘do_cpu_set_or’: ./Modules/posixmodule.c:4947: attention : implicit declaration of function ‘CPU_OR_S’ ./Modules/posixmodule.c: In function ‘do_cpu_set_xor’: ./Modules/posixmodule.c:4948: attention : implicit declaration of function ‘CPU_XOR_S’ ... gcc -pthread -Xlinker -export-dynamic -o python Modules/python.o libpython3.3m.a -lpthread -ldl -lutil -lm libpython3.3m.a(posixmodule.o): In function `cpu_set_zero': /home/proexp/cpython2/./Modules/posixmodule.c:4897: undefined reference to `CPU_ZERO_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_count': /home/proexp/cpython2/./Modules/posixmodule.c:4858: undefined reference to `CPU_COUNT_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_clear': /home/proexp/cpython2/./Modules/posixmodule.c:4871: undefined reference to `CPU_CLR_S' libpython3.3m.a(posixmodule.o): In function `make_new_cpu_set': /home/proexp/cpython2/./Modules/posixmodule.c:4786: undefined reference to `CPU_ALLOC_SIZE' /home/proexp/cpython2/./Modules/posixmodule.c:4787: undefined reference to `CPU_ALLOC' /home/proexp/cpython2/./Modules/posixmodule.c:4793: undefined reference to `CPU_ZERO_S' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_or': /home/proexp/cpython2/./Modules/posixmodule.c:4947: undefined reference to `CPU_OR_S' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_xor': /home/proexp/cpython2/./Modules/posixmodule.c:4948: undefined reference to `CPU_XOR_S' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_and': /home/proexp/cpython2/./Modules/posixmodule.c:4946: undefined reference to `CPU_AND_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_richcompare': /home/proexp/cpython2/./Modules/posixmodule.c:4910: undefined reference to `CPU_EQUAL_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_dealloc': /home/proexp/cpython2/./Modules/posixmodule.c:4769: undefined reference to `CPU_FREE' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_xor': /home/proexp/cpython2/./Modules/posixmodule.c:4948: undefined reference to `CPU_XOR_S' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_and': /home/proexp/cpython2/./Modules/posixmodule.c:4946: undefined reference to `CPU_AND_S' libpython3.3m.a(posixmodule.o): In function `do_cpu_set_or': /home/proexp/cpython2/./Modules/posixmodule.c:4947: undefined reference to `CPU_OR_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_set': /home/proexp/cpython2/./Modules/posixmodule.c:4847: undefined reference to `CPU_SET_S' libpython3.3m.a(posixmodule.o): In function `cpu_set_isset': /home/proexp/cpython2/./Modules/posixmodule.c:4885: undefined reference to `CPU_ISSET_S' -- components: Build files: sched.h messages: 155706 nosy: Alzakath priority: normal severity: normal status: open title: Compilation error on CentOS 5.8 versions: Python 3.3 Added file: http://bugs.python.org/file24836/sched.h ___ Python tracker <http://bugs.python.org/issue14296> ___
[issue14296] Compilation error on CentOS 5.8
Hervé Coatanhay added the comment: I forgot to give glibc version: glibc-2.5-81 -- ___ Python tracker <http://bugs.python.org/issue14296> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14296] Compilation error on CentOS 5.8
Hervé Coatanhay added the comment: I still have the exact same error Maybe change should be: #if !defined(CPU_ALLOC) && defined(HAVE_SCHED_SETAFFINITY) #undef HAVE_SCHED_SETAFFINITY #endif it seems CPU_ALLOC first appeared in glibc 2.7 -- ___ Python tracker <http://bugs.python.org/issue14296> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14296] Compilation error on CentOS 5.8
Hervé Coatanhay added the comment: You can consider it fixed, compilation runs OK now. However I have an error on building _posixsubprocess.o when I do `make test`, I'll report it in another ticket. -- ___ Python tracker <http://bugs.python.org/issue14296> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14359] _posixsubprocess.o compilation error on CentOS 5.8
New submission from Hervé Coatanhay : Linux Version: 2.6.18-238.19.1.el5 / CentOS release 5.8 (Final) On changeset 75803:b26056192653 , I have the following compilation error: gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/usr/local/include -I/home/proexp/cpython2 -c /home/proexp/cpython2/Modules/_posixsubprocess.c -o build/temp.linux-x86_64-3.3/home/proexp/cpython2/Modules/_posixsubprocess.o /home/proexp/cpython2/Modules/_posixsubprocess.c: In function ‘_close_open_fd_range_safe’: /home/proexp/cpython2/Modules/_posixsubprocess.c:207: erreur: ‘O_CLOEXEC’ undeclared (first use in this function) /home/proexp/cpython2/Modules/_posixsubprocess.c:207: erreur: (Each undeclared identifier is reported only once /home/proexp/cpython2/Modules/_posixsubprocess.c:207: erreur: for each function it appears in.) The problem is the too old kernel version provided on CentOS 5 and RHEL 5 whic does not support O_CLOEXEC. I join my proposed patch for this issue. -- components: Build files: _posixmodule.patch keywords: patch messages: 156237 nosy: Alzakath priority: normal severity: normal status: open title: _posixsubprocess.o compilation error on CentOS 5.8 type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file24922/_posixmodule.patch ___ Python tracker <http://bugs.python.org/issue14359> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21187] 2.7 build-installer.py with OS X 10.9
New submission from Hervé Coatanhay: With XCode 5.1 some changes were made to clang, making it impossible to build Mac OS X installer. Shipped SQLite and Sleepycat DB pass CFLAGS and LDFLAGS to compiler in their compiler check in configure script. In particular -syslibroot option is a linker option not a compiler option, and since XCode 5.1 unused command line options are considered as errors. I manage to work around this problem with the following extra CFLAGS: -Wno-error=unused-command-line-argument-hard-error-in-future I joined my modified version of build-installer.py -- assignee: ronaldoussoren components: Macintosh files: build-installer.py messages: 215810 nosy: Alzakath, ronaldoussoren priority: normal severity: normal status: open title: 2.7 build-installer.py with OS X 10.9 versions: Python 2.7 Added file: http://bugs.python.org/file34773/build-installer.py ___ Python tracker <http://bugs.python.org/issue21187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21187] 2.7 build-installer.py with OS X 10.9
Hervé Coatanhay added the comment: By the way it seems more like an SQLite / Sleepycat issue as LDFLAGS should be passed to linker not compiler. Proposed modifications are just workarounds to allow Mac installer creation on OS X 10.9. -- ___ Python tracker <http://bugs.python.org/issue21187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17453] logging.config.fileConfig error
New submission from Hervé Coatanhay:
In python 2.7 this code works:
>>> import logging.config
>>> import StringIO
>>> a="""[loggers]
... keys = root
... [logger_root]
... handlers = ""
... [formatters]
... keys = ""
... [handlers]
... keys = ""
... """
>>> logging.config.fileConfig(StringIO.StringIO(a))
>>>
whereas in python 3.3 it raises an exception:
>>> import logging.config
>>> import io
>>> a="""[loggers]
... keys = root
... [logger_root]
... handlers = ""
... [formatters]
... keys = ""
... [handlers]
... keys = ""
... """
>>> logging.config.fileConfig(io.StringIO(a))
Traceback (most recent call last):
File "", line 1, in
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/logging/config.py",
line 70, in fileConfig
formatters = _create_formatters(cp)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/logging/config.py",
line 114, in _create_formatters
class_name = cp[sectname].get("class")
File
"/opt/local/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/configparser.py",
line 942, in __getitem__
raise KeyError(key)
KeyError: 'formatter_""'
>>>
--
components: Library (Lib)
messages: 184435
nosy: Alzakath
priority: normal
severity: normal
status: open
title: logging.config.fileConfig error
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue17453>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17453] logging.config.fileConfig error
Hervé Coatanhay added the comment: My complete configuration is this: [loggers] keys = app_admin,root,app_test_py3 [logger_root] handlers = "" [formatters] keys = app_admin,app_test_py3 [handlers] keys = app_admin,app_test_py3 [logger_app_admin] propagate = 1 handlers = app_admin qualname = nagare.application.admin level = INFO [handler_app_admin] formatter = app_admin class = StreamHandler args = (sys.stderr,) [formatter_app_admin] format = %(asctime)s - %(name)s - %(levelname)s - %(message)s [logger_app_test_py3] propagate = 1 handlers = app_test_py3 qualname = nagare.application.test_py3 level = INFO [formatter_app_test_py3] format = %(asctime)s - %(name)s - %(levelname)s - %(message)s [handler_app_test_py3] formatter = app_test_py3 class = StreamHandler args = (sys.stderr,) I wanted to provided a non-working configuration as small as possible, that was accepted by python 2.7. It seems you are right there is a problem with this configuration as it shuts down logging in python 2.7. It looks like i have a bug in my configuration generation. By the way the patch restores python 2.7 behavior as expected, thanks. -- ___ Python tracker <http://bugs.python.org/issue17453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17453] logging.config.fileConfig error
Hervé Coatanhay added the comment: Yes it does. I fixed my configuration generation and everything is running as expected. Thanks. -- ___ Python tracker <http://bugs.python.org/issue17453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
