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
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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
