[ python-Feature Requests-1474577 ] feature requests for logging lib
Feature Requests item #1474577, was opened at 2006-04-22 19:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Nobody/Anonymous (nobody)
Summary: feature requests for logging lib
Initial Comment:
The logger module interface is a bit broken, I reckon.
My problems specifically are:
i) It's hard to get access to the LogRecord classes
for customization.
ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...
Here are my proposed fixes:
a) Add a method
Logger.setLogRecordClass( myLogRecordSubClass )
which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).
This would make customizing the LogRecord easier...
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well? This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html
Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..
b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken. Currently the
defn looks like this:
def debug(self, msg, *args, **kwargs):
this suggests to me that a call like this is OK...
logger.debug("here we go %(foo)s", foo = 'bar')
but it's not. This is discussed further here...
http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881
Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra). This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood). Instead I propose using a
couple of calls along the lines of printf/fprintf. In
my world we'd have a simple printf-style function...
def debug(self, msg, *args):
and a more complex, more easily customizable
fprintf-style one
def x_debug(self, log_record, msg, *args):
In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary. Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).
(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)
c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...
Currently you can set up log filters. What you can
filter is largely based on what information appears in
the log record. It'd be nice to filter messages based
on metadata that you add at log time (i.e. in the
logger.debug(...) method). Currently it's quite
painfull to set this up. This is because we can't
customize the initialization of the log_record. The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..
class GUIFilter:
"A filter that only lets messges with gui tags
through."""
def filter(self, log_record):
return hasattr(log_record, 'gui')
# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())
# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")
# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")
Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones (though what you'd call the new fns I
don't know).
That said I quite like the logger lib and I use it.
It's a lot better than anything I would have thought up.
cheers
blaize
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470
___
[ python-Feature Requests-1474577 ] feature requests for logging lib
Feature Requests item #1474577, was opened at 2006-04-22 19:50
Message generated for change (Comment added) made by blaize
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Nobody/Anonymous (nobody)
Summary: feature requests for logging lib
Initial Comment:
The logger module interface is a bit broken, I reckon.
My problems specifically are:
i) It's hard to get access to the LogRecord classes
for customization.
ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...
Here are my proposed fixes:
a) Add a method
Logger.setLogRecordClass( myLogRecordSubClass )
which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).
This would make customizing the LogRecord easier...
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well? This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html
Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..
b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken. Currently the
defn looks like this:
def debug(self, msg, *args, **kwargs):
this suggests to me that a call like this is OK...
logger.debug("here we go %(foo)s", foo = 'bar')
but it's not. This is discussed further here...
http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881
Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra). This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood). Instead I propose using a
couple of calls along the lines of printf/fprintf. In
my world we'd have a simple printf-style function...
def debug(self, msg, *args):
and a more complex, more easily customizable
fprintf-style one
def x_debug(self, log_record, msg, *args):
In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary. Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).
(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)
c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...
Currently you can set up log filters. What you can
filter is largely based on what information appears in
the log record. It'd be nice to filter messages based
on metadata that you add at log time (i.e. in the
logger.debug(...) method). Currently it's quite
painfull to set this up. This is because we can't
customize the initialization of the log_record. The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..
class GUIFilter:
"A filter that only lets messges with gui tags
through."""
def filter(self, log_record):
return hasattr(log_record, 'gui')
# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())
# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")
# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")
Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones (though what you'd call the new fns I
don't know).
That said I quite like the logger lib and I use it.
It's a lot better than anything I would have thought up.
cheers
blaize
--
>Comment By: blaize rhodes (blaize)
Date: 2006-04-22 19:56
Message:
Logged In: YES
user_id=264689
For readability put an "if __name__ == '__main__':" above the
#
[ python-Feature Requests-1474609 ] feature requests for logging lib
Feature Requests item #1474609, was opened at 2006-04-22 22:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474609&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: blaize rhodes (blaize)
Assigned to: Nobody/Anonymous (nobody)
Summary: feature requests for logging lib
Initial Comment:
The logger module interface is a bit broken, I reckon.
My problems specifically are:
i) It's hard to get access to the LogRecord classes
for customization.
ii) the semantics of the debug, log, info, etc calls
is a bit strange/confusing...
Here are my proposed fixes:
a) Add a method
Logger.setLogRecordClass( myLogRecordSubClass )
which sets the class that is instantiated in the
makeRecord() fn/method (yes there are two of them).
This would make customizing the LogRecord easier...
Otherwise (I believe) in order to subclass the
LogRecord you also have to overload the Logger and
possibly the root makeRecord() function as well? This
bloke's writen up his approach to this (it's doable but
not as nice as it should be).
http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html
Another problem is that LogRecords are instantiated in
Logger._log so it's difficult to customize __init__
behaviour for the LogRecord (and I argue that this is a
useful thing)..
b) A second problem is that the semantics of the log,
info, debug, etc fns is a bit broken. Currently the
defn looks like this:
def debug(self, msg, *args, **kwargs):
this suggests to me that a call like this is OK...
logger.debug("here we go %(foo)s", foo = 'bar')
but it's not. This is discussed further here...
http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881
Instead kwargs are used for customizing the behaviour
of the debug method (e.g. exc_info, and extra). This
seems i) a bit incongrous with its definition and
therefore confusing, and ii) a bit of a hack (it's not
completely insane though when you think about what's
happening under the hood). Instead I propose using a
couple of calls along the lines of printf/fprintf. In
my world we'd have a simple printf-style function...
def debug(self, msg, *args):
and a more complex, more easily customizable
fprintf-style one
def x_debug(self, log_record, msg, *args):
In these calls *args is a valid argument for the string
formatting operator %, either a tuple of the right
length or a dictionary. Any customization of the
behaviour of the system can be done (using keyword args
if you wish) in the log_record initializer (an example
will follow).
(Having said that perhaps we can check whether the
first arg to the new simple debug() is a logrecord and
if it is call the (hidden) extended version - that's
more pythonic I imagine)
c) This is not so much a feature request but a
motivating mode of operation that I'd like to be able
to use...
Currently you can set up log filters. What you can
filter is largely based on what information appears in
the log record. It'd be nice to filter messages based
on metadata that you add at log time (i.e. in the
logger.debug(...) method). Currently it's quite
painfull to set this up. This is because we can't
customize the initialization of the log_record. The
call structure in ii) above allows us to setup nice
filtering mechanisms
eg..
class GUIFilter:
"A filter that only lets messges with gui tags
through."""
def filter(self, log_record):
return hasattr(log_record, 'gui')
# set up a log, and a handler...
log = logging.getLogger(..)
file_handler = FileHandler(..)
log.addHandler(file_handler)
gui_msg_bar_handler = StreamHandler(..)
log.addHandler(gui_msg_bar_handler)
gui_msg_bar_handler.addFilter(GUIFilter())
# msg only goes to the file_handler
log.debug("here we go %s", "here's an arg")
# msg goes to the file_handler and to the gui_handler.
log.x_debug(LogRecord(gui=True), "what you just tried
to do didn't work %s", "fool")
Change a) could be made with no backward compatability
problems (I can see), change b) could be made without
probs if you didn't overload the existing logging
methods with the new ones, and then deprecate the
existing ones (though what you'd call the new fns I
don't know).
That said I quite like the logger lib and I use it.
It's a lot better than anything I would have thought up.
cheers
blaize
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474609&group_id=5470
___
[ python-Bugs-1472566 ] import module with .dll extension
Bugs item #1472566, was opened at 2006-04-18 22:06
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: svenn (sven_nystrom)
Assigned to: Martin v. Löwis (loewis)
Summary: import module with .dll extension
Initial Comment:
In previous versions, extension modules with the file
extension '.dll' could be imported using a
single 'import' statement.
In 2.5a1 this seems to have changed - here's an
example:
>>> import minx # Implemented in a .dll - fails
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named minx
>>> import imp# Workaround
>>> import os
>>> minx = imp.load_dynamic('minx', os.getcwd()
+ '\\minx.dll')
I would really like this to remain the same; if that's
not possible, it would be helpful if the change itself
and a suggested approach were to be included in the
documentation.
/Sven
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-22 16:26
Message:
Logged In: YES
user_id=21627
Tim mentions the rationale for the change; the Misc/NEWS
entry is now in r45574.
svenn, why do you need it to work that way? Could you change
your code/application/whatever so that it works with .pyd
files instead?
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-19 19:16
Message:
Logged In: YES
user_id=31435
Note that rev 43622 added a comment to dynload_win.c
explaining why it was done:
"""
/* Temporarily disable .dll, to avoid conflicts between
sqlite3.dll and the sqlite3 package. If this needs to
be reverted for 2.5, some other solution for the
naming conflict must be found.
"""
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 09:13
Message:
Logged In: YES
user_id=33168
I believe this was an intentional change in rev 43622. I
don't see any doc associated with the change however. I
also thought it was mentioned on python-dev. Martin,
shouldn't this be documented at least in Misc/NEWS? I
couldn't find anything.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1474677 ] non-keyword argument following keyword
Bugs item #1474677, was opened at 2006-04-23 01:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: non-keyword argument following keyword Initial Comment: def foo(a,b=None):pass foo(b=1,2) With Python 2.5(compiled as of 2006-04-23), this code runs without any error. In older Python(although I didn't check every version of it), I get File "foo.py", line 2 foo(b=1,2) SyntaxError: non-keyword arg after keyword arg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474677&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1474680 ] pickling files works with protocol=2.
Bugs item #1474680, was opened at 2006-04-22 19:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474680&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickling files works with protocol=2.
Initial Comment:
Compare:
>>> import pickle
>>> pickle.dumps(file('/etc/passwd'))
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/pickle.py", line 1386, in dumps
Pickler(file, protocol, bin).dump(obj)
File "/usr/lib/python2.4/pickle.py", line 231, in dump
self.save(obj)
File "/usr/lib/python2.4/pickle.py", line 313, in save
rv = reduce(self.proto)
File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle file objects
with
>>> pickle.dumps(file('/etc/passwd'), protocol=2)
'\x80\x02c__builtin__\nfile\nq\x00)\x81q\x01.'
Similarly, the __reduce__ method works for basic
objects like str, int or dict with protocol=2, but
doesn't work with protocol=1:
>>> (1).__reduce_ex__(1)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/copy_reg.py", line 69, in
_reduce_ex
raise TypeError, "can't pickle %s objects" %
base.__name__
TypeError: can't pickle int objects
>>> (1).__reduce_ex__(2)
(, (,
1), None, None, None)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1474680&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472566 ] import module with .dll extension
Bugs item #1472566, was opened at 2006-04-18 22:06
Message generated for change (Comment added) made by sven_nystrom
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: svenn (sven_nystrom)
Assigned to: Martin v. Löwis (loewis)
Summary: import module with .dll extension
Initial Comment:
In previous versions, extension modules with the file
extension '.dll' could be imported using a
single 'import' statement.
In 2.5a1 this seems to have changed - here's an
example:
>>> import minx # Implemented in a .dll - fails
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named minx
>>> import imp# Workaround
>>> import os
>>> minx = imp.load_dynamic('minx', os.getcwd()
+ '\\minx.dll')
I would really like this to remain the same; if that's
not possible, it would be helpful if the change itself
and a suggested approach were to be included in the
documentation.
/Sven
--
>Comment By: svenn (sven_nystrom)
Date: 2006-04-22 18:25
Message:
Logged In: YES
user_id=1504966
Hi loewis,
I', sure the .pyd extension will work fine - my original
comment was due to the fact I didn't realise it would work
as today if the file extension was changed; I was (wrongly)
assuming I would have to use the approach indicated in my
example, which seemed a little less intuitive than the
simple "import".
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-22 16:26
Message:
Logged In: YES
user_id=21627
Tim mentions the rationale for the change; the Misc/NEWS
entry is now in r45574.
svenn, why do you need it to work that way? Could you change
your code/application/whatever so that it works with .pyd
files instead?
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-19 19:16
Message:
Logged In: YES
user_id=31435
Note that rev 43622 added a comment to dynload_win.c
explaining why it was done:
"""
/* Temporarily disable .dll, to avoid conflicts between
sqlite3.dll and the sqlite3 package. If this needs to
be reverted for 2.5, some other solution for the
naming conflict must be found.
"""
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 09:13
Message:
Logged In: YES
user_id=33168
I believe this was an intentional change in rev 43622. I
don't see any doc associated with the change however. I
also thought it was mentioned on python-dev. Martin,
shouldn't this be documented at least in Misc/NEWS? I
couldn't find anything.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472566&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
