[issue41704] logging module needs some form of introspection or debugging support
Jack Jansen added the comment: @vinay, absolutely right on this being an anti-pattern:-) And also right on the statement that I can set a breakpoint on all three of logging.basicConfig, logging.config.fileConfig and logging.config.dictConfig, I had overlooked that (was looking for a single place to put the breakpoint). I'll close this. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41704> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41704] logging module needs some form of introspection or debugging support
New submission from Jack Jansen : The logging module and its API make it easy to modify the behaviour of all loggers used in any package in your program. Unfortunately the downside of this is that if any author of any module that you use changes the global logger configuration you get in a situation where all your logger calls are not behaving as expected. Moreover, it is very difficult to debug this and to find the culprit. If the logger module had a global "debug logger usage" flag which would make it emit a log message whenever a call changed the global configuration this would help, especially if the messages were vectored through a single function or method that you could then set a breakpoint on. -- components: Library (Lib) messages: 376308 nosy: jackjansen priority: normal severity: normal status: open title: logging module needs some form of introspection or debugging support type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41704> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40610] ctypes on Windows: error message on DLL load failure is misleading
New submission from Jack Jansen : On Windows, when ctypes fails to load a DLL, the error message is misleading. If a dependency of the DLL cannot be found if appears as if the DLL itself cannot be found. This issue has always existed on Windows (and I know it is due to what the OS provides by default as its error message) but it is exacerbated by the DLL loading rules in Python 3.8 (the `os.add_dll_directory()` changes), because now importing a DLL into Python will follow different rules than those followed by, for example, command line utilities shipped with the DLL you are loading follow. An ideal fix would be a message of the form "xxx.dll failed to load because its dependency yyy.dll is not on the current Python DLL search path, see for details". But I am not well-versed enough in Windows APIs to know whether that is even possible. A fix that is minimal and at least not misleading would be a message "xxx.dll (or one of its dependencies) failed to load. See for details". -- components: ctypes messages: 368748 nosy: jackjansen priority: normal severity: normal status: open title: ctypes on Windows: error message on DLL load failure is misleading type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder
Jack Jansen added the comment: Correction to the last line: When using Python 2.7 everything works fine. When adding a findall() method to the Element subclass that simply calls ElementPath.findall() everything also works fine. I suspect some issue with the _elementtree C implementation but I don't understand it. -- ___ Python tracker <https://bugs.python.org/issue34941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34941] xml.etree.ElementTree findall() fails when using custom TreeBuilder
New submission from Jack Jansen : When using a TreeBuilder with a custom factory (returning a subclass of Element with some extra functionality) there is an issue with findall(). XPaths using an indexed predicate no longer work: the findall() result is always empty. The attached test script shows the problem. I have analysed this as far as finding that the issue is in ElementPath.prepare_predicate..select(), the last one. Specifically, the statement elems = list(parent.findall(elem.tag)) always returns an empty list (if the Element class is subclassed). When using Python 2.7 everything works fine. When adding a findall() method to the Element subclass that simply calls Element.findall() everything also works fine. I suspect some issue with the _elementtree C implementation but I don't understand it. -- components: Library (Lib) files: testetns.py messages: 327385 nosy: jackjansen priority: normal severity: normal stage: needs patch status: open title: xml.etree.ElementTree findall() fails when using custom TreeBuilder type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47859/testetns.py ___ Python tracker <https://bugs.python.org/issue34941> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Change by Jack Jansen : -- nosy: +jackjansen ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13210] Support Visual Studio 2010
Changes by Jack Jansen jackjan...@users.sourceforge.net: -- nosy: +jackjansen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13892] distutils handling of windows manifest isn't optimal
Jack Jansen jackjan...@users.sourceforge.net added the comment: Indeed, my situation is different from the cscript.exe situation because in my case Python needs to call back into the hosting application. Further experiments have shown that this is indeed the problem, and moreover that this is a problem that cannot be solved (at least, I am not smart enough to solve it:-). The Python extension module that does the callbacks would have to live in two different runtime worlds: if it allocates python objects it would have to use the VS2008 runtime, if it allocates Ambulant objects it would have to use 2010 runtime. This makes the whole original topic of this bug report of academic interest only. Fell free to close/won't fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13892] distutils handling of windows manifest isn't optimal
Jack Jansen jackjan...@users.sourceforge.net added the comment: Hmm, the cscript.exe point is a valid one. I can think of two things that make my situation different, I will investigate (and post here): - I started getting the problem when the hosting application (Ambulant multimedia player) switched from VS2008 to VS2010. So maybe cscript.exe is built with 2008, and there the problem is masked? - My outer plugin (the one for Ambulant) also links against the .pyd (actually, to the .lib corresponding to the .pyd, which results in the .dll having a reference to the .pyd) because I need the various _New and _Convert routines when I call out to Python. I think this is a situation that wouldn't occur in the cscript.exe case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13892] distutils handling of windows manifest isn't optimal
New submission from Jack Jansen jackjan...@users.sourceforge.net: I found a problem with the handling of manifest files in the msvc9compiler. Distutils removes the reference to the MSVC runtime from the manifest resource, to enable installing the runtime system locally (i.e. to allow non-admins to install Python in their own directory, without needing admin access to the winSxS directory). Embedders of Python are suggested to the manifest for the MSCV runtime to their main program (i.e. the program embedding Python). This is all a good idea, except for one use case: if you are including Python into a product that is itself a plugin to another product. And, of course, if you need to extend this Python with an extension module. In this case, you have no control over the manifest of the main program (which is the outer embedder). You have control over your own plugin (the one incorporating Python), but this intermediate manifest file is not taken into account when loading the distutils-generated .pyd file. (imagining the amount of time it took me before I got to this analysis is left as an exercise to the reader:-) I would suggest an option to distutils to skip the _remove_visual_c_ref() step. -- assignee: tarek components: Distutils messages: 152119 nosy: eric.araujo, jackjansen, tarek priority: normal severity: normal status: open title: distutils handling of windows manifest isn't optimal type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen jackjan...@users.sourceforge.net added the comment: Martin, I agree about the Py_DEBUG issue. My reason for asking is really only a workaround for the VC++ problam that you can't link non-debug and debug builds together. You know what: if you think it isn't worth it just assign it to me and I'll try to go the extra step of doing the work and providing a patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11656 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen jackjan...@users.sourceforge.net added the comment: Martin, what I meant by linking debug and non-debug builds together is impossible is you cannot link modules together if they code generation has been set to different runtime systems, for example one module using the debug runtime system and another using the non-debug runtime system. But: let's cut this short, if this isn't worth the extra load on the release manager then it isn't worth pursuing. I did the work for myself (and co-developers, more importantly) but then I won't try and shape things up for more general consumption. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11656 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
New submission from Jack Jansen jackjan...@users.sourceforge.net: Because VC++ cannot cross-link modules that have been built with debugging to those built without debugging (because of runtime system differences) it would be a boon for people embedding Python if there was a binary distribution of the DLL (and .lib) available that was built with debugging turned on. Right now, to build a debugging version of an application that has Python embedded you must also build Python from source... -- components: Build, Windows messages: 131934 nosy: jackjansen priority: normal severity: normal status: open title: Debug builds for Windows would be very helpful type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11656 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11656] Debug builds for Windows would be very helpful
Jack Jansen jackjan...@users.sourceforge.net added the comment: Sorry, I think I wasn't clear in my original message. I don't want to debug Python, I want to debug only my own code. But because it embeds Python I cannot debug my own code, because it needs to link to Python. Indeed, if it was only Python itself I would have build from source it would not be so much of an issue, but there's all the external stuff... Brian: if you have a reference I can check the reasoning. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11656 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Jack Jansen jackjan...@users.sourceforge.net added the comment: Jack, could you please comment on why the LDFLAGS are added to LDSHARED by configure, rather than using LDFLAGS as extra argument to LDSHARED ? Because this worked, no deep reason. The initial framework builds were a big hack, because they were neither static nor shared builds (because the extensions were linked against the framework), so I had to find something that worked while hoping I wouldn't break too much on other platforms. In case anyone is interested in my opinion: I would scratch the whole configure/make suite and rebuild it from scratch. As others here have noticed, the OPT/EXTRA_CFLAGS pattern that Python adhered to has lost out the the CFLAGS/LDFLAGS pattern, and more such things. And this is important if people want to do recursive builds. But: it's a major undertaking to get this working, especially if you don't want to pull in libtool:-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1628484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue602291] Bgen should learn about booleans
Jack Jansen jackjan...@users.sourceforge.net added the comment: Close it. I'll revive my version of bgen whenever I find the time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue602291 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
