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?
On Fri, Dec 10, 2010 at 9:42 PM, vinay.sajip python-check...@python.org 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 |
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
--- 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 bit
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
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.
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
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
On Fri, Dec 10, 2010 at 11:36 PM, Thomas Nagy tnagyemail-m...@yahoo.fr 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()
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
On Thu, Dec 9, 2010 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 9 Dec 2010 13:55:08 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Thu, Dec 9, 2010 at 1:42 PM, Guido van Rossum gu...@python.org wrote:
..
string-string transforms use the same namespace
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
--- 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 execution
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
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
--- 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 to create a
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
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 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 Fri, 10 Dec 2010 12:27:26 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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:
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
On Dec 10, 2010, at 12:56 PM, Antoine Pitrou wrote:
On Fri, 10 Dec 2010 12:27:26 -0800
Raymond Hettinger raymond.hettin...@gmail.com 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
On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger
raymond.hettin...@gmail.com 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
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.
On Sat, Dec 11, 2010 at 6:07 AM, Brian Quinlan br...@sweetapp.com 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
On Sat, Dec 11, 2010 at 6:07 AM, Brian Quinlan br...@sweetapp.com 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
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
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
On Sat, Dec 11, 2010 at 7:59 AM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 09 Dec 2010 16:18:14 -0800, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
ISTM it mostly could have been reduced to single call returning a nested
dictionary.
If what was returned was, as you
On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy tjre...@udel.edu 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
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
On Sat, Dec 11, 2010 at 10:41 AM, raymond.hettinger
python-check...@python.org 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:
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
50 matches
Mail list logo
