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 Thu, Dec 9, 2010 at 12:47 AM, "Martin v. Löwis" wrote:
..
>> However, in Python 3.2b1 the library python32.lib contains only
>> _PyUnicode_IsWhitespace, therefore breaking the build.
>>
>> Is this change intentional? If so, why does unicodeobject.h still do
>> the mapping?
>
> Are you sure abou
Am 09.12.2010 03:56, schrieb MRAB:
> The regex module calls _PyUnicode_IsWhitespace, which is mapped by
> unicodeobject.h to either _PyUnicodeUCS2_IsWhitespace or
> _PyUnicodeUCS4_IsWhitespace.
>
> From Python 2.5 to Python 3.1 the library pythonXX.lib contains either
> _PyUnicodeUCS2_IsWhitespace
Hello,
> Author: raymond.hettinger
> Date: Mon Nov 29 02:38:25 2010
> New Revision: 86855
> Log: Do not add an obsolete unittest name to Py3.2.
> Modified: python/branches/py3k/Lib/unittest/case.py
> -# Old name for assertCountEqual()
> -assertItemsEqual = assertCountEqual
When we merge
The regex module calls _PyUnicode_IsWhitespace, which is mapped by
unicodeobject.h to either _PyUnicodeUCS2_IsWhitespace or
_PyUnicodeUCS4_IsWhitespace.
From Python 2.5 to Python 3.1 the library pythonXX.lib contains either
_PyUnicodeUCS2_IsWhitespace or _PyUnicodeUCS4_IsWhitespace.
However, in
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
2010/12/8 Ben Finney :
> Benjamin Peterson writes:
>
>> 2010/12/8 Kirk McDonald :
>> > What is the status of PEP 3143? It appears to be aimed at 3.2, but
>> > there does not appear to be a resolution on it.
>
> I am the PEP 3143 author and champion. It hasn't been presented for a
> resolution yet.
Benjamin Peterson writes:
> 2010/12/8 Kirk McDonald :
> > What is the status of PEP 3143? It appears to be aimed at 3.2, but
> > there does not appear to be a resolution on it.
I am the PEP 3143 author and champion. It hasn't been presented for a
resolution yet.
Development of the reference imp
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.
Am 08.12.2010 21:12, schrieb Benjamin Peterson:
> 2010/12/8 Kirk McDonald :
>> What is the status of PEP 3143? It appears to be aimed at 3.2, but there
>> does not appear to be a resolution on it.
>
> It's after beta freeze now, so definitely not 3.2. AFAIK, though, it's
> never been discussed her
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. :-)
2010/12/8 Kirk McDonald :
> What is the status of PEP 3143? It appears to be aimed at 3.2, but there
> does not appear to be a resolution on it.
It's after beta freeze now, so definitely not 3.2. AFAIK, though, it's
never been discussed here.
--
Regards,
Benjamin
__
What is the status of PEP 3143? It appears to be aimed at 3.2, but there
does not appear to be a resolution on it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
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
Antoine Pitrou pitrou.net> writes:
> However, there are some limitations due to the fact that logging is
> line-based while people may output arbitrary text on stderr (perhaps
> ASCII-formatted tables, who knows).
True, though the wrapper could easily buffer partial output internally to
support
On Thu, 9 Dec 2010 03:28:36 +1000
Nick Coghlan wrote:
> On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip wrote:
> > Nick Coghlan gmail.com> writes:
> >> P.S. On a completely unrelated note, has anyone thought about creating
> >> a write-only TextIO stream that outputs received writes via the
> >> lo
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
On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>> 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?
>>
>
> Is this for use at the C level? At the Python
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
>
On Wed, 8 Dec 2010 01:19:45 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou 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. Everything's documented reasonabl
On Wed, 08 Dec 2010 09:09:45 +0100
Georg Brandl wrote:
> Am 08.12.2010 01:09, schrieb Antoine Pitrou:
> > On Tue, 7 Dec 2010 23:45:39 + (UTC)
> > Vinay Sajip wrote:
> >> Antoine Pitrou pitrou.net> writes:
> >>
> >> >
> >> > I thought "error" and "critical" messages were logged to stderr b
On Wed, 8 Dec 2010 01:51:44 + (UTC)
Vinay Sajip 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 basicConfig(): deb
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 it for his users?
Because the ap
Nick Coghlan 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 was nothi
Am 07.12.2010 09:24, schrieb Łukasz Langa:
> Wiadomość napisana przez Georg Brandl w dniu 2010-12-06, o godz. 22:46:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On behalf of the Python development team, I'm happy to announce the
>> first of two beta preview releases of Python 3.2.
Am 08.12.2010 01:09, schrieb Antoine Pitrou:
> On Tue, 7 Dec 2010 23:45:39 + (UTC)
> Vinay Sajip wrote:
>> Antoine Pitrou pitrou.net> writes:
>>
>> >
>> > I thought "error" and "critical" messages were logged to stderr by
>> > default? Isn't it the case?
>> >
>>
>> Only if you call basicC
56 matches
Mail list logo
