[issue34107] root.warning('msg') output format modified by logging.warning('msg')
Michael Kearney added the comment:
Thanks for the clarification and doc pointers. I saw "lastResort" attribute in
the code
but had not fully understood what was going on. I am not certain I really do
now, but that's ok. That's why we read docs, read and write
code. Eventually it starts making sense.
It appears that there is history to contend with or complications provoked by
threads.
I had not yet read the lastResort discussion in the documentation. That's deep
in the
advanced tutorial, I was getting tripped up by simple examples that I concocted
from
very simple cases, which can be on the fringes of actual usage. I wonder why
"lastResort" differs from the built-in default.
I was playing with basicConfig because I wanted to experiment with formatting
and level,
and I managed to generate messages that seemed unrelated to formating I had
specified.
For now it appears that after
import logging
I can add
logging.warning('')
and achieve what I want. I get the default format where I expect rather than
lastResort format.
I prefer the default format that I get from the internal call to basicConfig.
I can imagine the there will be a situation where I want the even simpler
"last resort format".
--
___
Python tracker
<https://bugs.python.org/issue34107>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34107] root.warning('msg') output format modified by logging.warning('msg')
New submission from Michael Kearney :
0 >>> import logging
1 >>> root=logging.getLogger(name='root')
2 >>> root.warning('msg')
3 msg <- Compare this line
4 >>> logging.warning('msg')
5 WARNING:root:msg
6 >>> root.warning('msg')
7 WARNING:root:msg <-- with this line
Specifically, I was surprised to see
line 7 response to line 6
given
line 3 response to line 2
logger methods log(),critical(),error(),info() act the same way.
A workaround from issue 33897 fixes things
logging.basicConfig(level=logging.DEBUG, force=True)
I discovered this when exploring "logging" module defaults, It is the sort of
thing someone new to the module might encounter. I did.
Slightly more comprehensive unittest example attached.
This may be my first real submission. Feedback appreciated
--
files: logTest.py
messages: 321582
nosy: Michael Kearney
priority: normal
severity: normal
status: open
title: root.warning('msg') output format modified by logging.warning('msg')
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file47686/logTest.py
___
Python tracker
<https://bugs.python.org/issue34107>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33897] Add a restart option to logging.basicConfig()
michael kearney added the comment: Thank you! I just stumbled into this problem with logging.basicConfig. In the course of trying to find an acceptable workaround I discovered issue 33897 . I downloaded 3.8.0 and voila my problem is solved. So, I'll tread lightly, advance to 3.7.0, and keep the latest 3.8.* around for surprises. Regards to you-all in the development front lines. -m Is it acceptable to express appreciation in here? -- nosy: +michael.kearney ___ Python tracker <https://bugs.python.org/issue33897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
michael kearney added the comment: Observation: Tools\buildbot\build.bat solves all the problems I was having. That is to say, a single command exists to build python on windows w/o problems. It has worked since at least since python 3.3.1, which I think preceded my original submission. So this has existed all this time, but has not been suggested as the solution it seems to be. What's wrong with it? Is it about to be deprecated perhaps? The DevGuide recommends external.bat in the same directory. build.bat calls external.bat and does more. Detail: If I 1. place the unzipped downloaded file folder isolated within another folder so that external projects can be built adjacent to python. 2. make certain that svn,nasm,VC++, are in my path. 3. cd to the python root 4. execute the command : Tools\buildbot\build.bat Then python_d.exe is created in the PCbuild folder. This is true for python 3.3.1, 3.3.2, 3.3.4, 3.4.0, and the current development version. I have built all since yesterday. I skipped 3.3.3 only because I didn't have the source downloaded OK, I lied a little. 1. The 3.3.1 release python.org areas had a corrupt openSSL rev d, I think. I modified my local external.bat to get a later version to solve that problem. 2. Other releases build debug tcltk release libs when debug libs are needed, and vice versa. I made copies of whatever existed and renamed the copy to whatever was required. But this is nothing compared what I was going through before. I personally like to have python.exe around also. To create python.exe, I only now open pcbuild.sln to start VC++, chose the release configuration, and hit F7. I have learned that it is best to run build.bat first before using pcbuild.sln with the VC++ IDE to build anything. It currently does not work for AMD64 but I maguessing that ti would be a good model to follow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
michael kearney added the comment: Thanks for the pointer to your work and discussion in issue16895. I was contemplating something along those lines. I had not started down that path first because I've only relatively recently thrashed the problem enough to understand the issues, and second because I wasn't thrilled with the prospect of implementing anything in microsoft's shell scripting language (called PowerShell now yes?), which being proprietary and primitive would discourage I would think the python community from even considering looking at the code when the inevitable bugs appear. I was intrigued to read in the recent replies to issue 16895 about the suggestion to bootstrap. There is a lot of history to the merits of that approach in other languages. It is surprising to me that the approach isn't used in python. Well I guess, given that python is C under the skin and configure/make is well established unix idiom My progress on this topic has been in fits and starts. It's about what I can tolerate. The state of OpenSLL all by itself is pretty bizarre. Regardless, I believe another fit is in my near future. Judging by the response to your issue there is interest and hope in getting this corner of python under control. I will review your configure/make solution, with luck a patch to the devguide can be just a massive simplification. On the other hand, the discussion of what is going on in automating the process would be useful. The existing docs did help me decode what was going on envetually. -m -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17846] Building Python on Windows - Supplementary info
New submission from michael kearney: This is not a bug per se, though perhaps documentation rewrite might be appropriate. I've been building python for windows for several years now. I have found that it is unnecessarily problematic. Perhaps my expectations are too high. When I started building python, I expected to build a whole stable version of python thing without error. In my experience, it is not true that one can build python on windows by simply loading the .sln file into Visual studio, selecting Debug or Release, and then clicking build. Over time I have worked out steps that allow me to build all bits of python and minimize the aggravation and failures. These steps follow. Hopefully they will help folks to avoid some of the problems I encountered. Perhaps this will attract commentary that will document the way things actually should be done. I would be happy to stand corrected and know that there is a simple single point and click or single line command that would build python on windows. Regardless, here you go. The online directions for downloading the development version source are fine and can be found at http://docs.python.org/devguide/. Mercurial must be installed on your machine. Stable released version source is available on the download page. Python building/rebuilding assumes the existence of subversion, perl, and a version of Visual Studio on your system. If you have all three, skip to step three. Otherwise download and install any of those that are missing. If it is necessary to have on hand multiple versions of python built from scratch, you should isolate them from each other by putting them in a container directory perhaps of the same name. e.g. I use a style like python331/python331, python32/python32 where the subdirectory is the source root directory. I use the upper directory to isolate the external subprojects created by the buildbots described later. If you don't do this, the buildbots of one version can wipe out required subprojects of another version of python. I can assure you this will cause you a lot of confusion until you realize the source of the problem. 0. Download and install at least a subversion client and add the executable to your path. I got mine from Collabnet and here is how it appears in my path C:\Program Files\CollabNet\Subversion Client 1. Download and install perl and add the executable to your path I vaguely recall I downloaded ActivePerl Your Perl path will look something like this. C:\Perl\site\bin;C:\Perl\bin 2. Download and install VC++ express and add the bin area to your path Your VC++ bin path will look something like this: C:\Program Files\Microsoft Visual Studio 10.0\VC\bin I use the free version of VC++, which may be the source of all my python build issues. When I load the solution file which you will see later, VC++ complains that the version I have doesn't support various features. It is free though and I am able to work with it. 2 Download and install nasm: There are several downloading sites. This seems to be the latest and greatest. http://www.windows7download.com/win7-nasm/ldyuniel.html 4. Download and build the external subprojects with the buildbots using either: Tools\buildbot\external.bat # for 32 bit processors Tools\buildbot\external-amd64.bat # for 64 bit processors from the root directory or your python distribution. This step will download the correct versions of the external projects for this version of python. There are several projects 4. openssl is used for python on windows ssl rarely succeeds if you proceed to build using pcbuild.sln: The following steps will resolve many problems if you executing them before building with the .sln file cd into the openssl directory created by the buildbots perl util\mkdef.pl crypto ssl update perl Configure VC-WIN32 --prefix=C:\opt\openssl-1.0.1d ms\do_nasm You may get compilation errors anyway when you attempt to build the .sln file with Visual Studio. The errors I have seen have always been the same type, namely a forced error contained within a block of conditional code. In all cases so far I have been able to comment out the forced error. Most recently I had to comment out code blocks in mdc2.h and idea.h. Historically, the openssl build has not had a clean function. This used to cause me a lot of problems if rebuilding was required for whatever reason. I cleaned the project by deleting and letting the buildbot download again what was required. 5. Finally Build python and its internal subprojects open the solution pcbuild.sln in Visual Studio (VC++ in my case) - If you have an express version, then ignore the warning select the configuration Release or Debug Release builds python.exe Debug builds python_d.exe select
