[ python-Feature Requests-1474577 ] feature requests for logging lib
Feature Requests item #1474577, was opened at 2006-04-22 09:50
Message generated for change (Comment added) made by vsajip
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: Vinay Sajip (vsajip)
Date: 2006-05-02 09:11
Message:
Logged In: YES
user_id=308438
Why does the recent introduction of the 'extra' keyword
argument, mean
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 17:46 Message generated for change (Comment added) made by markshep You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- >Comment By: Mark Sheppard (markshep) Date: 2006-05-02 11:48 Message: Logged In: YES user_id=1512331 I'm running Windows XP. I've been unable to find any documentation about this exact problem - only that fwrite thing. But my testing shows that it works if I do file.read(67076095), but throws an exception with file.read(67076096). I'm not suggesting limiting all reads from Python. All I'm suggesting is that under the hood the Windows implementation of Python's read() call actually uses multiple fread() (or whatever) calls if more than 67076095 bytes need to be read. That's all. No interface changes. -- Comment By: Tim Peters (tim_one) Date: 2006-04-30 17:23 Message: Logged In: YES user_id=31435 Martin, here's an MS article seemingly related to this: http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 However, it's about writing to a file on a network drive, not reading from it. It says that opening the file in 'w+b' mode, instead of 'wb' mode, is a workaround. I couldn't find anything documenting the same kind of problem for reading. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-30 11:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 14:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1478529 ] size limit exceeded for read() from network drive
Bugs item #1478529, was opened at 2006-04-28 18:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sheppard (markshep) Assigned to: Nobody/Anonymous (nobody) Summary: size limit exceeded for read() from network drive Initial Comment: If you've got a network share mounted as a local drive then Windows has a limit of 67,076,095 (0x03ff7fff) bytes for a read from an open file on that drive. Running the python read() method on an open file larger than this size throws an "IOError: [Errno 22] Invalid argument" exception. A fix would be for python to internally use multiple reads so as to not exceed this limit. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-05-02 21:00 Message: Logged In: YES user_id=21627 I could reproduce the write problem on XPSP2; I get the Win32 error ERROR_NO_SYSTEM_RESOURCES after fwrite returns (from GetLastError). I can't reproduce the fread problem, though: in Python, f.read(90*2**20) just returns with a 90MiB string. So it could be a limitation of your machine (e.g. it might not have enough memory), or of the server machine. I'm hesitant to add a work-around for that into Python if this isn't a system limitation. Performing multiple reads is also bad: what happens if the first read succeeds, and the second one fails? It might be that the system *really* is out of resources. -- Comment By: Mark Sheppard (markshep) Date: 2006-05-02 12:48 Message: Logged In: YES user_id=1512331 I'm running Windows XP. I've been unable to find any documentation about this exact problem - only that fwrite thing. But my testing shows that it works if I do file.read(67076095), but throws an exception with file.read(67076096). I'm not suggesting limiting all reads from Python. All I'm suggesting is that under the hood the Windows implementation of Python's read() call actually uses multiple fread() (or whatever) calls if more than 67076095 bytes need to be read. That's all. No interface changes. -- Comment By: Tim Peters (tim_one) Date: 2006-04-30 18:23 Message: Logged In: YES user_id=31435 Martin, here's an MS article seemingly related to this: http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 However, it's about writing to a file on a network drive, not reading from it. It says that opening the file in 'w+b' mode, instead of 'wb' mode, is a workaround. I couldn't find anything documenting the same kind of problem for reading. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-30 12:10 Message: Logged In: YES user_id=21627 What version of Windows are you using? Do you know of any documentation of this limit? (without actually testing, I find it hard to believe that this limit exists in Windows) -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-29 15:23 Message: Logged In: YES user_id=849994 How can it be determined whether exactly this restriction caused the "invalid argument" error? If it can't, there's nothing that can be done -- restricting all reads just because of a Windows limitation doesn't seem right. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1478529&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1051840 ] HTMLParser doesn't treat endtags in
Bugs item #1051840, was opened at 2004-10-21 19:02 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1051840&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: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Luke Bradley (neptune235) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser doesn't treat endtags in tags as CDATA Initial Comment: HTMLParser.HTMLParser in Python 2.3.4 calls self.handle_endtag() for end tags within script and style sections, which it should not, because the content is supposed to be CDATA, as defined in CDATA_CONTENT_ELEMENTS within HTMLParser. The following script will demonstrate this problem: import HTMLParser class MyHandler(HTMLParser.HTMLParser): tags = [] def handle_starttag(self, tag, attr): self.tags.append(tag) def handle_endtag(self, tag): if tag != self.tags[-1]: #this should never happen in a well formed document raise "Not well-formed, endtag '" + tag + "' doesn't match starttag '" + self.lasttag + "'" self.tags.pop(-1) s = """ This page is completely well formed