Re: A curious bit of code...
Terry Reedy tjre...@udel.edu Wrote in message: On 2/13/2014 1:37 PM, forman.si...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article mailman.6914.1392380171.18130.python-l...@python.org, Dave Angel da...@davea.name wrote: Terry Reedy tjre...@udel.edu Wrote in message: On 2/13/2014 1:37 PM, forman.si...@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. -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Thursday, February 13, 2014 7:26:48 PM UTC-8, Ned Batchelder wrote: On 2/13/14 9:45 PM, forman.si...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 14/02/2014 20:04, forman.si...@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.si...@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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Friday, February 14, 2014 1:01:48 PM UTC-8, Mark Lawrence wrote: [snip] 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. Ah! Thanks for the tip. ;-) (Just last night I was trying to explain to a friend about Usenet and how it's not Google Groups.) I really hope I can be of use with IDLE. I've been using it for years now. :) Warm regards, ~Simon -- http://phoenixbureau.org/ http://phoenixbureau.org/blog.html http://twitter.com/SimonForman The history of mankind for the last four centuries is rather like that of an imprisoned sleeper, stirring clumsily and uneasily while the prison that restrains and shelters him catches fire, not waking but incorporating the crackling and warmth of the fire with ancient and incongruous dreams, than like that of a man consciously awake to danger and opportunity. --H. P. Wells, A Short History of the World -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article 4cc09129-43ee-4205-a24c-03f92b594...@googlegroups.com,
forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
if re.match(r'^.*$', key):
sheesh.
(if you care how fast it is, pre-compile the pattern)
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 10:37 AM, forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like the original
might be the fastest after all?
Unless that line of code is a bottleneck, don't worry about speed, go for readability. In which case I'd go with the
second option, then the first, and definitely avoid the third.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 13/02/2014 18:37, forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like the original
might be the fastest after all?
All I can say is that if you're worried about the speed of a single line
of code like the above then you've got problems. Having said that, I
suspect that using an index to extract a single character has to be
faster than using a slice, but I haven't run these through a profiler yet :)
--
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 11:09 AM, Mark Lawrence wrote: All I can say is that if you're worried about the speed of a single line of code like the above then you've got problems. Having said that, I suspect that using an index to extract a single character has to be faster than using a slice, but I haven't run these through a profiler yet :) The problem with using indices in the code sample is that if the string is 0 or 1 characters long you'll get an exception instead of a False. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
forman.si...@gmail.com writes:
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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I would do: if key[0] == '' and key[-1] == '' ...
-- Alain.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 11:20 AM, Ethan Furman wrote: On 02/13/2014 11:09 AM, Mark Lawrence wrote: All I can say is that if you're worried about the speed of a single line of code like the above then you've got problems. Having said that, I suspect that using an index to extract a single character has to be faster than using a slice, but I haven't run these through a profiler yet :) The problem with using indices in the code sample is that if the string is 0 or 1 characters long you'll get an exception instead of a False. Oops, make that zero characters. ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2014-02-13, Ethan Furman et...@stoneleaf.us wrote: On 02/13/2014 11:09 AM, Mark Lawrence wrote: All I can say is that if you're worried about the speed of a single line of code like the above then you've got problems. Having said that, I suspect that using an index to extract a single character has to be faster than using a slice, but I haven't run these through a profiler yet :) The problem with using indices in the code sample is that if the string is 0 or 1 characters long you'll get an exception instead of a False. There will be an exception only if it is zero-length. But good point! That's a pretty sneaky way to avoid checking for a zero-length string. Is it a popular idiom? -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2014-02-13, forman.si...@gmail.com forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like
the original might be the fastest after all?
I think the following would occur to someone first:
if key[0] == '' and key[-1] == '':
...
It is wrong to avoid the obvious. Needlessly ornate or clever
code will only irritate the person who has to read it later; most
likely yourself.
--
Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 13/02/2014 19:25, Neil Cerutti wrote: On 2014-02-13, Ethan Furman et...@stoneleaf.us wrote: On 02/13/2014 11:09 AM, Mark Lawrence wrote: All I can say is that if you're worried about the speed of a single line of code like the above then you've got problems. Having said that, I suspect that using an index to extract a single character has to be faster than using a slice, but I haven't run these through a profiler yet :) The problem with using indices in the code sample is that if the string is 0 or 1 characters long you'll get an exception instead of a False. There will be an exception only if it is zero-length. But good point! That's a pretty sneaky way to avoid checking for a zero-length string. Is it a popular idiom? I hope not. -- 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article mailman.6859.1392319225.18130.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: On 02/13/2014 11:09 AM, Mark Lawrence wrote: All I can say is that if you're worried about the speed of a single line of code like the above then you've got problems. Having said that, I suspect that using an index to extract a single character has to be faster than using a slice, but I haven't run these through a profiler yet :) The problem with using indices in the code sample is that if the string is 0 or 1 characters long you'll get an exception instead of a False. My re.match() solution handles those edge cases just fine. -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like the original
might be the fastest after all?
$ python -m timeit -s 's = alpha' 's[:1]+s[-1:] == '
100 loops, best of 3: 0.37 usec per loop
$ python -m timeit -s 's = alpha' 's[:1] == and s[-1:] == '
100 loops, best of 3: 0.329 usec per loop
$ python -m timeit -s 's = alpha' 's.startswith() and
s.endswith()'
100 loops, best of 3: 0.713 usec per loop
The first is too clever for my taste.
The second is fast and easy to understand. It might attract improvements
replacing the slice with an index, but I trust you will catch that with your
unit tests ;)
Personally, I'm willing to spend the few extra milliseconds and use the
foolproof third.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 11:17 AM, Neil Cerutti wrote:
On 2014-02-13, forman.si...@gmail.com forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like
the original might be the fastest after all?
I think the following would occur to someone first:
if key[0] == '' and key[-1] == '':
...
It is wrong to avoid the obvious. Needlessly ornate or clever
code will only irritate the person who has to read it later; most
likely yourself.
Not whet the obvious is wrong:
- key = ''
-- if key[0] == '' and key[-1] == '':
... print good key!
... else:
... print bad key
...
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: string index out of range
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2014-02-13, Peter Otten __pete...@web.de wrote: forman.si...@gmail.com wrote: The first is too clever for my taste. The second is fast and easy to understand. It might attract improvements replacing the slice with an index, but I trust you will catch that with your unit tests ;) It's easy to forget exactly why startswith and endswith even exist. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 11:43 AM, Peter Otten wrote:
forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like the original
might be the fastest after all?
$ python -m timeit -s 's = alpha' 's[:1]+s[-1:] == '
100 loops, best of 3: 0.37 usec per loop
$ python -m timeit -s 's = alpha' 's[:1] == and s[-1:] == '
100 loops, best of 3: 0.329 usec per loop
$ python -m timeit -s 's = alpha' 's.startswith() and
s.endswith()'
100 loops, best of 3: 0.713 usec per loop
The first is too clever for my taste.
The second is fast and easy to understand. It might attract improvements
replacing the slice with an index, but I trust you will catch that with your
unit tests ;)
Personally, I'm willing to spend the few extra milliseconds and use the
foolproof third.
For completeness:
# the slowest method from Peter
$ python -m timeit -s 's = alpha' 's.startswith() and s.endswith()'
100 loops, best of 3: 0.309 usec per loop
# the re method from Roy
$ python -m timeit -s import re;pattern=re.compile(r'^.*$');s = 'alpha'
pattern.match(s)
100 loops, best of 3: 0.466 usec per loop
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
Peter Otten __pete...@web.de: Personally, I'm willing to spend the few extra milliseconds and use the foolproof third. Speaking of foolproof, what is this key? Is it an XML start tag, maybe? Then, how does your test fare with, say, start comparison= which is equivalent to start comparison=gt; Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Thu, Feb 13, 2014 at 12:37 PM, forman.si...@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:] == '': ...
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
and:
if (key[:1], key[-1:]) == ('', ''): ...
I haven't run these through a profiler yet, but it seems like the original
might be the fastest after all?
In a fit of curiosity, I did some timings:
'and'ed indexing:
C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == ''
100 loops, best of 3: 0.35 usec per loop
C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == ''
100 loops, best of 3: 0.398 usec per loop
C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == ''
100 loops, best of 3: 0.188 usec per loop
C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == ''
1000 loops, best of 3: 0.211 usec per loop
C:\tmppy -m timeit -s key = '' key[0] == '' and key[-1] == ''
Traceback (most recent call last):
File P:\Python34\lib\timeit.py, line 292, in main
x = t.timeit(number)
File P:\Python34\lib\timeit.py, line 178, in timeit
timing = self.inner(it, self.timer)
File timeit-src, line 6, in inner
key[0] == '' and key[-1] == ''
IndexError: string index out of range
Slice concatenation:
C:\tmppy -m timeit -s key = 'test' key[:1] + key[-1:] == ''
100 loops, best of 3: 0.649 usec per loop
C:\tmppy -m timeit -s key = 'test' key[:1] + key[-1:] == ''
100 loops, best of 3: 0.7 usec per loop
C:\tmppy -m timeit -s key = 'test' key[:1] + key[-1:] == ''
100 loops, best of 3: 0.663 usec per loop
C:\tmppy -m timeit -s key = 'test' key[:1] + key[-1:] == ''
100 loops, best of 3: 0.665 usec per loop
C:\tmppy -m timeit -s key = '' key[:1] + key[-1:] == ''
100 loops, best of 3: 0.456 usec per loop
String methods:
C:\tmppy -m timeit -s key = 'test' key.startswith('') and
key.endswith('')
100 loops, best of 3: 1.03 usec per loop
C:\tmppy -m timeit -s key = 'test' key.startswith('') and
key.endswith('')
100 loops, best of 3: 1.02 usec per loop
C:\tmppy -m timeit -s key = 'test' key.startswith('') and
key.endswith('')
100 loops, best of 3: 0.504 usec per loop
C:\tmppy -m timeit -s key = 'test' key.startswith('') and
key.endswith('')
100 loops, best of 3: 0.502 usec per loop
C:\tmppy -m timeit -s key = '' key.startswith('') and key.endswith('')
100 loops, best of 3: 0.49 usec per loop
Tuple comparison:
C:\tmppy -m timeit -s key = 'test' (key[:1], key[-1:]) == ('', '')
100 loops, best of 3: 0.629 usec per loop
C:\tmppy -m timeit -s key = 'test' (key[:1], key[-1:]) == ('', '')
100 loops, best of 3: 0.689 usec per loop
C:\tmppy -m timeit -s key = 'test' (key[:1], key[-1:]) == ('', '')
100 loops, best of 3: 0.676 usec per loop
C:\tmppy -m timeit -s key = 'test' (key[:1], key[-1:]) == ('', '')
100 loops, best of 3: 0.675 usec per loop
C:\tmppy -m timeit -s key = '' (key[:1], key[-1:]) == ('', '')
100 loops, best of 3: 0.608 usec per loop
re.match():
C:\tmppy -m timeit -s import re;key = 'test' re.match(r'^.*$', key)
10 loops, best of 3: 3.39 usec per loop
C:\tmppy -m timeit -s import re;key = 'test' re.match(r'^.*$', key)
10 loops, best of 3: 3.27 usec per loop
C:\tmppy -m timeit -s import re;key = 'test' re.match(r'^.*$', key)
10 loops, best of 3: 2.94 usec per loop
C:\tmppy -m timeit -s import re;key = 'test' re.match(r'^.*$', key)
10 loops, best of 3: 2.97 usec per loop
C:\tmppy -m timeit -s import re;key = '' re.match(r'^.*$', key)
10 loops, best of 3: 2.97 usec per loop
Pre-compiled re:
C:\tmppy -m timeit -s import re;r = re.compile(r'^.*$');key =
'test' r.match(key)
100 loops, best of 3: 0.932 usec per loop
C:\tmppy -m timeit -s import re;r = re.compile(r'^.*$');key =
'test' r.match(key)
100 loops, best of 3: 0.79 usec per loop
C:\tmppy -m timeit -s import re;r = re.compile(r'^.*$');key =
'test' r.match(key)
100 loops, best of 3: 0.718 usec per loop
C:\tmppy -m timeit -s import re;r = re.compile(r'^.*$');key =
'test' r.match(key)
100 loops, best of 3: 0.755 usec per loop
C:\tmppy -m timeit -s import re;r = re.compile(r'^.*$');key = ''
r.match(key)
100 loops, best of 3: 0.731 usec per loop
Pre-compiled re with pre-fetched method:
C:\tmppy -m timeit -s import re;m = re.compile(r'^.*$').match;key
= 'test' m(key)
100 loops, best of 3: 0.777 usec per loop
C:\tmppy -m timeit -s import re;m = re.compile(r'^.*$').match;key
= 'test' m(key)
100 loops, best of 3: 0.65 usec per loop
C:\tmppy -m timeit -s import re;m = re.compile(r'^.*$').match;key
= 'test' m(key)
100 loops, best of 3: 0.652 usec per loop
C:\tmppy -m timeit -s import re;m = re.compile(r'^.*$').match;key
= 'test' m(key)
100 loops, best of 3: 0.576 usec per loop
C:\tmppy -m timeit -s import re;m =
Re: A curious bit of code...
On Fri, Feb 14, 2014 at 6:32 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
There will be an exception only if it is zero-length. But good
point! That's a pretty sneaky way to avoid checking for a
zero-length string. Is it a popular idiom?
I hope not.
The use of slicing rather than indexing to avoid problems when the
string's too short? I don't know about popular, but I've certainly
used it a good bit. For the specific case of string comparisons you
can use startswith/endswith, but slicing works with other types as
well.
Also worth noting:
Python 2.7.4 (default, Apr 6 2013, 19:54:46) [MSC v.1500 32 bit
(Intel)] on win32
Type copyright, credits or license() for more information.
s1,s2=basdf,uasdf
s1[:1],s2[:1]
('a', u'a')
s1[0],s2[0]
('a', u'a')
Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 16:23:43) [MSC
v.1600 32 bit (Intel)] on win32
Type copyright, credits or license() for more information.
s1,s2=basdf,uasdf
s1[:1],s2[:1]
(b'a', 'a')
s1[0],s2[0]
(97, 'a')
When you slice, you get back the same type as you started with. (Also
true of lists, tuples, and probably everything else that can be
sliced.) When you index, you might not; strings are a special case
(since Python lacks a character type), and if your code has to run
on Py2 and Py3, byte strings stop being that special case in Py3. So
if you're working with a byte string, it might be worth slicing rather
than indexing. (Though you can still use startswith/endswith, if they
suit your purpose.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2014-02-13 10:37, forman.si...@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.
Some possibilities that occurred to me:
if key.startswith('') and key.endswith(''): ...
This is my favorite because it doesn't break on the empty string like
some of your alternatives. Your k[0] and k[-1] assume there's at
least one character in the string, otherwise an IndexError is raised.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2014-02-13, Zachary Ware zachary.ware+pyl...@gmail.com wrote: In a fit of curiosity, I did some timings: 'and'ed indexing: C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.35 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.398 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.188 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 1000 loops, best of 3: 0.211 usec per loop C:\tmppy -m timeit -s key = '' key[0] == '' and key[-1] == '' Traceback (most recent call last): File P:\Python34\lib\timeit.py, line 292, in main x = t.timeit(number) File P:\Python34\lib\timeit.py, line 178, in timeit timing = self.inner(it, self.timer) File timeit-src, line 6, in inner key[0] == '' and key[-1] == '' IndexError: string index out of range The corrected version key and key[0] == '' and key[-1] == '' probably still wins the Pretty Unimportant Olympics. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Fri, Feb 14, 2014 at 7:55 AM, Emile van Sebille em...@fenx.com wrote: On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] AAARGG! Really, I actually did pause, double-take, and then scream under my breath, when I saw that. Yes, it works. But please, if you EVER do this, save me the trouble and just submit your code to thedailywtf.com straight away! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
Chris Angelico wrote: On Fri, Feb 14, 2014 at 7:55 AM, Emile van Sebille em...@fenx.com wrote: On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] AAARGG! Really, I actually did pause, double-take, and then scream under my breath, when I saw that. Yes, it works. But please, if you EVER do this, save me the trouble and just submit your code to thedailywtf.com straight away! For the record: s = x s[::len(s)-1] Traceback (most recent call last): File stdin, line 1, in module ValueError: slice step cannot be zero -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Fri, Feb 14, 2014 at 8:06 AM, Peter Otten __pete...@web.de wrote: For the record: s = x s[::len(s)-1] Traceback (most recent call last): File stdin, line 1, in module ValueError: slice step cannot be zero And that, my friends, is a classic example of a Python exception that ought to be a subclass of UnhingedProgrammerError. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 13/02/2014 21:01, Neil Cerutti wrote: On 2014-02-13, Zachary Ware zachary.ware+pyl...@gmail.com wrote: In a fit of curiosity, I did some timings: 'and'ed indexing: C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.35 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.398 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 100 loops, best of 3: 0.188 usec per loop C:\tmppy -m timeit -s key = 'test' key[0] == '' and key[-1] == '' 1000 loops, best of 3: 0.211 usec per loop C:\tmppy -m timeit -s key = '' key[0] == '' and key[-1] == '' Traceback (most recent call last): File P:\Python34\lib\timeit.py, line 292, in main x = t.timeit(number) File P:\Python34\lib\timeit.py, line 178, in timeit timing = self.inner(it, self.timer) File timeit-src, line 6, in inner key[0] == '' and key[-1] == '' IndexError: string index out of range The corrected version key and key[0] == '' and key[-1] == '' probably still wins the Pretty Unimportant Olympics. Exactly how I'd write it. To me it wins awards for being most boring and most obvious, obviously YMMV or we wouldn't be having this discussion. Or argument. Or contradiction :) -- 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Thu, Feb 13, 2014 at 2:55 PM, Emile van Sebille em...@fenx.com wrote: On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] It's not great, around 0.520 usec (the builtin lookup and function call is what gets it). Also, uglier than sin itself. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Thu, Feb 13, 2014 at 3:01 PM, Neil Cerutti ne...@norwich.edu wrote: On 2014-02-13, Zachary Ware zachary.ware+pyl...@gmail.com wrote: C:\tmppy -m timeit -s key = '' key[0] == '' and key[-1] == '' Traceback (most recent call last): File P:\Python34\lib\timeit.py, line 292, in main x = t.timeit(number) File P:\Python34\lib\timeit.py, line 178, in timeit timing = self.inner(it, self.timer) File timeit-src, line 6, in inner key[0] == '' and key[-1] == '' IndexError: string index out of range The corrected version key and key[0] == '' and key[-1] == '' probably still wins the Pretty Unimportant Olympics. Indeed, see the last set of timings and moral ;) -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article mailman.6880.1392324956.18130.python-l...@python.org, Emile van Sebille em...@fenx.com wrote: On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] Emile I love it. I need to add this to my list of Python trivia questions. -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2/13/2014 1:10 PM, Chris Angelico wrote: On Fri, Feb 14, 2014 at 8:06 AM, Peter Otten __pete...@web.de wrote: For the record: s = x s[::len(s)-1] Traceback (most recent call last): File stdin, line 1, in module ValueError: slice step cannot be zero And that, my friends, is a classic example of a Python exception that ought to be a subclass of UnhingedProgrammerError. And certainly s[::len(s)-1 or 1] isn't any better. :) Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Fri, Feb 14, 2014 at 8:19 AM, Zachary Ware zachary.ware+pyl...@gmail.com wrote: Also, uglier than sin itself. Hey hey, no need to insult our lovely trigonometric functions! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article mailman.6891.1392327074.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Fri, Feb 14, 2014 at 8:19 AM, Zachary Ware zachary.ware+pyl...@gmail.com wrote: Also, uglier than sin itself. Hey hey, no need to insult our lovely trigonometric functions! This newsgroup is taylor made for that kind of abuse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Thu, Feb 13, 2014 at 3:31 PM, Chris Angelico ros...@gmail.com wrote: On Fri, Feb 14, 2014 at 8:19 AM, Zachary Ware zachary.ware+pyl...@gmail.com wrote: Also, uglier than sin itself. Hey hey, no need to insult our lovely trigonometric functions! Here's your sine... -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
13.02.14 21:59, Zachary Ware написав(ла): don't use re for simple stuff (because while it may be very fast, it's dominated by attribute lookup and function call overhead), And the time of re variant depends on the size of input. -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
In article mailman.6893.1392328170.18130.python-l...@python.org, Serhiy Storchaka storch...@gmail.com wrote: 13.02.14 21:59, Zachary Ware напиÑав(ла): don't use re for simple stuff (because while it may be very fast, it's dominated by attribute lookup and function call overhead), And the time of re variant depends on the size of input. That's a good point. It's nice, for a change, to see somebody shoot down a regex solution for a valid reason :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 01:01 PM, Chris Angelico wrote: On Fri, Feb 14, 2014 at 7:55 AM, Emile van Sebille em...@fenx.com wrote: On 2/13/2014 11:59 AM, Zachary Ware wrote: In a fit of curiosity, I did some timings: Snip of lots of TMTOWTDT/TIMTOWTDI/whatever... timed examples :) But I didn't see this one: s[::len(s)-1] AAARGG! Really, I actually did pause, double-take, and then scream under my breath, when I saw that. Yes, it works. But please, if you EVER do this, save me the trouble and just submit your code to thedailywtf.com straight away! Oh, it's not that bad! All you have to do is handle the edge case of an empty string: s[::len(s)-1 if s else True] *ducks and runs* -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On Fri, Feb 14, 2014 at 8:33 AM, Ethan Furman et...@stoneleaf.us wrote:
Oh, it's not that bad! All you have to do is handle the edge case of an
empty string:
s[::len(s)-1 if s else True]
*ducks and runs*
And the edge case of the one-character string. Also, it's been noted
that calling the built-in function len() is slow, so I propose
changing that.
s[::(sys.getsizeof(\N{MATHEMATICAL BOLD CAPITAL
L}+s)-sys.getsizeof(\N{MATHEMATICAL BOLD CAPITAL E}\N{MATHEMATICAL
BOLD CAPITAL N}) or 4)//4]
Note the elegance of using the word LEN across two string literals
(because string literals are fast) as a means of clearly describing
what we are doing - an optimization of the built-in len() function.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 02:13 PM, Chris Angelico wrote: On Fri, Feb 14, 2014 at 8:33 AM, Ethan Furman et...@stoneleaf.us wrote: Oh, it's not that bad! All you have to do is handle the edge case of an empty string: s[::len(s)-1 if s else True] And the edge case of the one-character string. Oops, my description should have said edge case of a one-character string. The empty string needs no extra handling. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2/13/2014 1:37 PM, forman.si...@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. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 02/13/2014 01:24 PM, Roy Smith wrote: Emile van Sebille wrote: But I didn't see this one: s[::len(s)-1] I love it. I need to add this to my list of Python trivia questions. Great interview question: What does this do? What is its weakness? How would you fix it? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: A curious bit of code...
On 2/13/14 9:45 PM, forman.si...@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 -- https://mail.python.org/mailman/listinfo/python-list
