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 10:41 AM, raymond.hettinger
wrote:
> Author: raymond.hettinger
> Date: Sat Dec 11 01:41:02 2010
> New Revision: 87162
>
> Log:
> Issue 2690: Doc fixup. xrange() objects are slicable.
>
>
> Modified:
> python/branches/release27-maint/Doc/library/stdtypes.rst
Are you sur
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 Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote:
> On 12/10/2010 4:59 PM, R. David Murray wrote:
>
>> Like Éric, I'm not sure what the implications of the existing module
>> having been released in 2.7 and 3.2 beta are in terms of making such an
>> API change.
>
> I am with Raymond on this: th
On Sat, Dec 11, 2010 at 7:59 AM, R. David Murray wrote:
> On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger
> wrote:
>> ISTM it mostly could have been reduced to single call returning a nested
>> dictionary.
>
> If what was returned was, as you suggested on IRC, a set of named tuples,
> it
On 12/10/2010 4:59 PM, R. David Murray wrote:
Like Éric, I'm not sure what the implications of the existing module
having been released in 2.7 and 3.2 beta are in terms of making such an
API change.
I am with Raymond on this: the purpose of betas is so we can test *and*
make changes. No one s
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
On Sat, Dec 11, 2010 at 6:07 AM, Brian Quinlan wrote:
> AFAIK, catching KeyboardInterrupt exceptions is not sufficient.
Getting away from the flaws in the test code in this thread, is there
any particular reason futures is rolling its own variant of
weakref.WeakSet for the _thread_references clea
On Sat, Dec 11, 2010 at 6:07 AM, Brian Quinlan wrote:
>> The problem also occurs when using a callback:
>> http://www.freehackers.org/~tnagy/futures_test2.py
>>
>> If it is necessary to catch KeyboardInterrupt exceptions to cancel the
>> futures execution, then how about adding this detail to the
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
On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger
wrote:
> Does anyone know why this needed a separate module and so many accessor
> functions?
Originally sysconfig was moved *out* of distutils, and distutils was
changed to use it. But that proved to be as fragile as many other
distutils c
On Dec 10, 2010, at 12:56 PM, Antoine Pitrou wrote:
> On Fri, 10 Dec 2010 12:27:26 -0800
> Raymond Hettinger wrote:
>>
>> IMO, sysconfig did not warrant a whole module.
>
> Where would you put it?
A single function in the sys module.
>
>> Rather than using two levels of dictionary, it's als
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:27:26 -0800
Raymond Hettinger wrote:
>
> IMO, sysconfig did not warrant a whole module.
Where would you put it?
> Rather than using two levels of dictionary, it's also possible
> to use a named tuple if you think that is more clean looking:
>
>>>> c = sys.sysconfig()
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
On Dec 10, 2010, at 6:20 AM, Éric Araujo wrote:
> Final note: with 3.2 being in beta, I don’t know how much can be changed
> now.
Part of the purpose of a beta, and in our case, two betas is to give
people a chance to exercise new APIs and fix them before they
become set in stone two months later
On Dec 10, 2010, at 11:39 AM, Thomas Nagy wrote:
--- El vie, 10/12/10, Thomas Nagy escribió:
--- El vie, 10/12/10, Brian Quinlan
escribió:
On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote:
I have a process running for a long time, and
which
may use futures of different max_workers count. I
--- El vie, 10/12/10, Thomas Nagy escribió:
> --- El vie, 10/12/10, Brian Quinlan
> escribió:
> > On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote:
> > > I have a process running for a long time, and
> which
> > may use futures of different max_workers count. I
> think it
> > is not too far-fetched
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
On Dec 10, 2010, at 10:51 AM, Thomas Nagy wrote:
--- El vie, 10/12/10, Brian Quinlan escribió:
On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote:
I have a process running for a long time, and which
may use futures of different max_workers count. I think it
is not too far-fetched to create a new
--- El vie, 10/12/10, Brian Quinlan escribió:
> On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote:
> > I have a process running for a long time, and which
> may use futures of different max_workers count. I think it
> is not too far-fetched to create a new futures object each
> time. Yet, the executi
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
On Thu, Dec 9, 2010 at 11:17 AM, Antoine Pitrou wrote:
> On Thu, 9 Dec 2010 13:55:08 -0500
> Alexander Belopolsky wrote:
>
>> On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum wrote:
>> ..
>> > string-string transforms use the same namespace even though the
>> > typical transform only supports on
Oops. I accidentally replied off-list:
On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote:
--- El jue, 9/12/10, Brian Quinlan escribió:
On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote:
I am looking forward to replacing a piece of code (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner
On Fri, Dec 10, 2010 at 11:36 PM, Thomas Nagy wrote:
> fut = concurrent.futures.ThreadPoolExecutor(max_workers=20)
> for x in range(100):
> # comment the following line
> fut = concurrent.futures.ThreadPoolExecutor(max_workers=20)
> c = counter(fut)
> c.run()
> """
> The runtime gr
ACTIVITY SUMMARY (2010-12-03 - 2010-12-10)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2557 (+20)
closed 19899 (+38)
total 22456 (+58)
Open issues wit
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
Hi,
Original discussion for the sysconfig module was short:
http://mail.python.org/pipermail/python-dev/2009-May/089520.html
Tarek will reply better, but I think the issue to solve was to move
sysconfig out of distutils, improving its API a bit in the process but
not overhauling it completely. A
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
--- El jue, 9/12/10, Brian Quinlan escribió:
> On Dec 9, 2010, at 4:26 AM, Thomas Nagy wrote:
>
> > I am looking forward to replacing a piece of code
> > (http://code.google.com/p/waf/source/browse/trunk/waflib/Runner.py#86)
> by the futures module which was announced in python 3.2
> beta. I am a
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
On Fri, Dec 10, 2010 at 9:42 PM, vinay.sajip wrote:
> Author: vinay.sajip
> Date: Fri Dec 10 12:42:57 2010
> New Revision: 87157
>
> Log:
> logging: added handler of last resort.
Nice, that ended up fitting in quite neatly.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
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
50 matches
Mail list logo
