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

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

Re: get each pair from a string.

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: get each pair from a string. rusi <rustompmody@gmail.com> - 2012-10-22 09:19 -0700
    Re: get each pair from a string. rusi <rustompmody@gmail.com> - 2012-10-22 21:59 -0700
      Re: get each pair from a string. wxjmfauth@gmail.com - 2012-10-22 23:47 -0700
        Re: get each pair from a string. Neil Cerutti <neilc@norwich.edu> - 2012-10-23 12:30 +0000
        Re: get each pair from a string. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-23 13:44 +0100
        Re: get each pair from a string. Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-23 10:41 -0600
          Re: get each pair from a string. wxjmfauth@gmail.com - 2012-10-24 02:32 -0700
            Re: get each pair from a string. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-10-24 13:14 +0100
          Re: get each pair from a string. wxjmfauth@gmail.com - 2012-10-24 02:32 -0700

#31895 — Re: get each pair from a string.

On 10/21/2012 11:33 AM, Vincent Davis wrote:

> I am looking for a good way to get every pair from a string. For example,
> input:
> x = 'apple'
> output
> 'ap'
> 'pp'
> 'pl'
> 'le'

Maybe zip before izip for a noob?

>>> s="apple"
>>> [a+b for a,b in zip(s, s[1:])]
['ap', 'pp', 'pl', 'le']
>>>

[toc] | [next] | [standalone]

#31915

On Oct 22, 9:19 pm, rusi <rustompm...@gmail.com> wrote:
> On 10/21/2012 11:33 AM, Vincent Davis wrote:
>
> > I am looking for a good way to get every pair from a string. For example,
> > input:
> > x = 'apple'
> > output
> > 'ap'
> > 'pp'
> > 'pl'
> > 'le'
>
> Maybe zip before izip for a noob?
>
> >>> s="apple"
> >>> [a+b for a,b in zip(s, s[1:])]
>
> ['ap', 'pp', 'pl', 'le']

Daniel wrote:
> This is a little bit faster:
>
> s = "apple"
> [s[i:i+2] for i in range(len(s)-1)]

Nice! I always find pairs of structural decomposition of input vs
recomposition of output interesting.
In this case the use of slices:
to decompose: s -> s[1:]
vs doing s[i:i+2]

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

#31916

Le mardi 23 octobre 2012 06:59:49 UTC+2, rusi a écrit :
> On Oct 22, 9:19 pm, rusi <rustompm...@gmail.com> wrote:
> 
> > On 10/21/2012 11:33 AM, Vincent Davis wrote:
> 
> >
> 
> > > I am looking for a good way to get every pair from a string. For example,
> 
> > > input:
> 
> > > x = 'apple'
> 
> > > output
> 
> > > 'ap'
> 
> > > 'pp'
> 
> > > 'pl'
> 
> > > 'le'
> 
> >
> 
> > Maybe zip before izip for a noob?
> 
> >
> 
> > >>> s="apple"
> 
> > >>> [a+b for a,b in zip(s, s[1:])]
> 
> >
> 
> > ['ap', 'pp', 'pl', 'le']
> 
> 
> 
> Daniel wrote:
> 
> > This is a little bit faster:
> 
> >
> 
> > s = "apple"
> 
> > [s[i:i+2] for i in range(len(s)-1)]
> 
> 
> 
> Nice! I always find pairs of structural decomposition of input vs
> 
> recomposition of output interesting.
> 
> In this case the use of slices:
> 
> to decompose: s -> s[1:]
> 
> vs doing s[i:i+2]

Why bother with speeed?

The latest Python version is systematically slower
than the previous ones as soon as one uses non "ascii
strings".

Python users are discussing "code optimizations" without
realizing the tool they are using, has killed itself its
own performances.

(Replace 'apple' with 'ap需')

jmf

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

#31928

On 2012-10-23, wxjmfauth@gmail.com <wxjmfauth@gmail.com> wrote:
> Why bother with speeed?

Because the differences between O(N), O(log(N)) and O(N ** 2)
operations are often relevant.

A Python string replace function experiencing a slow-down from
previous versions doesn't absolve me from making informed choices
of algorithm and implentation.

-- 
Neil Cerutti

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

#31929

On 23/10/2012 07:47, wxjmfauth@gmail.com wrote:
>
> Why bother with speeed?
>
> The latest Python version is systematically slower
> than the previous ones as soon as one uses non "ascii
> strings".
>
> Python users are discussing "code optimizations" without
> realizing the tool they are using, has killed itself its
> own performances.
>
> (Replace 'apple' with 'ap需')
>
> jmf
>

Please stop giving blatant lies on this list about Python speed.

-- 
Cheers.

Mark Lawrence.

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

#31941

On Tue, Oct 23, 2012 at 12:47 AM,  <wxjmfauth@gmail.com> wrote:
> The latest Python version is systematically slower
> than the previous ones as soon as one uses non "ascii
> strings".

No, it isn't.  You've previously demonstrated a *microbenchmark* where
3.3 is slower than 3.2.  This is a far cry from demonstrating that 3.3
is "systematically slower", and that larger claim is simply false.

In any case, have you been following the progress of issue 16061?
There is a patch for the str.replace regression that you identified,
which results in better performance across the board than 3.2.  So
although 3.3 is slower than 3.2 on this one microbenchmark, 3.4 will
not be.

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

#32023

Le mardi 23 octobre 2012 18:41:45 UTC+2, Ian a écrit :
> On Tue, Oct 23, 2012 at 12:47 AM,  <wxjmfauth@gmail.com> wrote:
> 
> 
> 
> In any case, have you been following the progress of issue 16061?
> 
> There is a patch for the str.replace regression that you identified,
> 
> which results in better performance across the board than 3.2.  So
> 
> although 3.3 is slower than 3.2 on this one microbenchmark, 3.4 will
> 
> not be.

Yes.
A workaround to solve one of the corner cases of something
which is wrong by design.

jmf

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

#32030

On 24/10/2012 10:32, wxjmfauth@gmail.com wrote:
> Le mardi 23 octobre 2012 18:41:45 UTC+2, Ian a écrit :
>> On Tue, Oct 23, 2012 at 12:47 AM,  <wxjmfauth@gmail.com> wrote:
>>
>>
>>
>> In any case, have you been following the progress of issue 16061?
>>
>> There is a patch for the str.replace regression that you identified,
>>
>> which results in better performance across the board than 3.2.  So
>>
>> although 3.3 is slower than 3.2 on this one microbenchmark, 3.4 will
>>
>> not be.
>
> Yes.
> A workaround to solve one of the corner cases of something
> which is wrong by design.
>
> jmf
>

Do you get paid money for acting as a complete moron or do you do it for 
free?

-- 
Cheers.

Mark Lawrence.

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

#32024

Le mardi 23 octobre 2012 18:41:45 UTC+2, Ian a écrit :
> On Tue, Oct 23, 2012 at 12:47 AM,  <wxjmfauth@gmail.com> wrote:
> 
> 
> 
> In any case, have you been following the progress of issue 16061?
> 
> There is a patch for the str.replace regression that you identified,
> 
> which results in better performance across the board than 3.2.  So
> 
> although 3.3 is slower than 3.2 on this one microbenchmark, 3.4 will
> 
> not be.

Yes.
A workaround to solve one of the corner cases of something
which is wrong by design.

jmf

[toc] | [prev] | [standalone]

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

csiph-web