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 pa
On Mon, Dec 13, 2010 at 2:13 PM, Robert Kern 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 Python 2.6
On 2010-12-12 21:30 , Nick Coghlan wrote:
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kern 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 "I
On Mon, Dec 13, 2010 at 11:22 AM, Robert Kern 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 available, it woul
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
m
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, b
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 simp
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:
http://mail.python.org/mailman/options/python-dev/archi
On 10 December 2010 20:57, Glenn Linderman 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 displaying only err
Nick Coghlan 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 Sun, Dec 12, 2010 at 5:32 AM, Brett Cannon wrote:
> On Fri, Dec 10, 2010 at 22:21, Vinay Sajip wrote:
>> Nick Coghlan gmail.com> writes:
>>
>>
>>> This could actually make a reasonably good basic for a "task oriented"
>>> subsection of the logging documentation. Something like:
>>>
>>
>> Good
On Fri, Dec 10, 2010 at 22:21, Vinay Sajip wrote:
> Nick Coghlan 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 wanted to +1 on some
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 is
On Sun, Dec 12, 2010 at 3:24 AM, Tres Seaver 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 -- stdout belongs
-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 shoul
On Sat, Dec 11, 2010 at 10:06 PM, Vinay Sajip wrote:
> Nick Coghlan 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,
> bu
Nick Coghlan 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 concurrent.f
Glenn Linderman 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 I'll read
On Sat, Dec 11, 2010 at 7:28 PM, Vinay Sajip wrote:
> Nick Coghlan 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 that front - the behaviour alrea
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 to
On 12/11/2010 1:28 AM, Vinay Sajip wrote:
Nick Coghlan 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 until 3.3 t
On 12/11/2010 12:00 AM, Nick Coghlan wrote:
On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman 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,
Nick Coghlan 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 in the
On Sat, Dec 11, 2010 at 3:06 PM, Nick Coghlan 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 resolving
> this is
Glenn Linderman 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 effort i
On Sat, Dec 11, 2010 at 4:18 PM, Vinay Sajip 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, str.format and str
On Sat, Dec 11, 2010 at 6:00 PM, Nick Coghlan 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 the Python Co
On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman 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 may be multiple
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 by
Nick Coghlan 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
___
Python-Dev mail
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 s
On Sat, Dec 11, 2010 at 3:06 PM, Nick Coghlan 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
> should be
On Sat, Dec 11, 2010 at 12:42 PM, Terry Reedy 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 "right
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 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
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 module
Bill Janssen 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.
>
Although e.g
Antoine Pitrou pitrou.net> writes:
> Guido van Rossum 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 silencing ot
Glenn Linderman 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 what I thought I'd ge
Guido van Rossum 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 reading the 2.
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 expecte
On Fri, 10 Dec 2010 12:31:19 -0800
Guido van Rossum 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 not. Imagine
On Fri, Dec 10, 2010 at 11:39 AM, Vinay Sajip wrote:
> Bill Janssen 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 warning
Bill Janssen 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 WARNIN
Glenn Linderman 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 the lo
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
Antoine Pitrou 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 it's in t
On Fri, 10 Dec 2010 12:34:48 + (UTC)
Vinay Sajip 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
> > principally bet
Antoine Pitrou 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 first fo
Hey Vinay,
On Fri, 10 Dec 2010 11:46:18 + (UTC)
Vinay Sajip wrote:
> Terry Reedy 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
Terry Reedy 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 behaviour can
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.
>
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 scare
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 tha
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__ they'l
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
Gregory P. Smith 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 root l
On Wed, Dec 8, 2010 at 9:51 AM, Glenn Linderman
> 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 could be wrong
> about this, but I don'
On Tue, Dec 7, 2010 at 5:51 PM, Vinay Sajip wrote:
> Nick Coghlan 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 why you'd be surpri
Glenn Linderman 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 servicing that
On 12/9/2010 12:26 AM, Vinay Sajip wrote:
Glenn Linderman 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 ov
Vinay Sajip yahoo.co.uk> writes:
>
> Glenn Linderman 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 the post is to be di
Glenn Linderman 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 knowing wh
On Thu, Dec 9, 2010 at 4:49 AM, Paul Moore wrote:
> On 8 December 2010 14:52, Nick Coghlan 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
On 12/8/2010 9:43 AM, Vinay Sajip wrote:
As am off-topic example, Armin Ronacher kept on saying in various posts and
presentations that you couldn't use stdlib logging for web applications, that
there were fundamental problems with it. But when he actually sent me his
specific problem statement
Paul Moore gmail.com> writes:
> You misunderstand me. I know that's how those levels work. What I'm
> not sure about (and I think would be interesting and potentially
> useful information) is whether the individuals participating in this
> thread feel that liberal use of info and debug level logg
On 8 December 2010 19:04, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>>
>> On 8 December 2010 14:52, Nick Coghlan 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 slightl
On 12/8/2010 2:00 PM, Vinay Sajip wrote:
Actually, I don't think my response to Nick's post (about concurrent.futures)
could be characterized as "I don't care", as I even made a specific proposal
about how a change could be implemented.
Your proposal struck me as probably the best way forward.
If we're all converging on adding a "handler of last resort" and dropping the
warning message, we can just let this branch of the thread drop. But if you want
to continue, I already had most of the following already written. I hope it
clears some things up more than it muddies them further. :-)
Vinay Sajip 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
http://mail.python.org/mailman/listinfo
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 un
Antoine Pitrou 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
http://mail.python
On Wed, 8 Dec 2010 19:00:31 + (UTC)
Vinay Sajip 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
>
> No, I'm not i
>> 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 inf
Nick Coghlan 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 applicatio
Paul Moore gmail.com> writes:
>
> On 8 December 2010 14:52, Nick Coghlan 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
>
Antoine Pitrou 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 errors.
I d
On 8 December 2010 14:52, Nick Coghlan 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 level logging? In ef
On Wed, 8 Dec 2010 14:54:09 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou 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.
> >
> > (o
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
Robert Kern 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 write an ap
On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip wrote:
> Nick Coghlan 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
Nick Coghlan 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 any dr
On 12/8/10 2:51 AM, Vinay Sajip wrote:
Robert Kern 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
On Wed, Dec 8, 2010 at 9:52 AM, Nick Coghlan 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
idea was to prepen
On Thu, Dec 9, 2010 at 12:27 AM, Antoine Pitrou wrote:
> On Wed, 8 Dec 2010 12:15:53 + (UTC)
> Vinay Sajip 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 as you suggest
>> (because in
>>
On Thu, Dec 9, 2010 at 12:43 AM, Fred Drake wrote:
> On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou 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
Antoine Pitrou 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
> that
On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou 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
except the message abo
On Wed, 8 Dec 2010 12:15:53 + (UTC)
Vinay Sajip 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 silenced. I'm willing
On Wed, Dec 8, 2010 at 8:19 AM, Paul Moore 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
NullHandler for that, th
Paul Moore 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 by def
Am 08.12.2010 13:22, schrieb Vinay Sajip:
> Antoine Pitrou pitrou.net> writes:
>
>>
>> On Wed, 08 Dec 2010 11:48:16 +0100
>> Georg Brandl 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 t
On 8 December 2010 12:15, Vinay Sajip 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 to inform the user abo
On 8 December 2010 08:32, Vinay Sajip wrote:
> Nick Coghlan 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 useful (i.e. warnings and
>> err
Antoine Pitrou pitrou.net> writes:
>
> On Wed, 08 Dec 2010 11:48:16 +0100
> Georg Brandl 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 using
> it (think
Antoine Pitrou 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 time
On Wed, 08 Dec 2010 11:48:16 +0100
Georg Brandl 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.
> > http://docs.python.org/dev/library/logging.html
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, Dec 8, 2010 at 6:32 PM, Vinay Sajip 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 "handler of last
>
1 - 100 of 127 matches
Mail list logo
