Skip,
On 2/04/19 9:54 AM, Skip Montanaro wrote:
I assiduously avoided using Python's logging package for about the
first dozen years of its existence. I eventually gave in and started
I'm glad you're stepping-up!
I'm never sure whether to be amazed or dismayed by the huge number of
folk exp
Malcolm Greene wrote:
> I'm using the Python logging module and looking for a way to include a
> method's class name when using %(funcName). Is this possible? When you
> have several related classes, just getting the function (method) name is
> not enough information to provide context on the code
Malcolm Greene writes:
> I'm using the Python logging module and looking for a way to include a
> method's class name when using %(funcName). Is this possible?
If it does not happen automatically, the standard logging components
will not let you do it (the name "funcName" is rather explicit;
you
Sharan Basappa writes:
> I am trying to use logging module and somehow I cannot make it work.
>
> A simple code that I am trying is below. The commented code line 5,6 are
> other options I have tried but don't work
>
> #importing module
> import logging
>
> #Create and configure logger
> #loggi
On Sun, 01 Jul 2018 06:05:48 -0700, Sharan Basappa wrote:
> Folks,
>
> I am trying to use logging module and somehow I cannot make it work.
>
> A simple code that I am trying is below. The commented code line 5,6 are
> other options I have tried but don't work
>
> #importing module
> import log
> On Jul 1, 2018, at 8:05 AM, Sharan Basappa wrote:
>
> Folks,
>
> I am trying to use logging module and somehow I cannot make it work.
Saying that something does not work does not provide enough information for
anyone to assist you. You need to provide both the exact code that did not
wo
On Monday, October 16, 2017 at 11:58:12 PM UTC-7, Steve D'Aprano wrote:
> On Tue, 17 Oct 2017 03:06 pm, llanitedave wrote:
>
> [...]
> > I set up the logging code at the very beginning of the app, before any other
> > work is done. Here's the relevant code:
> >
> > #!/usr/bin/env python3
> [...
Those are some good suggestions, I've found that I won't be able to work on it
today, but I'll definitely follow up tomorrow. As for not showing all the
code, the main window and its associated code are definitely there and working.
I didn't post it because of all the setup code for fields and
On Tue, 17 Oct 2017 03:06 pm, llanitedave wrote:
[...]
> I set up the logging code at the very beginning of the app, before any other
> work is done. Here's the relevant code:
>
> #!/usr/bin/env python3
[... snip imports ...]
> class MainWindow(QMainWindow):
> def __init__(self):
> s
On Tue, Oct 17, 2017 at 3:06 PM, llanitedave
wrote:
> I'm building an application that contains some long-running operations in a
> separate thread from the user interface. I've been using the logging module
> writing logging.info() statements to a .log file to keep track of the data
> interac
Thank you. This has been very helpful.
Ian
--
http://mail.python.org/mailman/listinfo/python-list
On Mar 30, 3:49 pm, mennis wrote:
> I am working on a library for controlling various appliances in which
> I use theloggingmodule. I'd like some input on the basic structure
> of what I've done. Specifically theloggingaspect but more general
> comments are welcome. I'm convinced I mis-understa
On Wed, Feb 16, 2011 at 12:23, benhoyt wrote:
>
> > AFAIK, the Windows performance counter has long-term accuracy issues,
> > so neither is perfect. Preferably we should have a timer with the long-
> > term accuracy of time.time and the short-term accuracy of time.clock.
>
> Thanks for the tip --
> For example, are you assuming that your clock() call in logging is
> the very first call made?
Yes, we were making that assumption (the time.clock() call in the import of our
log module), which was true in our code, but I can see where it's not a good
thing to assume generally.
> Also, IIUC
> AFAIK, the Windows performance counter has long-term accuracy issues,
> so neither is perfect. Preferably we should have a timer with the long-
> term accuracy of time.time and the short-term accuracy of time.clock.
Thanks for the tip -- yes, I hadn't thought about that, but you're right,
Quer
On Wed, Feb 16, 2011 at 09:34, sturlamolden wrote:
> On 16 Feb, 15:30, benhoyt wrote:
>
> > It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows, just like the "timeit" module does.
>
> AFAIK, the Windows performance counter has long-term a
On 16 Feb, 15:30, benhoyt wrote:
> It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows, just like the "timeit" module does.
AFAIK, the Windows performance counter has long-term accuracy issues,
so neither is perfect. Preferably we should
On Feb 16, 2:30 pm, benhoyt wrote:
> It seems to me that the logging module should use a millisecond-accurate
> timestamp (time.clock) on Windows,
> just like the "timeit" module does.
It's not an unreasonable request, though I don't think logging should
be used to time things accurately. I'm a
> A simpler solution would be to caclulate the time it takes to the handle
> the request using time.clock() and include it in the log message.
> Something like:
Thanks, Ross. Actually, we are doing exactly that already -- it's how we
noticed the timestamp issue in the first place. However, that
benhoyt wrote:
>This works, but as you can see, it's a bit hacky. Is there a better way to =
>fix it? (I'd like the fix to affect all loggers, including the root logger.=
>)
A simpler solution would be to caclulate the time it takes to the handle
the request using time.clock() and include it in
Chris Seberino wrote:
> It looks like I can miss some logging messages if I don't flush after
> every oneis that true?
As far as I can tell from the 2.6 source the StreamHandler does flush after
each record.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 4, 12:31 pm, mynthon wrote:
Thank you for this suggestion. Ideally, you would have created an
issue for this on bugs.python.org, because then it would be more
likely to be acted upon.
I've implemented this feature in r76691 (in Python trunk and py3k) in
a more general way. It works by spe
On 2009-07-01 10:02, Frank Aune wrote:
Hello,
snip
import logging
logging.basicConfig(level=logging.DEBUG)
x='\xfe\x9f\xce\xc3\xa1\x00\xff\x01'
x
'\xfe\x9f\xce\xc3\xa1\x00\xff\x01'
print x
���á�
logging.info(x)
Traceback (most recent call last):
File "/usr/lib/python2.6/loggin
Frank Aune wrote:
import logging
logging.basicConfig(level=logging.DEBUG)
x='\xfe\x9f\xce\xc3\xa1\x00\xff\x01'
x
> '\xfe\x9f\xce\xc3\xa1\x00\xff\x01'
logging.info(x)
> Traceback (most recent call last):
> File "/usr/lib/python2.6/logging/__init__.py", line 773, in emit
En Thu, 23 Oct 2008 14:52:47 -0200, Matimus <[EMAIL PROTECTED]> escribió:
On Oct 23, 7:58 am, "Werner F. Bruhin" <[EMAIL PROTECTED]> wrote:
1. I would like to have a "log viewer" a wxPython based app to be able
to look at a log generated by another script.
Running in a separate process? That
On Oct 23, 7:58 am, "Werner F. Bruhin" <[EMAIL PROTECTED]> wrote:
> I am starting to use the logging module.
>
> Simple log to file and/or console work very nicely.
>
> Even managed to get TimedRotatingFileHandler to work.
>
> The problem I am trying to solve.
>
> 1. I would like to have a "log vie
On Nov 21, 11:08 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> Having thought more about this, it _has_ to be that way - think of one
> handler attached to several loggers. Removing AND closing it from one would
> render it useless for others. You can't want that to happen.
You have a point.
Michele Simionato wrote:
> On Nov 21, 10:23 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>
>> I can only guess - but I'd say if you can do
>>
>> foo.removeHandler(h)
>>
>> you can do
>>
>> foo.removeHandler(h)
>> h.close()
>>
>> easily. But not
>>
>> foo.removeHandler(h) # implicit closing
>
On Nov 21, 10:23 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> I can only guess - but I'd say if you can do
>
> foo.removeHandler(h)
>
> you can do
>
> foo.removeHandler(h)
> h.close()
>
> easily. But not
>
> foo.removeHandler(h) # implicit closing
> bar.addHandler(h)
>
> It does kind of mak
Michele Simionato schrieb:
> I have just discovered a bug in my code using the logging module, due
> to
> handlers not being closed properly. The issue was that I called the
> function
> removeHandler and I assumed that it took care of closing the handler,
> but it did not.
> Looking at the source
On 21 Oct, 07:50, Paul Rudin <[EMAIL PROTECTED]> wrote:
> > Can you say a little bit more about the execution environment? For
> > example, are you running under mod_python? If so, which version?
>
> I'm not running under mod_python - but this is using cherrypy. I also
> do some passing of pickled
Vinay Sajip <[EMAIL PROTECTED]> writes:
> On 16 Oct, 04:14, Paul Rudin <[EMAIL PROTECTED]> wrote:
>> I'm occasionally seeing tracebacks like this:
>>
>> Traceback (most recent call last):
>> File "logging/__init__.py", line 744, in emit
>> File "logging/__init__.py", line 630, in format
>> F
On 16 Oct, 04:14, Paul Rudin <[EMAIL PROTECTED]> wrote:
> I'm occasionally seeing tracebacks like this:
>
> Traceback (most recent call last):
> File "logging/__init__.py", line 744, in emit
> File "logging/__init__.py", line 630, in format
> File "logging/__init__.py", line 421, in format
>
Both are very good responses... thanks! I had forgotten the ease of
"monkey-patching" in python and the Stream class is certainly cleaner
than the way I had been doing it.
On Oct 3, 3:15 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> Russell Warren wrote:
> > All I'm after is the ability to log thi
Shiao wrote:
> Maybe my question wasn't very clear. What I meant is that these four
> lines lead in my case to two entries per logged event:
>
> applog = logging.getLogger()
> applog.setLevel(logging.DEBUG)
> hdl = logging.FileHandler('/tmp/foo.log')
> applog.addHandler(hdl)
>
> However if I REP
Maybe my question wasn't very clear. What I meant is that these four
lines lead in my case to two entries per logged event:
applog = logging.getLogger()
applog.setLevel(logging.DEBUG)
hdl = logging.FileHandler('/tmp/foo.log')
applog.addHandler(hdl)
However if I REPLACE the above by:
logging.basi
Shiao wrote:
>> You need to remove the handler from the logging object
>>
>> # remove the handler once you are done
>> applog.removeHandler(hdl)
> I'm not sure how this could help.
If you have multiple handlers you'll get a logged message for every handler.
In your code logging.basicConfig() im
>
> You need to remove the handler from the logging object
>
> # remove the handler once you are done
> applog.removeHandler(hdl)
>
> Cheers,
> amit.
>
I'm not sure how this could help.
--
http://mail.python.org/mailman/listinfo/python-list
On 8/21/07, Shiao <[EMAIL PROTECTED]> wrote:
> Hi,
> I am getting duplicate log entries with the logging module.
>
> The following behaves as expected, leading to one log entry for each
> logged event:
>
> logging.basicConfig(level=logging.DEBUG, filename='/tmp/foo.log')
>
> But this results in two
On Jun 13, 1:28 am, "James T. Dennis" <[EMAIL PROTECTED]> wrote:
> This sounds like a job for the Queue class/module to me.
> Could you create a Queue such that all your worker threads
> are producers to it and you have one dedicated thread as a
> consumer that relays log entries from the Queue
Ross Boylan <[EMAIL PROTECTED]> wrote:
> I would like my different threads to log without stepping on each
> other.
> Past advice on this list (that I've found) mostly says to send the
> messages to a Queue. That would work, but bypasses the logging
> module's facilities.
> The logging module it
On 1 Jun, 13:00, Álvaro Nieto <[EMAIL PROTECTED]> wrote:
> How could I define a log file with datetime in his name?. Now the
> name
> for log file is './Logs/cdmto.log' and I'd like it would be './
> Logs/cdmto_20070601.log',
> for example.
>
You can't do this just in the configuration
On May 12, 1:53 am, Ross Boylan <[EMAIL PROTECTED]> wrote:
>
> I'm also puzzled by how the logger hierarchy works. The docs say that
> everything that is logged by the kids is also logged by the parent.
> That would seem to defeat what I'm trying to do above, since the
> parent would get each logg
Peter Otten wrote:
> Peter Otten wrote:
>
> > Gary Jefferson wrote:
> >
> >> I've written a logging.filter and would like to use doctest on it
> >> (using a StreamHandler for stdout), but this doesn't seem possible.
> >> Output from the logger seems to disappear (running the doctest strings
> >> th
Peter Otten wrote:
> Gary Jefferson wrote:
>
>> I've written a logging.filter and would like to use doctest on it
>> (using a StreamHandler for stdout), but this doesn't seem possible.
>> Output from the logger seems to disappear (running the doctest strings
>> through the interpreter as-is yield
Gary Jefferson wrote:
> I've written a logging.filter and would like to use doctest on it
> (using a StreamHandler for stdout), but this doesn't seem possible.
> Output from the logger seems to disappear (running the doctest strings
> through the interpreter as-is yields expected results). I assu
Tekkaman wrote:
>> Putting /usr/lib64/python2.4 as the first entry into your
>>
>> PYTHONPATH
>>
>> environment variable might fix the problem (the idea is
>> that /usr/lib64/python2.4 precedes /usr/lib/python2.4 in sys.path and is
>> therefore used for the import of the logging package).
> Thank
On Dec 14, 6:41 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> Tekkaman wrote:
>> lib is a symlink to lib64
> So my initial diagnosis was correct. Unfortunately I can no longer recommend
> that you remove the symlink...
>
Yes. What I really meant in my first reply was "it's not a symlink in
the scr
Tekkaman wrote:
> lib is a symlink to lib64
So my initial diagnosis was correct. Unfortunately I can no longer recommend
that you remove the symlink...
Putting /usr/lib64/python2.4 as the first entry into your
PYTHONPATH
environment variable might fix the problem (the idea is
that /usr/lib64
Peter Otten wrote:
> Tekkaman wrote:
>
> > Peter Otten wrote:
> >> Tekkaman wrote:
> >>
> >> > Thanks for the hint, but it's not a symlink
> >>
> >> What does logging._srcfile contain? Should be
> >>
> >> >>> import logging
> >> >>> logging._srcfile
> >> '/usr/lib/python2.4/logging/__init__.py'
>
lib is a symlink to lib64
Peter Otten wrote:
> Tekkaman wrote:
>
> > Peter Otten wrote:
> >> Tekkaman wrote:
> >>
> >> > Thanks for the hint, but it's not a symlink
> >>
> >> What does logging._srcfile contain? Should be
> >>
> >> >>> import logging
> >> >>> logging._srcfile
> >> '/usr/lib/python2
Tekkaman wrote:
> Peter Otten wrote:
>> Tekkaman wrote:
>>
>> > Thanks for the hint, but it's not a symlink
>>
>> What does logging._srcfile contain? Should be
>>
>> >>> import logging
>> >>> logging._srcfile
>> '/usr/lib/python2.4/logging/__init__.py'
>>
>> on your machine, but probably isn't.
'/usr/lib64/python2.4/logging/__init__.py'
Peter Otten wrote:
> Tekkaman wrote:
>
> > Thanks for the hint, but it's not a symlink
>
> What does logging._srcfile contain? Should be
>
> >>> import logging
> >>> logging._srcfile
> '/usr/lib/python2.4/logging/__init__.py'
>
> on your machine, but pro
Tekkaman wrote:
> Thanks for the hint, but it's not a symlink
What does logging._srcfile contain? Should be
>>> import logging
>>> logging._srcfile
'/usr/lib/python2.4/logging/__init__.py'
on your machine, but probably isn't.
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Peter Otten wrote:
>
> An evil symlink, maybe?
Thanks for the hint, but it's not a symlink
>
> $ ln -s /usr/local/lib/python2.4/logging
> $ python
> [snip]
> >>> import logging
> >>> logging.basicConfig(format="%(pathname)s")
> >>> logging.getLogger().critical("yadda")
> /usr/local/lib/python2.4/l
sim.sim wrote:
> Hi, i've check documentation, and found that logging.basicConfig takes
> no arguments (probably we have different versions of logging package),
Your Python version is < 2.4. Now basicConfig takes optional keyword
args:
basicConfig([**kwargs])
Does basic configuration for the log
Tekkaman wrote:
> I'm getting a strange behaviour from the "pathname" and "lineno"
> formatter mapping keys. Instead of my file and my line number I get:
>
> /usr/lib/python2.4/logging/__init__.py
>
> as the file, and 1072 as the line number. I set up my config as
> follows:
>
> logBaseConf = {
Hi, i've check documentation, and found that logging.basicConfig takes
no arguments (probably we have different versions of logging package),
and i've never used it.
just try this:
fileName = 'testlog.log'
logName = 'LOG'
iHandler = logging.FileHandler(fileName)
iHandler.setFormatter(
logging.F
Am Thu, 29 Jun 2006 20:22:28 -0700 schrieb ss2003:
> hi
> i have defined a function
> def logger(logfile,msg):
> import logging
>
> logging.basicConfig(level=logging.DEBUG,
>format='%(asctime)s %(levelname)-8s
> %(message)s',
>
> See a very similar example which uses the new 'extra' keyword argument:
Now that's brilliant! Exactly what I need.
But unfortunately, it's also unavailable until 2.5 comes out. Until then I'm
afraid I'm stuck with my shoddy hack... but it's always nice to know the time
will come when I can fi
[EMAIL PROTECTED] wrote:
> Hi!
>
> I'm writing a server and I want to use the logging module for logging
> stuff. I want to log all transactions in detail, and if everything goes
> haywire I want to know which client did it. Therefore I want to affix
> the client address to every single log item.
[EMAIL PROTECTED] wrote:
> I use the logging module include in Python 2.4 distribution, and I 'd
> like to have a logger witth several Handlers .
> I know how to do this by coding in python, but could I specify this
> directly in the logger configuration file?
See in
http://docs.python.org/lib/l
> but now I'd like to understand the design rational behind having each
> logger in the object hierarchy log the same output by default. Anyone?
Loggers are different to handlers. Loggers map to areas of the
application, handlers map to output destinations. Loggers form a
hierarchy based on names
Ok, so I've figured this out (see below),
mail = logging.handlers.SMTPHandler('mail.vw.com',
'[EMAIL PROTECTED]',
'[EMAIL PROTECTED]',
'Data Processing Error at
location: %s' %
One thing that made little sense to me when I was first working on
this is the following variation on the original script:
#--begin test script--
import logging
forest = ["root","trunk","branch","leaf"]
lumber_jack = {forest[0] : logging.DEBUG
,forest[1] : logging.INFO
> "Diez" == Diez B Roggisch <[EMAIL PROTECTED]> writes:
Diez> Chris Smith schrieb:
>> Hola, pythonisas: The documentation for the logging module is
>> good, but a bit obscure. In particular, there seems to be a
>> lot of action at a distance. The fact that getLogger() can
Chris Smith schrieb:
> Hola, pythonisas:
> The documentation for the logging module is good, but a bit obscure.
> In particular, there seems to be a lot of action at a distance.
> The fact that getLogger() can actually be a call to Logger.__init__(),
> which is mentioned in para 6.29.1, also bea
67 matches
Mail list logo
