Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #66200 > unrolled thread

A curious bit of code...

Started byforman.simon@gmail.com
First post2014-02-13 10:37 -0800
Last post2014-02-14 09:06 -0500
Articles 5 on this page of 45 — 16 participants

Back to article view | Back to comp.lang.python

Contents

  A curious bit of code... forman.simon@gmail.com - 2014-02-13 10:37 -0800
    Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-13 13:45 -0500
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 10:45 -0800
    Re: A curious bit of code... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-13 19:09 +0000
    Re: A curious bit of code... Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-02-13 20:05 +0100
    Re: A curious bit of code... Neil Cerutti <neilc@norwich.edu> - 2014-02-13 19:17 +0000
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 11:20 -0800
      Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-13 14:28 -0500
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 11:25 -0800
    Re: A curious bit of code... Neil Cerutti <neilc@norwich.edu> - 2014-02-13 19:25 +0000
    Re: A curious bit of code... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-13 19:32 +0000
    Re: A curious bit of code... Peter Otten <__peter__@web.de> - 2014-02-13 20:43 +0100
      Re: A curious bit of code... Marko Rauhamaa <marko@pacujo.net> - 2014-02-13 21:56 +0200
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 11:23 -0800
    Re: A curious bit of code... Neil Cerutti <neilc@norwich.edu> - 2014-02-13 19:51 +0000
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 11:59 -0800
    Re: A curious bit of code... Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-13 13:59 -0600
    Re: A curious bit of code... Chris Angelico <rosuav@gmail.com> - 2014-02-14 07:29 +1100
    Re: A curious bit of code... Tim Chase <python.list@tim.thechases.com> - 2014-02-13 14:39 -0600
    Re: A curious bit of code... Emile van Sebille <emile@fenx.com> - 2014-02-13 12:55 -0800
      Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-13 16:24 -0500
        Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 16:23 -0800
    Re: A curious bit of code... Chris Angelico <rosuav@gmail.com> - 2014-02-14 08:01 +1100
    Re: A curious bit of code... Neil Cerutti <neilc@norwich.edu> - 2014-02-13 21:01 +0000
    Re: A curious bit of code... Peter Otten <__peter__@web.de> - 2014-02-13 22:06 +0100
    Re: A curious bit of code... Chris Angelico <rosuav@gmail.com> - 2014-02-14 08:10 +1100
    Re: A curious bit of code... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-13 21:14 +0000
    Re: A curious bit of code... Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-13 15:20 -0600
    Re: A curious bit of code... Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-13 15:19 -0600
    Re: A curious bit of code... Emile van Sebille <emile@fenx.com> - 2014-02-13 13:23 -0800
    Re: A curious bit of code... Chris Angelico <rosuav@gmail.com> - 2014-02-14 08:31 +1100
      Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-13 16:38 -0500
    Re: A curious bit of code... Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-13 15:47 -0600
    Re: A curious bit of code... Serhiy Storchaka <storchaka@gmail.com> - 2014-02-13 23:49 +0200
      Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-13 16:51 -0500
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 13:33 -0800
    Re: A curious bit of code... Chris Angelico <rosuav@gmail.com> - 2014-02-14 09:13 +1100
    Re: A curious bit of code... Ethan Furman <ethan@stoneleaf.us> - 2014-02-13 14:26 -0800
    Re: A curious bit of code... Terry Reedy <tjreedy@udel.edu> - 2014-02-13 19:29 -0500
    Re: A curious bit of code... forman.simon@gmail.com - 2014-02-13 18:45 -0800
      Re: A curious bit of code... Ned Batchelder <ned@nedbatchelder.com> - 2014-02-13 22:26 -0500
        Re: A curious bit of code... forman.simon@gmail.com - 2014-02-14 12:04 -0800
          Re: A curious bit of code... Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-02-14 21:01 +0000
    Re: A curious bit of code... Dave Angel <davea@davea.name> - 2014-02-14 07:19 -0500
      Re: A curious bit of code... Roy Smith <roy@panix.com> - 2014-02-14 09:06 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#66278

FromNed Batchelder <ned@nedbatchelder.com>
Date2014-02-13 22:26 -0500
Message-ID<mailman.6906.1392348429.18130.python-list@python.org>
In reply to#66275
On 2/13/14 9:45 PM, forman.simon@gmail.com wrote:
> 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.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#66320

Fromforman.simon@gmail.com
Date2014-02-14 12:04 -0800
Message-ID<6940c818-e8dc-483e-8795-9e5493050e3b@googlegroups.com>
In reply to#66278
On Thursday, February 13, 2014 7:26:48 PM UTC-8, Ned Batchelder wrote:
> On 2/13/14 9:45 PM, forman.simon@gmail.com wrote:
> 
> > 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

[toc] | [prev] | [next] | [standalone]

#66327

FromMark Lawrence <breamoreboy@yahoo.co.uk>
Date2014-02-14 21:01 +0000
Message-ID<mailman.6936.1392411730.18130.python-list@python.org>
In reply to#66320
On 14/02/2014 20:04, forman.simon@gmail.com wrote:
> On Thursday, February 13, 2014 7:26:48 PM UTC-8, Ned Batchelder wrote:
>> On 2/13/14 9:45 PM, forman.simon@gmail.com wrote:
>>
>>> 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.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#66293

FromDave Angel <davea@davea.name>
Date2014-02-14 07:19 -0500
Message-ID<mailman.6914.1392380171.18130.python-list@python.org>
In reply to#66200
 Terry Reedy <tjreedy@udel.edu> Wrote in message:
> On 2/13/2014 1:37 PM, forman.simon@gmail.com wrote:
>> 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] == '>: ...



-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#66296

FromRoy Smith <roy@panix.com>
Date2014-02-14 09:06 -0500
Message-ID<roy-A0B90C.09064814022014@news.panix.com>
In reply to#66293
In article <mailman.6914.1392380171.18130.python-list@python.org>,
 Dave Angel <davea@davea.name> wrote:

>  Terry Reedy <tjreedy@udel.edu> Wrote in message:
> > On 2/13/2014 1:37 PM, forman.simon@gmail.com wrote:
> >> 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.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web