[issue9512] logging.handlers.RotatingFileHandler - mode argument not respected
Friðrik Már Jónsson frid...@pyth.net added the comment: That's a fair conclusion, but in this case I'd appreciate Terry's suggested doc patch being implemented: DOC PATCH In 15.6.12.5. RotatingFileHandler, replace If mode is not specified, 'a' is used. with If mode is not specified or if maxBytes 0, the mode is 'a'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9512] logging.handlers.RotatingFileHandler - mode argument not respected
Friðrik Már Jónsson frid...@pyth.net added the comment: I agree with your points on the triviality and potential harmfulness of allowing modes like 'b' and 'w'. The '+' mode may be required for loggers that require headers or validation or positioning within an existing file (think XML). One example of such a format is the Extended Log File Format draft by the W3C which has seen widespread usage, despite being a draft. With a format like the ELFF, it must be determined on opening an existing file (perhaps amongst other sanitary operations), whether its headers have already been written or whether they need to be. It may also be desirable to simply check the file's size through its already open handler. I can see an argument for not allowing this into the handler; handlers are perhaps not meant to support formats but much rather storage mechanisms. Accepting this argument requires accepting the fact that libraries implementing such formats, using rotation and needing to read will need to write a handler from scratch for rotation support. There may be more uses of different modes than my single example. I see this boiling down to a matter of philosophy -- do we support usages we cannot foresee or do we admit certain features only when we've seen several valid examples of their use? Perhaps we should also consider what harm is possibly done by allowing these modes, and whether harmful use is likelier to be attributed to bad architecture or programmer recklessness. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9512] logging.handlers.RotatingFileHandler - mode argument not respected
Friðrik Már Jónsson frid...@pyth.net added the comment: Thank you. I should have been more clear about what I meant. This this condition was introduced in r38631 by Vinay Sajip having the log message Added optional encoding argument to file handlers. I can't easily see why this piece of code is necessary, which absolutely doesn't mean it isn't. I'm going to suggest some cases where other modes may be appropriate for loggers. This is a little open-ended and devoid of solution-orientation, but I don't know the rationale well enough to suggest alternatives. We do know that 'r' (read-only logger) and 'w' (logger rarely rolls over for traditional maxBytes values, but might -- this mode also makes relatively little sense with ``logger.FileHandler``) make little sense here. I'm not aware of a binary log format, so 'b' might make little sense as well. What about 'U' and '+'? For instance, the W3C Extended Log File Format draft uses headers at the beginning of a log file. Ideally, knowing whether to write headers to the file is done by using the ``handler.stream`` to determine whether the file is empty. It may be debatable whether supporting such formats is the purpose of handlers. If not, it's at the cost of writing new libraries that handle logging for those formats. I will never be able to exhaustively list use cases. If these modes are safe, shouldn't the developer decide makes sense, as long as it doesn't break the functionality of the logger? I don't know whether it's generally approrpiate to add people to the nosy list. I apologise, Vinay, if that's not common practice. -- nosy: +vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9512] logging.handlers.RotatingFileHandler - mode argument not respected
Friðrik Már Jónsson frid...@pyth.net added the comment: It may not have been entirely obvious that what I meant with the Extended Log File Format example is that read access would be optimal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9512] logging.handlers.RotatingFileHandler - mode argument not respected
New submission from Friðrik Már Jónsson frid...@pyth.net:
It seems to me that the ``mode`` keyword argument of
``logging.handlers.RotatingFileHandler`` is not respected.
Here is an example of opening a nonexistent file::
Python 2.7 (r27:82500, Aug 4 2010, 15:10:49)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import logging.handlers
handler = logging.handlers.RotatingFileHandler('nonexistent.log',
... mode='a+', maxBytes=1000, backupCount=2)
handler.mode
'a'
handler.stream
open file '/home/fridrik/nonexistent.log', mode 'a' at 0x2aefbca796f0
The docs do not mention any deviations from the behavior I expected
(``handler.stream`` having the mode specified as an argument to
``RotatingFileHandler``); only that If mode is not specified, 'a' is used.
I've confirmed the same behavior on 2.5.2 and 2.6.2. This happens regardless
of whether the file is being created or already exists.
--
components: Library (Lib)
messages: 112821
nosy: fridrik
priority: normal
severity: normal
status: open
title: logging.handlers.RotatingFileHandler - mode argument not respected
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9512
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: gett error message: TypeError: 'int' object is not callable
Look at: len = len(text) You're overriding `len` (a built-in method), with an integer (`len(text)`). You then call: for i in range(len(fields)): But `len` is no longer a callable, but merely an integer. Regards, Friðrik Már P.S. While this is a fairly obvious problem it's usually a good idea to post working code and a traceback when requesting help. -- http://mail.python.org/mailman/listinfo/python-list
Re: gett error message: TypeError: 'int' object is not callable
Previously, I wrote: P.S. While this is a fairly obvious problem it's usually a good idea to post working code and a traceback when requesting help. Nick wrote: thanks for spotting the obvious errors, its my 2nd day programming python in about 3 years. I'm sorry, my saying it was obvious may have come off a little arrogant. My clumsily delivered point was that because it was a small snippet of code it didn't take much time to run through for someone who codes daily with Python. What you did there was a perfectly ordinary thing to do until experience teaches you how Python does things. :) fridrick, code should be workable with the exception of the errors...thats the whole program You're right, I failed to say it explicitely but I was referring to the input file. In some cases, albeit not this one, problems can exist in parsing gotchas. Regards, Friðrik Már -- http://mail.python.org/mailman/listinfo/python-list
Re: gett error message: TypeError: 'int' object is not callable
Tom Kermode wrote: Do you know a good way to avoid running into this problem? It makes sense to suggest not calling variables the same names as built-in functions, but that's hard for a new python programmer who doesn't already know what all the built-in functions are. One way is using a code checker like PyChecker[1]. This neat software for finding bugs will check for lots of other pitfalls too, but you can filter it down to what you need if you're only interested in this one. I don't use an IDE, but this would seem like something for an IDE[2] to support if you're into that kind of magic. Regards, Friðrik Már [1] http://pychecker.sourceforge.net/ [2] http://wiki.python.org/moin/IntegratedDevelopmentEnvironments -- http://mail.python.org/mailman/listinfo/python-list
Re: gett error message: TypeError: 'int' object is not callable
Hi Rhodri, It's only really a pitfall if you try to use the built-in after you've redefined it. That's the thing to keep an eye open for. You're right, but in cases where you're editing a codebase which you didn't author entirely by yourself you may not be aware of that. That said, if the codebase you're working on is structured (short, concise methods) you should be working with small, consumable scopes you can inhale in entirety before modifying. Regards, Friðrik Már -- http://mail.python.org/mailman/listinfo/python-list
Re: AP -- MeAmI.org Paces Google
I'll be the first to admit it. The point of writing a fake story by Associated Press and publishing it on a programming mailing list is totally beyond me. Confoundedly yours, Friðrik Már -- http://mail.python.org/mailman/listinfo/python-list
Re: [0, 0, 0, 1, 1, 1, 0] ... remove all 0 values
ma wrote: filter(lambda x: x, your_list) Good call! Equivalent but more efficient: filter(None, your_list) Regards, Friðrik Már -- http://mail.python.org/mailman/listinfo/python-list
Re: [0, 0, 0, 1, 1, 1, 0] ... remove all 0 values
J Kenneth King wrote: I was wondering when someone would mention filter() I was happy to see that too. It's clean, faster than list comprehension and in terms of clarity it's only to be expected that the developer is familiar with, or at least willing to look up, the available built-in methods. Regards, Friðrik Már -- http://mail.python.org/mailman/listinfo/python-list
