Re: [Python-Dev] Removing anachronisms from logging module

2006-08-26 Thread A.M. Kuchling
On Fri, Aug 25, 2006 at 10:44:53AM -0700, Guido van Rossum wrote: > any more; neither does Vinay. I propose as a project for someone to > clean it up ... There's a list of simple tasks in the wiki at . --amk ___ P

Re: [Python-Dev] Removing anachronisms from logging module

2006-08-25 Thread Fredrik Lundh
Guido van Rossum wrote: > I prefer to focus on "clearer" and "less error-prone" rather than > "faster" in most cases. well, given that "startwith" is by far the most common typo I make when writing Python programs these days, I'm not so sure about that error-proneness thing, but never mind... >

Re: [Python-Dev] Removing anachronisms from logging module

2006-08-25 Thread Guido van Rossum
I prefer to focus on "clearer" and "less error-prone" rather than "faster" in most cases. I do agree it's a minor embarrassment that s.startswith(t) is slower than s[:len(t)]==t; but I think we should make startswith() faster rather than recommending the other idiom. (Also, for longer substrings

Re: [Python-Dev] Removing anachronisms from logging module

2006-08-25 Thread Fredrik Lundh
Guido van Rossum wrote: > (*) I found an example of code testing "if string.find(s, t) != 0", > thinking it was a bug attempting to write "if t in s", but which Vinay > identified as a 1.5.2 idiom for "if not s.startswith(t)"... and as noted on the py3k list, not a very good one, given that the u

[Python-Dev] Removing anachronisms from logging module

2006-08-25 Thread Guido van Rossum
The logging module currently contains some weird-looking code that is there to maintain 1.5.2 compatibility (*). I don't think that's needed any more; neither does Vinay. I propose as a project for someone to clean it up; perhaps compatibility could be maintained with 2.2 but that's probably as far