[Python-Dev] Removing anachronisms from logging module
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 back as it needs to go. Linux distros all come with 2.2 or newer these days. The logging module is currently listed in PEP 291 as requiring compatibility with 1.5.2; my proposal is to remove this or replace it with 2.2 (Vinay even proposed 2.4). (*) 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)"... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing anachronisms from logging module
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 usual way to write that under 1.5.2 is a lot faster (*). *) even faster than "startswith", in many cases. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing anachronisms from logging module
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 startswith wins -- but admittedly rather long, like 300 chracters.) --Guido On 8/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > 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 usual > way to write that under 1.5.2 is a lot faster (*). > > > > *) even faster than "startswith", in many cases. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing anachronisms from logging module
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... > 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. absolutely (see the py3k list for some related discussion). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
