A curious bit of code...

[Ned Batchelder]

For the record I wasn't worried about the performance. ;-)

It was for Tkinter event strings not markup tags.

I'm glad this was the time winner!

"key and key[0] == '<' and key[-1] == '>'"


Cheers to the folks who did the timings (and saved me from the trouble!)

Last but not least... s[::len(s)-1] omg!!? ;-D

If you aren't worried about performance, why are you choosing your code
based on which is the fastest? There are other characteristics
(clarity, flexibility, robustness, ...) that could be more useful.

 

[Dave Angel]

I ran across this and I thought there must be a better way of doing it, but then after further consideration I wasn't so sure.

if key[:1] + key[-1:] == '<>': ...

if key[:1] == '<' and key[-1:] == '>: ...
is the obvious choice to me. If the first clause is false, it never
computes the second.

And therefore no need for the second colon.

if key[:1] == '<' and key[-1] == '>: ...

 

[Roy Smith]

I ran across this and I thought there must be a better way of doing it,
but then after further consideration I wasn't so sure.

if key[:1] + key[-1:] == '<>': ...

if key[:1] == '<' and key[-1:] == '>: ...
is the obvious choice to me. If the first clause is false, it never
computes the second.

And therefore no need for the second colon.

if key[:1] == '<' and key[-1] == '>: ...

I'd leave the second colon in. It makes the statement more uniform, and
therefor easier to understand.

 

[forman.simon]

For the record I wasn't worried about the performance. ;-)
It was for Tkinter event strings not markup tags.
I'm glad this was the time winner!
"key and key[0] == '<' and key[-1] == '>'"
Cheers to the folks who did the timings (and saved me from the trouble!)
Last but not least... s[::len(s)-1] omg!!? ;-D

If you aren't worried about performance, why are you choosing your code

based on which is the fastest? There are other characteristics

(clarity, flexibility, robustness, ...) that could be more useful.

I guess I'm taking the word "worried" a little too seriously.

Back story: I am hoping to contribute to IDLE and am reading the code as a first step. I came across that line of code (BTW, I was wrong: it is NOT processing Tkinter event strings but rather special "<pyshell#...> entries" in linecache.cache [1]) and had to resist the urge to change it to something more readable (to me.) But when I thought about it I wasn't able to discern if any of the new versions would actually be enough of an improvement to justify changing it.

To be clear: I have no intention of modifying the IDLE codebase just for fairly trivial points like this one line.

The most satisfying (to me) of the possibilities is "if key and key[0] == '<' and key[-1] == '>':" in the dimensions, if you will, of readability and, uh, unsurprising-ness, and so I was pleased to learn that that was also the fastest.


(FWIW, it seems to me that whoever wrote that line was influenced by shell programming. It's a shell sort of a trick to my eye.)


When writing Python code I *do* value "clarity, flexibility, robustness" and almost never worry about performance unless something is actually slow ina way that affects something..

Warm regards,
~Simon


[1] http://hg.python.org/cpython/file/3a1db0d2747e/Lib/idlelib/PyShell.py#l117

 

[Mark Lawrence]

For the record I wasn't worried about the performance. ;-)
It was for Tkinter event strings not markup tags.
I'm glad this was the time winner!
"key and key[0] == '<' and key[-1] == '>'"
Cheers to the folks who did the timings (and saved me from the trouble!)
Last but not least... s[::len(s)-1] omg!!? ;-D

If you aren't worried about performance, why are you choosing your code

based on which is the fastest? There are other characteristics

(clarity, flexibility, robustness, ...) that could be more useful.

I guess I'm taking the word "worried" a little too seriously.

Back story: I am hoping to contribute to IDLE and am reading the code as a first step. I came across that line of code (BTW, I was wrong: it is NOT processing Tkinter event strings but rather special "<pyshell#...> entries" in linecache.cache [1]) and had to resist the urge to change it to something more readable (to me.) But when I thought about it I wasn't able to discern if any of the new versions would actually be enough of an improvement to justify changing it.

To be clear: I have no intention of modifying the IDLE codebase just for fairly trivial points like this one line.

The most satisfying (to me) of the possibilities is "if key and key[0] == '<' and key[-1] == '>':" in the dimensions, if you will, of readability and, uh, unsurprising-ness, and so I was pleased to learn that that was also the fastest.


(FWIW, it seems to me that whoever wrote that line was influenced by shell programming. It's a shell sort of a trick to my eye.)


When writing Python code I *do* value "clarity, flexibility, robustness" and almost never worry about performance unless something is actually slow in a way that affects something..

Warm regards,
~Simon


[1] http://hg.python.org/cpython/file/3a1db0d2747e/Lib/idlelib/PyShell.py#l117

Pleased to have you on board, as I'm know that Terry Reedy et al can do
with a helping hand.

But please note you appear to be using google groups, hence the double
line spacing above and trying to reply to paragraphs that run as a
single line across the screen. Therefore would you please read and
action this https://wiki.python.org/moin/GoogleGroupsPython, thanks.