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

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

Article on the future of Python

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

Contents

  Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-25 09:15 +0100
    Re: Article on the future of Python Kevin Walzer <kw@codebykevin.com> - 2012-09-25 09:26 -0400
      Re: Article on the future of Python Roy Smith <roy@panix.com> - 2012-09-25 09:44 -0400
      Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-25 15:35 +0000
        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 01:48 +1000
        Re: Article on the future of Python Ramchandra Apte <maniandram01@gmail.com> - 2012-09-26 02:28 -0700
          Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 05:39 -0400
        Re: Article on the future of Python Kevin Walzer <kw@codebykevin.com> - 2012-09-26 09:30 -0400
          Re: Article on the future of Python Matej Cepl <mcepl@redhat.com> - 2012-09-27 00:44 +0200
          Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 00:44 +0000
            Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 15:37 +1000
              Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 06:01 +0000
                Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 16:08 +1000
                  Re: Article on the future of Python Grant Edwards <invalid@invalid.invalid> - 2012-09-27 13:59 +0000
                    Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-28 00:32 +1000
                      Re: Article on the future of Python Walter Hurry <walterhurry@lavabit.com> - 2012-09-28 01:22 +0000
                        Re: Article on the future of Python Jason Friedman <jason@powerpull.net> - 2012-09-27 21:05 -0600
                        Re: Article on the future of Python "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-09-27 21:14 -0600
                        Re: Article on the future of Python Wayne Werner <wayne@waynewerner.com> - 2012-09-27 22:37 -0500
                        Re: Article on the future of Python Greg Donald <gdonald@gmail.com> - 2012-09-27 22:50 -0500
                        Re: Article on the future of Python Greg Donald <gdonald@gmail.com> - 2012-09-27 23:12 -0500
                        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-28 14:37 +1000
                          Re: Article on the future of Python rurpy@yahoo.com - 2012-09-28 08:52 -0700
                          Re: Article on the future of Python rurpy@yahoo.com - 2012-09-28 08:52 -0700
                        Re: Article on the future of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-28 10:31 -0400
                        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-29 00:58 +1000
                        Re: Article on the future of Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-28 09:14 -0600
                        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-29 01:20 +1000
                Re: Article on the future of Python Serhiy Storchaka <storchaka@gmail.com> - 2012-09-27 12:20 +0300
      Re: Article on the future of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-25 12:13 -0400
      Re: Article on the future of Python Paul Rubin <no.email@nospam.invalid> - 2012-09-25 10:27 -0700
    Re: Article on the future of Python "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-09-25 06:56 -0700
    Re: Article on the future of Python "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-09-25 06:56 -0700
      Re: Article on the future of Python Grant Edwards <invalid@invalid.invalid> - 2012-09-25 18:25 +0000
        Re: Article on the future of Python 88888 Dihedral <dihedral88888@googlemail.com> - 2012-09-25 16:34 -0700
          Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-25 23:35 -0700
            Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-26 07:23 +0000
              Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 02:31 -0700
                Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 19:55 +1000
                  Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 07:19 -0700
                    Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 00:24 +1000
                      Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 07:50 -0700
                        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 00:56 +1000
                          Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 08:17 -0700
                          Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 08:17 -0700
                        Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 16:08 +0100
                        Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 01:18 +1000
                          Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 08:45 -0700
                          Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 08:45 -0700
                            Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 09:33 +0000
                              Re: Article on the future of Python Alex Strickland <sscc@mweb.co.za> - 2012-09-27 12:43 +0200
                              Re: Article on the future of Python Serhiy Storchaka <storchaka@gmail.com> - 2012-09-27 15:46 +0300
                              Re: Article on the future of Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-27 09:06 -0600
                              Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 17:03 +0100
                              Re: Article on the future of Python Serhiy Storchaka <storchaka@gmail.com> - 2012-09-27 20:17 +0300
                                Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-27 12:09 -0700
                                  Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 21:16 +0100
                                  Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-28 08:00 +1000
                                Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-27 12:09 -0700
                              Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-27 15:08 -0400
                              Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-28 10:16 +0100
                      Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 07:50 -0700
                  Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 07:19 -0700
                    Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 00:36 +0000
                  Re: Article on the future of Python Paul Rubin <no.email@nospam.invalid> - 2012-09-26 09:52 -0700
                    Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 03:04 +1000
                      Re: Article on the future of Python Paul Rubin <no.email@nospam.invalid> - 2012-09-26 10:32 -0700
                    Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 11:35 -0700
                Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 14:21 +0100
              Re: Article on the future of Python Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-26 09:53 -0600
                Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 09:18 -0700
                Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 09:18 -0700
            Re: Article on the future of Python Ethan Furman <ethan@stoneleaf.us> - 2012-09-26 00:17 -0700
            Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 03:39 -0400
            Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 17:44 +1000
            Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 04:11 -0400
            Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-26 04:13 -0400
              Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 05:19 -0700
                Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 23:43 +1000
                Re: Article on the future of Python Ethan Furman <ethan@stoneleaf.us> - 2012-09-26 09:08 -0700
                Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-26 19:24 -0400
              Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 05:19 -0700
            Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 09:34 +0100
              Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 05:17 -0700
                Re: Article on the future of Python alex23 <wuwei23@gmail.com> - 2012-09-26 17:14 -0700
                  Re: Article on the future of Python Walter Hurry <walterhurry@lavabit.com> - 2012-09-27 01:37 +0000
              Re: Article on the future of Python wxjmfauth@gmail.com - 2012-09-26 05:17 -0700
            Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 09:37 +0100
            Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 18:44 +1000
            Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 04:45 -0400
            Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 04:47 -0400
            Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 10:01 +0100
              Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 00:40 +0000
                Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 02:10 +0100
            Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-26 05:09 -0400
            Re: Article on the future of Python "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-09-26 07:31 -0600
            Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 14:43 +0100
            Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 23:51 +1000
            Re: Article on the future of Python Ethan Furman <ethan@stoneleaf.us> - 2012-09-26 09:05 -0700
            Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-26 16:27 -0400
              Re: Article on the future of Python alex23 <wuwei23@gmail.com> - 2012-09-26 18:38 -0700
            Re: Fwd: Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-26 19:29 -0400
            Re: Fwd: Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-27 09:42 +1000
        Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-26 00:54 +0000
          Re: Article on the future of Python Paul Rubin <no.email@nospam.invalid> - 2012-09-25 18:04 -0700
            Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 14:10 +1000
              Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-26 05:16 +0000
                Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-26 16:02 +1000
                  Re: Article on the future of Python Paul Rubin <no.email@nospam.invalid> - 2012-09-25 23:09 -0700
            Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 09:32 +0100
            Re: Article on the future of Python Hannu Krosing <hannu@krosing.net> - 2012-09-26 12:01 +0200
              Re: Article on the future of Python Roy Smith <roy@panix.com> - 2012-09-26 09:01 -0400
                Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-26 14:28 +0100
                Re: Article on the future of Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-26 13:22 -0400
    Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 06:13 +0000
      Re: Article on the future of Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-09-27 08:11 -0400
        Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-27 14:25 +0000
          Re: Article on the future of Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-09-27 12:16 -0400
            Re: Article on the future of Python alex23 <wuwei23@gmail.com> - 2012-09-27 17:59 -0700
              Re: Article on the future of Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-09-28 14:50 -0400
                Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-29 03:07 +0000
          Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 17:45 +0100
          Re: Article on the future of Python Chris Angelico <rosuav@gmail.com> - 2012-09-28 02:49 +1000
          Re: Article on the future of Python Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-09-27 12:50 -0400
          Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 17:58 +0100
          Re: Article on the future of Python Ethan Furman <ethan@stoneleaf.us> - 2012-09-27 09:53 -0700
          Re: Article on the future of Python Terry Reedy <tjreedy@udel.edu> - 2012-09-27 15:32 -0400
        Re: Article on the future of Python Bob Martin <bob.martin@excite.com> - 2012-09-28 08:06 +0100
          Re: Article on the future of Python Dwight Hutto <dwightdhutto@gmail.com> - 2012-09-28 03:22 -0400
        Re: Article on the future of Python rusi <rustompmody@gmail.com> - 2012-09-28 05:08 -0700
          Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-28 12:54 +0000
            Re: Article on the future of Python rusi <rustompmody@gmail.com> - 2012-09-28 06:14 -0700
              Re: Article on the future of Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-28 16:33 +0000
      Re: Article on the future of Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-09-27 17:47 +0100
        Re: Article on the future of Python alex23 <wuwei23@gmail.com> - 2012-09-27 17:59 -0700

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#30207

On Thu, Sep 27, 2012 at 12:19 AM,  <wxjmfauth@gmail.com> wrote:
> No, I'm comparing Py33 with Py32 narrow build [*].

Then look at the broken behaviour that Python, up until now, shared
with Javascript and various other languages, in which a one-character
string appears as two characters, and slicing and splicing strings can
split surrogates apart. The new rule is simple: One Unicode codepoint
takes up the space of one character. Anything else is mindbogglingly
counterintuitive.

ChrisA

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

#30208

I should add that I have not the knowledge to dive
in the Python code. But I "see" what has been done.
As I have a very good understanding of all this
coding of characters stuff, I can just pick up
- in fact select characters or combination
of characters - which I supspect to be problematic
and I see the results.

Not only this, I can select characters, I know
a user is supposed to use or will use eg. a specific
scrit/language, a typographical work, ...
(Do not ask how and why, I know this).

I'm not interesting in the other languages or in
unicode therory (also I not bad on this level).

I just see the results and the facts. For an end
user, this is the only thing that counts.

jmf

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

#30210

On Thu, Sep 27, 2012 at 12:50 AM,  <wxjmfauth@gmail.com> wrote:
> I just see the results and the facts. For an end
> user, this is the only thing that counts.

Then what counts is that Python 3.2 (like Javascript) exhibits
incorrect behaviour, and Python (like Pike) performs correctly.

I think this tee applies to you. http://www.thinkgeek.com/product/f147/

ChrisA
wouldn't have bothered to respond except that that link was asking to be shared

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

#30212

Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit :
> On Thu, Sep 27, 2012 at 12:50 AM,  <wxjmfauth@gmail.com> wrote:
> 
> > I just see the results and the facts. For an end
> 
> > user, this is the only thing that counts.
> 
> 
> 
> Then what counts is that Python 3.2 (like Javascript) exhibits
> 
> incorrect behaviour, and Python (like Pike) performs correctly.
> 
> 
> 
> I think this tee applies to you. http://www.thinkgeek.com/product/f147/
> 
> 
> 
> ChrisA
> 
> wouldn't have bothered to respond except that that link was asking to be shared

"You" have gained a broader range of unicode code points
and the same time you "broke" a correct BMP behaviour.

There is a simple solution to solve this. "You" do not wish
to use it.
Luckily for me, the tools I'm using use that one.

jmf

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

#30213

Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit :
> On Thu, Sep 27, 2012 at 12:50 AM,  <wxjmfauth@gmail.com> wrote:
> 
> > I just see the results and the facts. For an end
> 
> > user, this is the only thing that counts.
> 
> 
> 
> Then what counts is that Python 3.2 (like Javascript) exhibits
> 
> incorrect behaviour, and Python (like Pike) performs correctly.
> 
> 
> 
> I think this tee applies to you. http://www.thinkgeek.com/product/f147/
> 
> 
> 
> ChrisA
> 
> wouldn't have bothered to respond except that that link was asking to be shared

"You" have gained a broader range of unicode code points
and the same time you "broke" a correct BMP behaviour.

There is a simple solution to solve this. "You" do not wish
to use it.
Luckily for me, the tools I'm using use that one.

jmf

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

#30211

On 26/09/2012 15:50, wxjmfauth@gmail.com wrote:
> I should add that I have not the knowledge to dive
> in the Python code. But I "see" what has been done.

How?

> As I have a very good understanding of all this
> coding of characters stuff, I can just pick up
> - in fact select characters or combination
> of characters - which I supspect to be problematic
> and I see the results.

Have you run the Python benchmarks yet, as people have more trust in 
something tangible than a claim that "I see the results"?  You were 
asked to do this one month ago.  If yes please publish your results.  If 
no why not, if your claims were correct running the benchmarks would 
obviously support you?

>
> Not only this, I can select characters, I know
> a user is supposed to use or will use eg. a specific
> scrit/language, a typographical work, ...
> (Do not ask how and why, I know this).

Please state how and why.

>
> I'm not interesting in the other languages or in
> unicode therory (also I not bad on this level).

Please prove your statement in brackets, nothing less is acceptable if 
you're making claims, you need to substantiate them.

>
> I just see the results and the facts. For an end
> user, this is the only thing that counts.

The modern day Pinball Wizard?  Or a physic?  Or what?

>
> jmf
>

#pseudo code
for _ in range(-inf, +inf, 1): print(FUD)

-- 
Cheers.

Mark Lawrence.

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

#30214

On Thu, Sep 27, 2012 at 1:08 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> for _ in range(-inf, +inf, 1): print(FUD)

That'll never work. Try this:

import itertools
list(map(print,itertools.cycle(('FUD',))))

ChrisA

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

#30215

Sorry guys, I'm "only" able to see this
(with the Python versions an end user can
download):

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[31.44532887821319, 31.409585124813844, 31.40705548932476]

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[323.56687741054805, 323.1660997337247, 325.52611455786905]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[31.48614883771855, 31.472262820580987, 31.467803762040184]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[320.55378064913526, 321.6890182785167, 321.4132045160866]

(Will wait for the final)

jmf

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

#30216

Sorry guys, I'm "only" able to see this
(with the Python versions an end user can
download):

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[31.44532887821319, 31.409585124813844, 31.40705548932476]

>>> timeit.repeat("('你'*10000).replace('你', 'a')")
[323.56687741054805, 323.1660997337247, 325.52611455786905]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[31.48614883771855, 31.472262820580987, 31.467803762040184]

>>> timeit.repeat("('\u2207'*10000).replace('\u2207', 'a')")
[320.55378064913526, 321.6890182785167, 321.4132045160866]

(Will wait for the final)

jmf

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

#30285

On Wed, 26 Sep 2012 08:45:30 -0700, wxjmfauth wrote:

> Sorry guys, I'm "only" able to see this (with the Python versions an end
> user can download):

[snip timeit results]

While you have been all doom and gloom and negativity that Python has 
"destroyed" Unicode, I've actually done some testing. It seems that, 
possibly, there is a performance regression in the "replace" method.

This is on Debian squeeze, using the latest rc version of 3.3, 3.3.0rc3:

py> timeit.repeat("('b'*1000).replace('b', 'a')")
[28.308280900120735, 29.012173799797893, 28.834429003298283]

Notice that Unicode doesn't come into it, they are pure ASCII strings. 
Here's the same thing using 3.2.2:

py> timeit.repeat("('b'*1000).replace('b', 'a')")
[3.4444618225097656, 3.147739887237549, 3.132185935974121]

That's a factor of 9 slowdown in 3.3, and no Unicode. Obviously Python 
has "destroyed ASCII".

(I get similar slowdowns for Unicode strings too, so clearly Python hates 
all strings, not just ASCII.)

Now, for irrelevant reasons, here I swapped to Centos.

[steve@ando ~]$ python2.7 -m timeit "'b'*1000"
1000000 loops, best of 3: 0.48 usec per loop
[steve@ando ~]$ python3.2 -m timeit "'b'*1000"
1000000 loops, best of 3: 1.3 usec per loop
[steve@ando ~]$ python3.3 -m timeit "'b'*1000"
1000000 loops, best of 3: 0.397 usec per loop

Clearly 3.3 is the fastest at string multiplication, at least for this 
trivial example. Just to prove that the result also applies to Unicode:

[steve@ando ~]$ python3.3 -m timeit "('你'*1000)"
1000000 loops, best of 3: 1.38 usec per loop

Almost identical to 3.2. And the reason it is slower than the 3.3 test 
using 'b' above is almost certainly because the string uses four times 
more memory:

[steve@ando ~]$ python3.3 -m timeit "('abcd'*1000)"
1000000 loops, best of 3: 0.919 usec per loop

So a little slower that the pure-ASCII version for the same amount of 
memory, but not significantly so.

But add a call to replace, and things are very different:

[steve@ando ~]$ python2.7 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 9.3 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 5.43 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = 'b'*1000" "s.replace('b', 'a')"
100000 loops, best of 3: 18.3 usec per loop


Three times slower, even for pure-ASCII strings. I get comparable results 
for Unicode. Notice how slow Python 2.7 is:

[steve@ando ~]$ python2.7 -m timeit -s "s = u'你'*1000" "s.replace(u'你', u'a')"
10000 loops, best of 3: 65.6 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s "s = '你'*1000" "s.replace('你', 'a')"
100000 loops, best of 3: 2.79 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s "s = '你'*1000" "s.replace('你', 'a')"
10000 loops, best of 3: 23.7 usec per loop

Even with the performance regression, it is still over twice as fast as 
Python 2.7.

Nevertheless, I think there is something here. The consequences are nowhere
near as dramatic as jmf claims, but it does seem that replace() has taken a
serious performance hit. Perhaps it is unavoidable, but perhaps not.

If anyone else can confirm similar results, I think this should be raised as
a performance regression.



-- 
Steven

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

#30287

Hi

>> Sorry guys, I'm "only" able to see this (with the Python versions an end
>> user can download):
>
> [snip timeit results]
>
> While you have been all doom and gloom and negativity that Python has
> "destroyed" Unicode,

I thought that jmf's concerns were solely concerned with the selection 
of latin1 as the 1 byte set. My impression was that if some set of 
characters was chosen that included all characters commonly used in 
French then all would be well with the world.

But now I'm confused because latin1 seems to cater for French quite well:

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

-- 
Regards
Alex

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

#30292

On 27.09.12 12:33, Steven D'Aprano wrote:
> Nevertheless, I think there is something here. The consequences are nowhere
> near as dramatic as jmf claims, but it does seem that replace() has taken a
> serious performance hit. Perhaps it is unavoidable, but perhaps not.
>
> If anyone else can confirm similar results, I think this should be raised as
> a performance regression.

Yes, I confirm, it's a performance regression. It should be avoidable. 
Almost any PEP393 performance regression can be avoided. At least for 
such corner case. Just no one has yet optimized this case.

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

#30297

On Thu, Sep 27, 2012 at 4:43 AM, Alex Strickland <sscc@mweb.co.za> wrote:
> I thought that jmf's concerns were solely concerned with the selection of
> latin1 as the 1 byte set. My impression was that if some set of characters
> was chosen that included all characters commonly used in French then all
> would be well with the world.
>
> But now I'm confused because latin1 seems to cater for French quite well:
>
> http://en.wikipedia.org/wiki/ISO/IEC_8859-1

I understand ISO 8859-15 (Latin-9) to be the preferred Latin character
set for French, as it includes the Euro sign as well as a few
characters that are not in Latin-1 but are nonetheless infrequently
found in French.

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

#30301

On 27/09/2012 13:46, Serhiy Storchaka wrote:
> On 27.09.12 12:33, Steven D'Aprano wrote:
>> Nevertheless, I think there is something here. The consequences are
>> nowhere
>> near as dramatic as jmf claims, but it does seem that replace() has
>> taken a
>> serious performance hit. Perhaps it is unavoidable, but perhaps not.
>>
>> If anyone else can confirm similar results, I think this should be
>> raised as
>> a performance regression.
>
> Yes, I confirm, it's a performance regression. It should be avoidable.
> Almost any PEP393 performance regression can be avoided. At least for
> such corner case. Just no one has yet optimized this case.
>
>

I have taken a liberty and raised this on the bug tracker quoting Steven 
D'Aprano's original figures and your response above.

-- 
Cheers.

Mark Lawrence.

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

#30313

On 27.09.12 18:06, Ian Kelly wrote:
> I understand ISO 8859-15 (Latin-9) to be the preferred Latin character
> set for French, as it includes the Euro sign as well as a few
> characters that are not in Latin-1 but are nonetheless infrequently
> found in French.

Even for Latin-9 Python 3.3 can be a little faster 3.2.

$ ./python -m timeit -s "s=bytes(range(256))*100"  "s.decode('latin1')"

Python 2.7: 105 usec
Python 3.2: 20.4 usec
Python 3.3: 4.98 usec

$ ./python -m timeit -s "s=bytes(range(256))*100"  "s.decode('latin9')"

Python 2.7: 700 usec
Python 3.2: 94.6 usec
Python 3.3: 93.2 usec

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

#30322

This flexible string representation is wrong by design.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.
The latin-1 chunk illustrates this wonderfully.

jmf

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

#30325

On 27/09/2012 20:09, wxjmfauth@gmail.com wrote:
> This flexible string representation is wrong by design.

Please state who agrees with this and why.

> Expecting to divide "Unicode" in chunks and to gain something
> is an illusion.

Please provide the benchmarks to support your claim.

> It has been created by a computer scientist who thinks "bytes"
> when on that field one has to think "bytes" and usage of the
> characters at the same time.

Please name this computer scientist so everybody knows to whom you are 
referring.

> The latin-1 chunk illustrates this wonderfully.

I understand from an earlier post that latin-9 meets your needs 
completely for all French language characters plus the Euro sign, why 
don't you simply use that and stop rabitting on about latin-1.

>
> jmf
>

Would you please be so kind as to stand up as your voice is rather muffled.

-- 
Cheers.

Mark Lawrence.

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

#30331

You're posting to both comp.lang.python and python-list, are you aware
that that's redundant?

On Fri, Sep 28, 2012 at 5:09 AM,  <wxjmfauth@gmail.com> wrote:
> This flexible string representation is wrong by design.
> Expecting to divide "Unicode" in chunks and to gain something
> is an illusion.
> It has been created by a computer scientist who thinks "bytes"
> when on that field one has to think "bytes" and usage of the
> characters at the same time.

There's another range of numbers that, in some languages, is divided
for efficiency's sake: Integers below 1<<[bit size]. In Python 2, such
numbers were an entirely different data type (int vs long); other
languages let you use the same data type for both, but "(1<<5)+1" will
be executed much faster than "(1<<500)+1". (And far as I know, a
conforming Python 3 implementation should be allowed to do that; 3.2
on Windows doesn't seem to, though.) That's all PEP 393 is; it's a
performance improvement for a particular subset of values that happens
to fit conveniently into the underlying machine's data storage.

If Python were implemented on a 9-bit computer, I wouldn't be
surprised if the PEP 393 optimizations were applied differently. It's
nothing to do with Latin-1, except insofar as the narrowest form of
string _happens_ to contain everything that's in Latin-1.

Go blame the Unicode consortium for picking that.

> The latin-1 chunk illustrates this wonderfully.

Aside from replace(), as mentioned in this thread, are there any other
ways that this is so wonderfully illustrated? Or is it "wonderfully"
as in "I wonder if people will believe me if I keep spouting
unsubstantiated claims"?

ChrisA

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

#30323

This flexible string representation is wrong by design.
Expecting to divide "Unicode" in chunks and to gain something
is an illusion.
It has been created by a computer scientist who thinks "bytes"
when on that field one has to think "bytes" and usage of the
characters at the same time.
The latin-1 chunk illustrates this wonderfully.

jmf

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

#30321

On 9/27/2012 5:33 AM, Steven D'Aprano wrote:

> Nevertheless, I think there is something here. The consequences are nowhere
> near as dramatic as jmf claims, but it does seem that replace() has taken a
> serious performance hit. Perhaps it is unavoidable, but perhaps not.
>
> If anyone else can confirm similar results,

I already did, about a month ago, for windows. I think the actual 
problem is with find, not replace (which does a find before the 
replace). When I asked on pydev, Victor Stinner had no explanation, but 
said he might look into it eventually. Others thought it not terribly 
important since 7 times blazingly fast is still fast (in your example, 
29 versus 3 microseconds per operation.

jmf wrapping a possible real issue with anti-3.3 crud did not help in 
getting attention to the regression.

I also reported results of running stringbench.py on both 3.2 and 3.3 on 
windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as 
3.2. Find/replace is the notable exception in stringbench, so it is an 
anomaly. Other things are faster in 3.3.

> I think this should be raised as a performance regression.

I agree, and Mark did it.

-- 
Terry Jan Reedy

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

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

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

csiph-web