On 07/12/2010 20:26, Vinay Sajip wrote:
I would suggest that when unit testing, rather than adding StreamHandlers to log
to stderr, that something like TestHandler and Matcher from this post:
http://plumberjack.blogspot.com/2010/09/unit-testing-and-logging.html
For Python 2, my testfixtures
On Sun, Dec 12, 2010 at 5:32 AM, Brett Cannon br...@python.org wrote:
On Fri, Dec 10, 2010 at 22:21, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
This could actually make a reasonably good basic for a task oriented
subsection of the logging
Nick Coghlan ncoghlan at gmail.com writes:
Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and
highlighting the typos and omissions. I've just checked in a further update;
hopefully it'll get built soon so we can all see the latest changes.
Regards,
Vinay Sajip
On 10 December 2010 20:57, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 12/10/2010 12:49 PM, Antoine Pitrou wrote:
And yet, I have helped many people who were baffled by exactly what
Bill observed: logging.info() didn't do anything. Maybe the default
should be INFO?
Funny, because
Hi,
I suggest to replace “error” with “event” in the module doc synopsis.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 12/12/2010 2:26 PM, Paul Moore wrote:
The thing*I* hit very early was wanting to add a command lime option
to my script to set the logging level. I'd have liked to be able to
add --log=INFO/DEBUG/... but to do that I seem to need to write my own
mapping between level names and numbers. A
On 12/12/2010 9:41 AM, Vinay Sajip wrote:
Gosh, Nick, that was fast! I'm still making changes, but thanks for spotting and
highlighting the typos and omissions. I've just checked in a further update;
hopefully it'll get built soon so we can all see the latest changes.
I'm not as fast as Nick,
On 2010-12-12 18:42 , Glenn Linderman wrote:
On 12/12/2010 2:26 PM, Paul Moore wrote:
The thing*I* hit very early was wanting to add a command lime option
to my script to set the logging level. I'd have liked to be able to
add --log=INFO/DEBUG/... but to do that I seem to need to write my own
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kern robert.k...@gmail.com wrote:
level = getattr(logging, opt.logLevel)
While this is the approach I would recommend, it does have a couple of
downsides:
1. An upper() call is also needed to allow strings like info instead
of INFO:
2. If an integer is
On 2010-12-12 21:30 , Nick Coghlan wrote:
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kernrobert.k...@gmail.com wrote:
level = getattr(logging, opt.logLevel)
While this is the approach I would recommend, it does have a couple of
downsides:
1. An upper() call is also needed to allow strings
On Mon, Dec 13, 2010 at 2:13 PM, Robert Kern robert.k...@gmail.com wrote:
level = logging._levelNames[opt.logLevel]
That doesn't work (_levelNames maps from integers to strings, we want
the mapping from strings to integers and it is only the module globals
that provides that).
At least in
On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 12/10/2010 9:24 PM, Nick Coghlan wrote:
This could actually make a reasonably good basic for a task oriented
subsection of the logging documentation. Something like:
Yep, agree. But sadly, for each point, there
On Sat, Dec 11, 2010 at 6:00 PM, Nick Coghlan ncogh...@gmail.com wrote:
What may make more sense than yet another global config mechanism, is
a module level addHandler helper function along the following lines:
For a more readable version of that example, take a look at the copy I
put up over
On Sat, Dec 11, 2010 at 4:18 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
formatting (when the documentation for the new styles feature goes in
would probably be an appropriate time to fix this). Similarly, the
Sorry, what do you mean by new styles feature?
The switching between percent,
Glenn Linderman v+python at g.nevcal.com writes:
Yep, agree. But sadly, for each point, there may be multiple
options (your StreamHandler, but I'd want a FileHandler; your
separation of messages by level, my wanting them combined; etc.)
That's partly why logging hasn't made much
On Sat, Dec 11, 2010 at 3:06 PM, Nick Coghlan ncogh...@gmail.com wrote:
However, the confusion that this setup will engender is that
encountered by Bill: by default, info() messages are silenced rather
than displayed on stdout.
Notice that even the recommended basicConfig approach to
Nick Coghlan ncoghlan at gmail.com writes:
The switching between percent, str.format and string.Template
formatting. It turns out that has been documented, but the table in
question is still written from a percent-style formatting point of
view.
Oh, right - yes. I presume you mean the table
On 12/11/2010 12:00 AM, Nick Coghlan wrote:
On Sat, Dec 11, 2010 at 4:25 PM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
On 12/10/2010 9:24 PM, Nick Coghlan wrote:
This could actually make a reasonably good basic for a task oriented
subsection of the logging documentation. Something like:
On 12/11/2010 1:28 AM, Vinay Sajip wrote:
Nick Coghlanncoghlanat gmail.com writes:
The lazy stream handler might be useful to make public in some way.
For example, rather than hardcoding sys.stderr, it could take a
callable that it uses to retrieve the stream. That kind of change can
wait
On 12/11/2010 1:07 AM, Nick Coghlan wrote:
As Glenn mentioned later in the thread, the output of logging.info and
logging.debug messages is*distinct* from an application's normal
operational output that is emitted on stdout. So making it easy to
emit such messages on stderr is the right thing
On Sat, Dec 11, 2010 at 7:28 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Actually if we're to change things to print INFO to stdout and WARNING+ to
stderr,
I suspect our messages crossed paths in mid-stream, but I actually
realised I was wrong on
Glenn Linderman v+python at g.nevcal.com writes:
the logger. Does basicConfig give that control? I don't know, the
first 8% of the logger documentation don't tell me that, they only
give me a canned example (actually 3) without explanation of its
full function. Someday
Nick Coghlan ncoghlan at gmail.com writes:
the logging module is a tool to track what is happening in a program, not a
tool for providing a console based UI.
That was certainly the thinking behind how it worked before my recent changes,
but I completely accept that it wasn't helpful in the
On Sat, Dec 11, 2010 at 10:06 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
the logging module is a tool to track what is happening in a program, not a
tool for providing a console based UI.
That was certainly the thinking behind how it worked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/11/2010 04:28 AM, Vinay Sajip wrote:
Actually if we're to change things to print INFO to stdout and WARNING+ to
stderr,
ACK! That would be an awful default -- stdout belongs to the
application, not to meta stuff like logging, which should
On Sun, Dec 12, 2010 at 3:24 AM, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/11/2010 04:28 AM, Vinay Sajip wrote:
Actually if we're to change things to print INFO to stdout and WARNING+ to
stderr,
ACK! That would be an awful default --
On 12/11/2010 3:52 AM, Vinay Sajip wrote:
I will try to incorporate more basic examples at the top of the documentation,
but surely you don't want me to add more verbiage about basicConfig when your
overall feeling is that there's too much documentation?
I try not to post unless I feel there
On Fri, Dec 10, 2010 at 22:21, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
This could actually make a reasonably good basic for a task oriented
subsection of the logging documentation. Something like:
Good suggestion, I'll see what I can do.
Just
Gregory P. Smith greg at krypto.org writes:
Hahaha. :) Well, I won't be suggesting to anyone at work that we throw away
our entire bazillion line codebase just because all of it happily relies on
logging.{debug,info,warn,error,exception} functions and all log messages go
through a single
On 12/10/2010 12:06 AM, Vinay Sajip wrote:
This simplistic easy usage somewhat echo's Glenn's comment on this thread
about logging seeming way to daunting as presented today. It needn't be.
Indeed, and the very first code sample in the logging documentation shows
exactly the simplistic
On 12/9/2010 8:29 PM, Gregory P. Smith wrote:
Exactly. All I ever recommend people do is:
import logging
...
logging.warn('doing something a bit odd.')
...
for x in thing:
logging.debug('working on %r', x)
...
And be done with it. If they are controlling their __main__
Vinay Sajip writes:
Indeed, and the very first code sample in the logging documentation
shows exactly the simplistic easy usage you're talking about. I
can't see why anyone would be scared off by that example.
They're not scared by that example. What you need is a paragraph
below it that
On 12/10/2010 10:47 AM, Stephen J. Turnbull wrote:
Vinay Sajip writes:
Indeed, and the very first code sample in the logging documentation
shows exactly the simplistic easy usage you're talking about. I
can't see why anyone would be scared off by that example.
They're not scared
On Fri, Dec 10, 2010 at 06:47:50PM +0900, Stephen J. Turnbull wrote:
Vinay Sajip writes:
Indeed, and the very first code sample in the logging documentation
shows exactly the simplistic easy usage you're talking about. I
can't see why anyone would be scared off by that example.
Terry Reedy tjreedy at udel.edu writes:
Your proposal struck me as probably the best way forward. Can you code
it up and put a patch on the tracker that people can test before the
next beta?
Coded up (including unit test) and checked into py3k branch, r87157. Regressions
pass OK. Old
Hey Vinay,
On Fri, 10 Dec 2010 11:46:18 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Terry Reedy tjreedy at udel.edu writes:
Your proposal struck me as probably the best way forward. Can you code
it up and put a patch on the tracker that people can test before the
next beta?
Antoine Pitrou solipsis at pitrou.net writes:
Hi Antoine,
When you make significant changes outside of logging, it would be nice
if you first opened an issue and posted the patch for review. There's
nothing obviously wrong with what you committed, but I think it's
principally better to ask
On Fri, 10 Dec 2010 12:34:48 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
When you make significant changes outside of logging, it would be nice
if you first opened an issue and posted the patch for review. There's
nothing obviously wrong with what you committed, but I think it's
Antoine Pitrou solipsis at pitrou.net writes:
Yes, I am talking about this one. I am not asking that you revert it; I
am just saying that it is generally appreciated if substantial patches
get proposed on the tracker before being committed.
OK, sorry - point taken.
In this case since
Oleg Broytman writes:
Better yet (IMHO) would be to split the huge page into Logging: Simple
start and Logging: Advanced usage (for the brave of of heart).
Splitting is OK, but I disagree about the gloss for the brave of
heart.
In my experience, if it is a YAGNI, the complexity is nearly
Glenn Linderman v+pyt...@g.nevcal.com wrote:
On 12/10/2010 12:06 AM, Vinay Sajip wrote:
This simplistic easy usage somewhat echo's Glenn's comment on this
thread
about logging seeming way to daunting as presented today. It needn't be.
Indeed, and the very first code sample in
Bill Janssen janssen at parc.com writes:
Liked it just fine -- easier to write. But nothing came out! Because
it's got this odd idea (from Java?) about severities of messages, and
by default passes nothing less threatening than warnings, because
logger.root is initialized by default to
On Fri, Dec 10, 2010 at 11:39 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Bill Janssen janssen at parc.com writes:
Liked it just fine -- easier to write. But nothing came out! Because
it's got this odd idea (from Java?) about severities of messages, and
by default passes nothing less
On Fri, 10 Dec 2010 12:31:19 -0800
Guido van Rossum gu...@python.org wrote:
The default setting of WARNING is not from Java either - it's the Unix idea
that
verbosity should be kept to a minimum unless specifically requested. So,
warnings and errors should be shown, but info and debug
On 12/10/2010 12:49 PM, Antoine Pitrou wrote:
And yet, I have helped many people who were baffled by exactly what
Bill observed: logging.info() didn't do anything. Maybe the default
should be INFO?
Funny, because displaying only errors and silencing other messages is
exactly what I expected
Guido van Rossum gu...@python.org wrote:
And yet, I have helped many people who were baffled by exactly what
Bill observed: logging.info() didn't do anything. Maybe the default
should be INFO?
Yeah, I was curious enough to read the code and find out why. But many
won't.
By the way, I tried
Glenn Linderman v+pyt...@g.nevcal.com wrote:
1) simple example for one file programs, include an example of
specifying output severity threshold. I'm with Antoine here on my
expectations.
Yes, once I put
logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)
in my main(), I got
Antoine Pitrou solipsis at pitrou.net writes:
Guido van Rossum guido at python.org wrote:
And yet, I have helped many people who were baffled by exactly what
Bill observed: logging.info() didn't do anything. Maybe the default
should be INFO?
Funny, because displaying only errors and
Bill Janssen janssen at parc.com writes:
stdlib, you don't want that default. I think that logging events
(context) have to come into this; you can't do it with just severity
alone. I'd expect to have different settings, by default, for __main__
and for http.client, for instance.
Glenn Linderman writes:
1) simple example for one file programs, include an example of
specifying output severity threshold. I'm with Antoine here on my
expectations.
2) example for multi-module, showing how a single logging destination
causes logging to happen in all modules, at
On 12/10/2010 5:16 PM, Vinay Sajip wrote:
IMO as long as it's just a small amount of work to get the specific effect
that you want, it doesn't really matter too much what the default is - though
of course I'd like it to be right, whatever that means ;-)
I think the default should accomodate
Stephen J. Turnbull wrote:
They're not scared by that example. What you need is a paragraph
below it that says
Do you think the above is all you should need? If so, you're
right. You can stop reading now. If you think you need more,
we've got that, too. Read on (you may
On Sat, Dec 11, 2010 at 12:42 PM, Terry Reedy tjre...@udel.edu wrote:
On 12/10/2010 5:16 PM, Vinay Sajip wrote:
IMO as long as it's just a small amount of work to get the specific effect
that you want, it doesn't really matter too much what the default is -
though
of course I'd like it to be
On Sat, Dec 11, 2010 at 3:06 PM, Nick Coghlan ncogh...@gmail.com wrote:
Basically, as of 3.2, the correct default use is likely to be:
print() for information you want to appear on stdout by default
(especially in scripts)
logging.debug() and .info() for additional debugging information that
Nick,
Thanks for the detailed exposition.
Notice that even the recommended basicConfig approach to resolving
this is subtly flawed, since your choices are to either display info
Right. basicConfig() is pretty basic.
Basically, as of 3.2, the correct default use is likely to be:
The
Nick Coghlan ncoghlan at gmail.com writes:
This could actually make a reasonably good basic for a task oriented
subsection of the logging documentation. Something like:
Good suggestion, I'll see what I can do.
Thanks,
Vinay Sajip
___
On 12/10/2010 9:06 PM, Nick Coghlan wrote:
Anyway, the shortest way I could find of setting this up (debug
silenced, info written to stdout, warning and above written to
stderr):
import sys, logging
root = logging.getLogger()
# Turns out the level of the root logger is set to WARNING
Glenn Linderman v+python at g.nevcal.com writes:
Or what am I missing?
That threads are not necessarily dedicated to apps, in a real world setting.
Depending on the server implementation, a single thread could be asked to handle
requests for different apps over its lifetime. So the only way of
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
Glenn Linderman v+python at g.nevcal.com writes:
Or what am I missing?
And one more thing: the filters for *both* apps are called for a given request.
One will return True, the other will return False.
Bear in mind that the intention of
On 12/9/2010 12:26 AM, Vinay Sajip wrote:
Glenn Lindermanv+pythonat g.nevcal.com writes:
Or what am I missing?
That threads are not necessarily dedicated to apps, in a real world setting.
Depending on the server implementation, a single thread could be asked to handle
requests for
Glenn Linderman v+python at g.nevcal.com writes:
Agreed, they are not necessarily dedicated to apps. But while they
are running the app, they have the appname in their thread local
storage, no? So if a thread has the appname in its thread local
storage, is it not
On Tue, Dec 7, 2010 at 5:51 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Indeed - I was very surprised to find just now that calling
logging.warn('Whatever') is not the same as doing log =
logging.getLogger(); log.warn('Whatever').
Don't know
On Wed, Dec 8, 2010 at 9:51 AM, Glenn Linderman
v+pyt...@g.nevcal.comv%2bpyt...@g.nevcal.com
wrote:
On 12/8/2010 4:15 AM, Vinay Sajip wrote:
You're complaining about too much documentation?! Don't measure it by weight!
On 12/8/2010 5:57 AM, Vinay Sajip wrote:
Of course I understand I
Am 08.12.2010 01:09, schrieb Antoine Pitrou:
On Tue, 7 Dec 2010 23:45:39 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at pitrou.net writes:
I thought error and critical messages were logged to stderr by
default? Isn't it the case?
Only if you
Nick Coghlan ncoghlan at gmail.com writes:
The surprise came from not realising there was a basicConfig() call
hidden inside the convenience APIs, a fact which is *not* mentioned in
the docstrings. It may be mentioned in the main documentation, but I
didn't look at that at the time - there
Robert Kern robert.kern at gmail.com writes:
I really don't understand how this view can be consistent with the
practice of adding NullHandler to loggers. If this message is so important
to prevent misconfiguration, then why should a library author decide to
silence it for his users?
On Wed, 8 Dec 2010 01:51:44 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Adding a NullHandler isn't the right thing to do - the behaviour I
would want for any standard library logging that hasn't been
explicitly configured otherwise is to do what the root logger does
under
On Wed, 08 Dec 2010 09:09:45 +0100
Georg Brandl g.bra...@gmx.net wrote:
Am 08.12.2010 01:09, schrieb Antoine Pitrou:
On Tue, 7 Dec 2010 23:45:39 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at pitrou.net writes:
I thought error and critical
On Wed, 8 Dec 2010 01:19:45 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at pitrou.net writes:
Why wouldn't it be the default for all logging calls ? Such special
cases don't really make things easy to remember.
One size doesn't fit all.
On Wed, Dec 8, 2010 at 6:32 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Thanks for the detailed explanation. I agree that unraisable warnings and
errors
need to be handled somehow. There is a way in which this can be done without
affecting a logging configuration, viz. logging can define a
Am 08.12.2010 10:42, schrieb Antoine Pitrou:
But errors don't pass silently, do they? The usual way to present errors
is still by raising exceptions.
Or logging them.
http://docs.python.org/dev/library/logging.html#logging.Logger.exception
Yes, thank you I'm aware of the exception()
On Wed, 08 Dec 2010 11:48:16 +0100
Georg Brandl g.bra...@gmx.net wrote:
Am 08.12.2010 10:42, schrieb Antoine Pitrou:
But errors don't pass silently, do they? The usual way to present errors
is still by raising exceptions.
Or logging them.
Antoine Pitrou solipsis at pitrou.net writes:
My point is that the default behaviour should be helpful.
I can't disagree with that. Now if only we could agree what we mean by default
and helpful ;-)
I would point out that logging is really the kind of thing people don't
want to spend
Antoine Pitrou solipsis at pitrou.net writes:
On Wed, 08 Dec 2010 11:48:16 +0100
Georg Brandl g.brandl at gmx.net wrote:
But hopefully standard
library modules don't use it to report exceptions to code that uses them?
I'm not aware of that, but there are certainly third-party libs
On 8 December 2010 08:32, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
I'm not proposing that the standard library be special-cased, I'm
proposing that the default behaviour of an unconfigured logging module
in general be changed to something more
On 8 December 2010 12:15, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
The Java thing is a red herring, I believe. It's more akin to the Unix idea of
minimum verbosity as a default.
And yet Unix invented the concept of stderr, precisely to ensure that
there's a route for things the program wants
Am 08.12.2010 13:22, schrieb Vinay Sajip:
Antoine Pitrou solipsis at pitrou.net writes:
On Wed, 08 Dec 2010 11:48:16 +0100
Georg Brandl g.brandl at gmx.net wrote:
But hopefully standard
library modules don't use it to report exceptions to code that uses them?
I'm not aware of that,
Paul Moore p.f.moore at gmail.com writes:
And yet Unix invented the concept of stderr, precisely to ensure that
there's a route for things the program wants to inform the user about
to get out.
The NullHandler approach could be seen as the equivalent of adding
2/dev/null to every command
On Wed, Dec 8, 2010 at 8:19 AM, Paul Moore p.f.mo...@gmail.com wrote:
But you don't because the library developer added a NullHandler which
you have to switch off!!!
I'm suspecting there's misunderstanding on this point.
If I have a logger myns.mypackage for my library, and register a
On Wed, 8 Dec 2010 12:15:53 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
First, you cannot call it a default, since the library writer has to
make it explicit.
Second, I don't find that convenient at all. When I use a third-party
lib I want the errors to be displayed, not
On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
The thing is, they don't *want* to configure them, but you force them
to do some configuration if they don't want error messages to be
silenced.
As I tried to explain earlier, a NullHandler doesn't silence anything
Antoine Pitrou solipsis at pitrou.net writes:
I'm not talking specifically about exceptions, but about errors in
general. If the case wasn't common, I'm not sure why the error() and
critical() methods would exist at all.
(of course I'm assuming error() is meant to output error messages. If
On Thu, Dec 9, 2010 at 12:43 AM, Fred Drake fdr...@acm.org wrote:
On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
The thing is, they don't *want* to configure them, but you force them
to do some configuration if they don't want error messages to be
silenced.
As I
On Thu, Dec 9, 2010 at 12:27 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 8 Dec 2010 12:15:53 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
See my comments to Nick Coghlan's post about getting messages out when you
can't
raise an exception. I think the case is not as common
On Wed, Dec 8, 2010 at 9:52 AM, Nick Coghlan ncogh...@gmail.com wrote:
..
P.S. On a completely unrelated note, has anyone thought about creating
a write-only TextIO stream that outputs received writes via the
logging module?
I've done something similar for C++ iostreams many moons ago. The
On 12/8/10 2:51 AM, Vinay Sajip wrote:
Robert Kernrobert.kernat gmail.com writes:
I really don't understand how this view can be consistent with the
practice of adding NullHandler to loggers. If this message is so important
to prevent misconfiguration, then why should a library author
Nick Coghlan ncoghlan at gmail.com writes:
That said, while I think Vinay's suggested handler of last resort
solution is a good one and something we should be doing for 3.2, I'm
also happy to let the idea bake for at least a few weeks.
I agree on the baking part, since it will allow time for
On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
That said, while I think Vinay's suggested handler of last resort
solution is a good one and something we should be doing for 3.2, I'm
also happy to let the idea bake for at
Robert Kern robert.kern at gmail.com writes:
I'm sorry, but it's not at all clear that you have understood my point.
There is no way for me to parse your words as a sensible reply to what I
said.
Let's say I write a library called Foo. I want to add logging to my
functions. You want to
On 12/8/2010 4:15 AM, Vinay Sajip wrote:
You're complaining about too much documentation?! Don't measure it by weight!
On 12/8/2010 5:57 AM, Vinay Sajip wrote:
Of course I understand I could be wrong
about this, but I don't recall when a stdlib maintainer has said to me, I want
to start using
On Wed, 8 Dec 2010 14:54:09 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at pitrou.net writes:
I'm not talking specifically about exceptions, but about errors in
general. If the case wasn't common, I'm not sure why the error() and
critical() methods would
On 8 December 2010 14:52, Nick Coghlan ncogh...@gmail.com wrote:
As I see it, there aren't many cases at the *library* level where
logging errors is more appropriate than raising exceptions:
On a slightly tangential note, what do you think of the idea of
library code including info or debug
Antoine Pitrou solipsis at pitrou.net writes:
But since you are the one you wrote the library and added error() in
the first place, why are you trying to convince me that error() is
not useful? Perhaps you should explain how error() is supposed to be
used for if it's not supposed to log
Paul Moore p.f.moore at gmail.com writes:
On 8 December 2010 14:52, Nick Coghlan ncoghlan at gmail.com wrote:
As I see it, there aren't many cases at the *library* level where
logging errors is more appropriate than raising exceptions:
On a slightly tangential note, what do you think of
Nick Coghlan ncoghlan at gmail.com writes:
As a starting point, I'd say warnings and above, no formatting (i.e.
just the message). To minimise bikeshedding, I'd like to be guided by
the idea that this is a more configurable alternative to printing
directly to stderr, but in the absence of
On a slightly tangential note, what do you think of the idea of
library code including info or debug level logging? In effect,
tracing and diagnostic code built in and available simply by changing
the logging level?
Vinay That's how it works right now. You get info() and
On Wed, 8 Dec 2010 19:00:31 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
If you're interested in having a theoretical argument about what a
beautiful design should be (and if you want to argue about your own
design decisions), I'll leave the discussion here. I'm only interested
Antoine Pitrou solipsis at pitrou.net writes:
Ok, I'm sorry for the harsh words.
I really hope this discussions leads to somewhere.
No offence taken, and do do I :-)
Regards,
Vinay Sajip
___
Python-Dev mailing list
Python-Dev@python.org
skip at pobox.com writes:
logging.error(error 1 2 3 %s % yup)
ERROR:root:error 1 2 3 yup
logging.error(error 1 2 3 %s, yup)
ERROR:root:error 1 2 3 yup
The second form should be preferred in library code as long as the format
string expansion is deferred until after the
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
No offence taken, and do do I
s/do do/so do/
Perhaps it was a Freudian slip admitting that I *am* a dodo!
Regards,
Vinay
___
Python-Dev mailing list
Python-Dev@python.org
1 - 100 of 128 matches
Mail list logo
