Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #30043 > unrolled thread
| Started by | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| First post | 2012-09-25 09:15 +0100 |
| Last post | 2012-09-27 17:59 -0700 |
| Articles | 20 on this page of 135 — 30 participants |
Back to article view | Back to comp.lang.python
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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2012-09-28 10:16 +0100 |
| Message-ID | <mailman.1546.1348823383.27098.python-list@python.org> |
| In reply to | #30285 |
On 27/09/2012 20:08, Terry Reedy wrote: > 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. > http://bugs.python.org/issue16061 and you should read it. I've tried to really muddy the waters by opening this issue, and the python devs are giving out facts, how dare they!!! It's just not my day is it? :( -- Cheers. Mark Lawrence.
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 07:50 -0700 |
| Message-ID | <mailman.1439.1348671063.27098.python-list@python.org> |
| In reply to | #30207 |
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]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 07:19 -0700 |
| Message-ID | <mailman.1437.1348669201.27098.python-list@python.org> |
| In reply to | #30179 |
Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit : > On Wed, Sep 26, 2012 at 7:31 PM, <wxjmfauth@gmail.com> wrote: > > > you are correct. But the price you pay for this is extremely > > > high. Now, practically all characters are affected, espacially > > > those *in* the Basic *** Multilingual*** Plane, these characters > > > used by non "American" user (No offense here, I just use this > > > word for ascii/latin-1). > > > > > > I'm ready to be considered as an idiot, but I'm not blind. > > > As soon as I tested these characters, Py3.3 performs really > > > badly. It seems to me it is legitimate to consider, there > > > is a serious problem here. > > > > We've been over this thread. The only reason you're counting 3.3 as > > worse is because you're comparing against a narrow build of Python > > 3.2. Narrow builds are **BUGGY** and this needed to be resolved. > > > > When you compare against a wide build, semantics of 3.2 and 3.3 are > > identical, and then - and ONLY then - can you sanely compare > > performance. And 3.3 stacks up much better. > > > > ChrisA No, I'm comparing Py33 with Py32 narrow build [*]. And I am not a Python newbie. Others in a previous discussion have pointed "bad" numbers and even TR wrote something like "I'm baffled (?) by these numbers". I took a look at the test suites, unfortunatelly they are mainly testing "special cases", something like one of the 3 internal representations, eg "latin-1". I can also add to this, that it is not only one of the internal representation which may be suspect (it is probably different now, Py32/Py33) but also the "switch" between these representations which is causing troubles. [*] I have not the knowledge to compile a wide build and I do not wish to spend my time in something that will be most probably a nightmare for me. I'm reacting like a "normal" Python user. jmf
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-09-27 00:36 +0000 |
| Message-ID | <50639f78$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #30206 |
On Wed, 26 Sep 2012 07:19:56 -0700, wxjmfauth wrote: > No, I'm comparing Py33 with Py32 narrow build [*]. And I am not a Python > newbie. Others in a previous discussion have pointed "bad" numbers and > even TR wrote something like "I'm baffled (?) by these numbers". jmf, some time ago I said to you that if you want your claims to be taken seriously, you should come up with a test suite that exercises the FULL range of string operations and still demonstrates a significant slowdown. Have you do this? I would be interested to run your test suite. We know that if the only thing you do is repeatedly create strings, then throw them away, then create more strings, then throw them away, Python 3.3 will be a little slower than Python 3.2. You say "ten times" slower, but nobody else has been able to confirm this. Others are reporting that, at worst, string handling is twice as slow and sometimes twice as fast, depending on what operations you do, and what operating system you have. (Since creating strings depends on allocating, and moving, blocks of memory, the speed of creating strings is highly dependent on the operating system's memory management.) If all you want to do is complain and whinge and feel morally superior that you are the only one that cares that "Python is slower" (allegedly), please take it to your blog because we don't care. But if you genuinely want to determine whether or not this slowdown is meaningful in practice, and if so help optimise it so that it is faster, then stop with the propaganda about Python destroying Unicode and start writing a test suite. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-26 09:52 -0700 |
| Message-ID | <7xmx0cg204.fsf@ruckus.brouhaha.com> |
| In reply to | #30179 |
Chris Angelico <rosuav@gmail.com> writes: > When you compare against a wide build, semantics of 3.2 and 3.3 are > identical, and then - and ONLY then - can you sanely compare > performance. And 3.3 stacks up much better. I like to have seen real world benchmarks against a pure UTF-8 implementation. That means O(n) access to the n'th character of a string which could theoretically slow some programs down terribly, but I wonder how often that actually matters in ways that can't easily be worked around.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-09-27 03:04 +1000 |
| Message-ID | <mailman.1454.1348679093.27098.python-list@python.org> |
| In reply to | #30227 |
On Thu, Sep 27, 2012 at 2:52 AM, Paul Rubin <no.email@nospam.invalid> wrote: > Chris Angelico <rosuav@gmail.com> writes: >> When you compare against a wide build, semantics of 3.2 and 3.3 are >> identical, and then - and ONLY then - can you sanely compare >> performance. And 3.3 stacks up much better. > > I like to have seen real world benchmarks against a pure UTF-8 > implementation. That means O(n) access to the n'th character of a > string which could theoretically slow some programs down terribly, but I > wonder how often that actually matters in ways that can't easily be > worked around. That's pretty much what we have with the PHP parts of our web site. We've decreed that everything should be UTF-8 byte streams (actually, it took some major campaigning from me to get rid of the underlying thinking that "binary-safe" and "UTF-8" and "characters" and so on were all equivalent), but there are very few places where we actually index strings in PHP. There's a small amount of parsing, but it's all done by splitting on particular strings - if you search for 0x0A in a UTF-8 bytestream and split at that index, it's the same as searching for U+000A in a Unicode string and splitting there - and all of our structural elements fit inside ASCII. The few times we actually care about character length (eg limiting user-specified rule names to N characters), we don't much care about performance, because they're unusual checks. So, I don't actually have any stats for you, because it's really easy to just not index strings at all. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-09-26 10:32 -0700 |
| Message-ID | <7xipb0g05j.fsf@ruckus.brouhaha.com> |
| In reply to | #30228 |
Chris Angelico <rosuav@gmail.com> writes: > So, I don't actually have any stats for you, because it's really easy > to just not index strings at all. Right, that's why I think the O(n) indexing issue of UTF-8 may be overblown. Haskell 98 was mentioned earlier as a language that did Unicode "correctly", but its strings are linked lists of code points. They are a performance pig to be sure but the O(n) indexing is usually not the bottleneck. These days there is a "Text" module that I think is basically UTF-16 arrays. I have been meaning to find out what happens with non-BMP characters.
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 11:35 -0700 |
| Message-ID | <a353bebe-bab8-42e8-8f12-eb02ec11d4cb@googlegroups.com> |
| In reply to | #30227 |
Le mercredi 26 septembre 2012 18:52:44 UTC+2, Paul Rubin a écrit : > Chris Angelico <rosuav@gmail.com> writes: > > > When you compare against a wide build, semantics of 3.2 and 3.3 are > > > identical, and then - and ONLY then - can you sanely compare > > > performance. And 3.3 stacks up much better. > > > > I like to have seen real world benchmarks against a pure UTF-8 > > implementation. That means O(n) access to the n'th character of a > > string which could theoretically slow some programs down terribly, but I > > wonder how often that actually matters in ways that can't easily be > > worked around. The selection of a coding scheme is a problem per se. In Py33 there is a mixin of coding schemes, an artificial construction supposed to be a new coding scheme. As an exercise, pickup characters of each individual coding, toy with them and see what happen. This poor Python has not only the task to handle the bytes of a coding scheme, now it has the task to select the coding scheme it will use with probably plenty of side effects. Completely absurd. I am penalized simply because I add a French character to a French word. A character which does not belong to the same "category" of the characters composing this word. jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2012-09-26 14:21 +0100 |
| Message-ID | <mailman.1429.1348665653.27098.python-list@python.org> |
| In reply to | #30175 |
On 26/09/2012 10:31, wxjmfauth@gmail.com wrote: > > I'm ready to be considered as an idiot, but I'm not blind. People here have seen enough of your writings to know that you're not an idiot. I'm feeling far too polite right now to state what they actually know about you. > As soon as I tested these characters, Py3.3 performs really > badly. It seems to me it is legitimate to consider, there > is a serious problem here. Your tests (for the lack of a better term) have been repeatedly shot to pieces, refuted, you've shown nothing at all to indicate that Python 3.3 performs really badly. > > Many people are commmenting, I have the feeling, I'm the only > one who tested this. It is not necessary to dive in the Python > code, understanding all this "characters stuff" is enough. Complete dross from a person who seems to know as much about the combination of Python 3.3 and unicode as Hitler, Stalin and Pol Pot amongst others knew about human rights. -- Cheers. Mark Lawrence.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2012-09-26 09:53 -0600 |
| Message-ID | <mailman.1446.1348674842.27098.python-list@python.org> |
| In reply to | #30150 |
On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: > >> Py 3.3 succeeded to somehow kill unicode and it has been transformed >> into an "American" product for "American" users. > > For the first time in Python's history, Python on 32-bit systems handles > strings containing Supplementary Multilingual Plane characters correctly, > and it does so without doubling or quadrupling the amount of memory every > single string takes up. Indeed. Here's an interesting article about Unicode handling that identifies Python 3.3 as one of only four programming languages that handle Unicode correctly (the other three being Bash, Haskell 98, and Scheme R6RS). http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 09:18 -0700 |
| Message-ID | <2bebeb46-9e2f-4a21-b089-e692a42b0d85@googlegroups.com> |
| In reply to | #30218 |
Le mercredi 26 septembre 2012 17:54:04 UTC+2, Ian a écrit : > On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano > > <steve+comp.lang.python@pearwood.info> wrote: > > > On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: > > > > > >> Py 3.3 succeeded to somehow kill unicode and it has been transformed > > >> into an "American" product for "American" users. > > > > > > For the first time in Python's history, Python on 32-bit systems handles > > > strings containing Supplementary Multilingual Plane characters correctly, > > > and it does so without doubling or quadrupling the amount of memory every > > > single string takes up. > > > > Indeed. Here's an interesting article about Unicode handling that > > identifies Python 3.3 as one of only four programming languages that > > handle Unicode correctly (the other three being Bash, Haskell 98, and > > Scheme R6RS). > > > > http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/ May I suggest, you dive in the TeX documentation (sometimes, no so easy to find quickly). In my mind much better than all these web pages around. The big plus, you will also understand "characters" as whole. jmf
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 09:18 -0700 |
| Message-ID | <mailman.1452.1348676321.27098.python-list@python.org> |
| In reply to | #30218 |
Le mercredi 26 septembre 2012 17:54:04 UTC+2, Ian a écrit : > On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano > > <steve+comp.lang.python@pearwood.info> wrote: > > > On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: > > > > > >> Py 3.3 succeeded to somehow kill unicode and it has been transformed > > >> into an "American" product for "American" users. > > > > > > For the first time in Python's history, Python on 32-bit systems handles > > > strings containing Supplementary Multilingual Plane characters correctly, > > > and it does so without doubling or quadrupling the amount of memory every > > > single string takes up. > > > > Indeed. Here's an interesting article about Unicode handling that > > identifies Python 3.3 as one of only four programming languages that > > handle Unicode correctly (the other three being Bash, Haskell 98, and > > Scheme R6RS). > > > > http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/ May I suggest, you dive in the TeX documentation (sometimes, no so easy to find quickly). In my mind much better than all these web pages around. The big plus, you will also understand "characters" as whole. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2012-09-26 00:17 -0700 |
| Message-ID | <mailman.1397.1348644367.27098.python-list@python.org> |
| In reply to | #30146 |
wxjmfauth@gmail.com wrote: > Py 3.3 succeeded to somehow kill unicode and it has > been transformed into an "American" product for > "American" users. *plonk*
[toc] | [prev] | [next] | [standalone]
| From | Dwight Hutto <dwightdhutto@gmail.com> |
|---|---|
| Date | 2012-09-26 03:39 -0400 |
| Message-ID | <mailman.1398.1348645161.27098.python-list@python.org> |
| In reply to | #30146 |
On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman <ethan@stoneleaf.us> wrote: > wxjmfauth@gmail.com wrote: >> >> Py 3.3 succeeded to somehow kill unicode and it has >> been transformed into an "American" product for >> "American" users. > > Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-09-26 17:44 +1000 |
| Message-ID | <mailman.1399.1348645497.27098.python-list@python.org> |
| In reply to | #30146 |
On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto <dwightdhutto@gmail.com> wrote: > On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman <ethan@stoneleaf.us> wrote: >> wxjmfauth@gmail.com wrote: >>> >>> Py 3.3 succeeded to somehow kill unicode and it has >>> been transformed into an "American" product for >>> "American" users. >> > Well, we can all use american as a standard, or maybe you'd prefer to > borrow my Latin for Idiots handbook. But then again google has a > Universal Communicator going, so, does it matter? Never in the field of human discussion has there been so much reason for so many to plonk so few. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dwight Hutto <dwightdhutto@gmail.com> |
|---|---|
| Date | 2012-09-26 04:11 -0400 |
| Message-ID | <mailman.1401.1348647094.27098.python-list@python.org> |
| In reply to | #30146 |
>> Well, we can all use american as a standard, or maybe you'd prefer to >> borrow my Latin for Idiots handbook. But then again google has a >> Universal Communicator going, so, does it matter? > > Never in the field of human discussion has there been so much reason > for so many to plonk so few. > "Plonk" it if you want. Your homosexual ideologies have no effect on me. Butt, back to the discussion, there are quite a few ways to encode, as well as translate code. Plonk it in your mouth, and let the nut hairs tickle your throat. > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-09-26 04:13 -0400 |
| Message-ID | <mailman.1402.1348647238.27098.python-list@python.org> |
| In reply to | #30146 |
On 9/26/2012 2:35 AM, wxjmfauth@gmail.com wrote: > Py 3.3 succeeded to somehow kill unicode and it has > been transformed into an "American" product for > "American" users. Python 3.3 is the first version that handles the full unicode character set correctly on all platforms. If anything, it will make unicode more alive and Python better suited for international applications. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2012-09-26 05:19 -0700 |
| Message-ID | <b01dd5a7-23e5-41ae-b770-22ff15e77c28@googlegroups.com> |
| In reply to | #30158 |
Le mercredi 26 septembre 2012 10:13:58 UTC+2, Terry Reedy a écrit : > On 9/26/2012 2:35 AM, wxjmfauth@gmail.com wrote: > > > > > Py 3.3 succeeded to somehow kill unicode and it has > > > been transformed into an "American" product for > > > "American" users. > > > > Python 3.3 is the first version that handles the full unicode character > > set correctly on all platforms. If anything, it will make unicode more > > alive and Python better suited for international applications. > > > > -- > > Terry Jan Reedy Remember the TeX discussion a few days ago? You are always selling the same argument. Py3.3 is the only computer language I'm aware of which is maltreating Unicode in such a way. After all, if replacing a Nabla operator in a string take 10 times more times in Py33 than in Python32, it takes 10 times more . There is nothing more to say. I proposed to make some tests with the characters used by the IMPRIMERIE NATINALE", I can now suggest to make some tests with random texts exceprt form the "Guide du typographe romand". What? Never heard from these? Do not worry too much. The corporates (software producers) and the foundries know these documents. Finally, all in all, it's no a suprise, end users are sticking with these products. I'm not complaining, only disappointed. jmf (Time to go back to TeX)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-09-26 23:43 +1000 |
| Message-ID | <mailman.1434.1348667007.27098.python-list@python.org> |
| In reply to | #30188 |
On Wed, Sep 26, 2012 at 10:19 PM, <wxjmfauth@gmail.com> wrote: > You are always selling the same argument. > Py3.3 is the only computer language I'm aware of which > is maltreating Unicode in such a way. You mean, the only computer language that represents Unicode characters as integers, and then stores them as an array of 8-bit, 16-bit, or 32-bit numbers depending on the highest codepoint? No, it's not. I can disprove your statement with a single counterexample, but it's entirely possible and (IMHO) likely that there are others too: http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/String/width.html Pike stores strings in largely the same way Python 3.3 does. Pike strings are immutable and guaranteed to be interned, so it makes good sense to store them as compactly as possible. > After all, if replacing a Nabla operator in a string take > 10 times more times in Py33 than in Python32, it takes 10 > times more . There is nothing more to say. Comparing against a Py32 wide build, I find it hard to believe that anything would take ten times as long. But I'll give you the benefit of the doubt; maybe your number is in binary. I still do not expect that it'd take twice as long. <voice imitate="Maxwell Smart">Would you believe... barely slower?</voice> And even that's pushing it. sigh... Why am I arguing this. I should get plonked myself for feeding the trolls. Sorry all. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2012-09-26 09:08 -0700 |
| Message-ID | <mailman.1451.1348676175.27098.python-list@python.org> |
| In reply to | #30188 |
Chris Angelico wrote: > On Wed, Sep 26, 2012 at 10:19 PM, <wxjmfauth@gmail.com> wrote: >> After all, if replacing a Nabla operator in a string take >> 10 times more times in Py33 than in Python32 [. . .] > > But I'll give you the benefit > of the doubt; maybe your number is in binary. +1 QOTW
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.python
csiph-web