Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104132 > unrolled thread
| Started by | Tony van der Hoff <tony@vanderhoff.org> |
|---|---|
| First post | 2016-03-06 11:34 +0000 |
| Last post | 2016-03-07 19:02 +0000 |
| Articles | 20 on this page of 142 — 20 participants |
Back to article view | Back to comp.lang.python
Pyhon 2.x or 3.x, which is faster? Tony van der Hoff <tony@vanderhoff.org> - 2016-03-06 11:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-07 01:41 +1100
Re: Pyhon 2.x or 3.x, which is faster? Tony van der Hoff <tony@vanderhoff.org> - 2016-03-07 10:45 +0000
Re: Pyhon 2.x or 3.x, which is faster? Andrew Jaffe <a.h.jaffe@gmail.com> - 2016-03-07 11:54 +0000
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 17:33 -0500
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 11:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-07 13:11 +0200
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 11:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Fabien <fabien.maussion@gmail.com> - 2016-03-07 13:19 +0100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 13:25 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 02:31 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 18:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 06:10 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 20:19 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 07:47 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-07 22:39 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 10:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 00:22 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 00:43 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 11:45 +1100
Re: Pyhon 2.x or 3.x, which is faster? MRAB <python@mrabarnett.plus.com> - 2016-03-08 00:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-07 20:29 -0500
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 22:51 -0500
Re: Pyhon 2.x or 3.x, which is faster? Michael Torrie <torriem@gmail.com> - 2016-03-08 17:34 -0700
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 13:01 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-09 11:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 11:05 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:00 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 01:12 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 02:45 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 16:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 19:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 20:44 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 22:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 10:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 08:40 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 12:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 21:13 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 23:14 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-09 23:35 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 00:58 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 12:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 07:30 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 11:50 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 12:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 12:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 00:08 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 14:22 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 19:26 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-11 16:29 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-11 18:57 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-11 21:59 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-11 22:24 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-12 16:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? alister <alister.ware@ntlworld.com> - 2016-03-12 10:06 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-12 10:31 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 10:51 +0000
Re: Pyhon 2.x or 3.x, which is faster? alister <alister.ware@ntlworld.com> - 2016-03-12 15:36 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-13 14:22 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-12 10:34 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-12 21:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 07:07 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-11 16:06 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 16:36 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 13:18 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-11 00:30 +1100
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-10 13:46 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 18:43 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 18:55 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 12:59 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 12:19 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 10:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 23:48 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 11:03 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-10 02:38 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 14:43 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 01:30 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 13:29 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-10 14:32 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 13:45 +1100
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-10 11:21 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:23 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:33 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 12:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 02:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 13:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? MRAB <python@mrabarnett.plus.com> - 2016-03-08 02:47 +0000
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-08 13:45 +0200
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 12:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-07 22:39 -0500
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 03:48 +0000
What will I get when reading from a file? (was: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-08 11:09 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 13:12 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 11:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 10:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 00:09 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-09 11:36 +1100
Re: Pyhon 2.x or 3.x, which is faster? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-08 21:03 -0500
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 03:07 +1100
Re: Pyhon 2.x or 3.x, which is faster? Serhiy Storchaka <storchaka@gmail.com> - 2016-03-08 14:48 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 12:34 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-08 12:49 +1100
Re: Pyhon 2.x or 3.x, which is faster? Serhiy Storchaka <storchaka@gmail.com> - 2016-03-08 15:05 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-08 12:19 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 01:41 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-08 15:40 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 13:49 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 16:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-08 09:23 -0800
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-08 19:02 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 11:04 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 01:28 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 13:18 +1100
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-09 02:11 -0800
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 14:03 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 01:11 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 14:39 +0000
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 01:54 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:33 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 02:58 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 14:56 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:28 +1100
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 01:57 +1100
Re: Pyhon 2.x or 3.x, which is faster? Chris Angelico <rosuav@gmail.com> - 2016-03-10 02:04 +1100
Re: Pyhon 2.x or 3.x, which is faster? BartC <bc@freeuk.com> - 2016-03-09 16:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 01:54 +1100
Re: Pyhon 2.x or 3.x, which is faster? Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-09 15:06 +0000
Re: Pyhon 2.x or 3.x, which is faster? Tim Golden <mail@timgolden.me.uk> - 2016-03-09 15:15 +0000
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 02:38 +1100
Re: Pyhon 2.x or 3.x, which is faster? Terry Reedy <tjreedy@udel.edu> - 2016-03-09 10:42 -0500
Re: Pyhon 2.x or 3.x, which is faster? wxjmfauth@gmail.com - 2016-03-09 09:04 -0800
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-09 08:08 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-09 22:52 +1100
Re: Pyhon 2.x or 3.x, which is faster? Marko Rauhamaa <marko@pacujo.net> - 2016-03-09 14:53 +0200
Re: Pyhon 2.x or 3.x, which is faster? Steven D'Aprano <steve@pearwood.info> - 2016-03-10 03:53 +1100
Re: Pyhon 2.x or 3.x, which is faster? Michael Torrie <torriem@gmail.com> - 2016-03-08 17:42 -0700
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-08 02:53 +0000
Re: Pyhon 2.x or 3.x, which is faster? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-07 19:02 +0000
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-13 14:22 +1100 |
| Message-ID | <56e4dd04$0$1583$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104711 |
On Sun, 13 Mar 2016 02:36 am, alister wrote about building up strings by repeated concatenation: > So you are bench marking python performance on a programming paradigm > that is not good python practice. > > A pointless exercise > what may be the best way to achieve a rsult in one language is not > necessarily the best way to achieve it in another. "Pointless"? I don't think so. The whole *point* is see how a straightforward and simple idiom compares between one implementation (or language) and another. There's nothing wrong with that, unless you think that the only code you should benchmark is code you think will be fast. If your aim is to *hide the fact* that vanilla Python performs poorly on repeated concatenation, then by all means this benchmark is a bad benchmark. You might also decide that it's a "bad" benchmark if you simply don't care about the results. But why would you do that? Repeated string concatenation is not only legal python code, but CPython actually includes special code to optimize that case. Using CPython 2.7 on Linux, contrast the time taken bythe optimized concatenation example: py> with Stopwatch(): ... s = '' ... for i in range(10**6): ... s = s + '%' ... time taken: 0.361933 seconds with an unoptimized variation in all it's quadratic horror: py> with Stopwatch(): ... s = '' ... for i in range(10**6): ... s = '%' + s ... time taken: 1075.427070 seconds (Source for Stopwatch available on request.) Somebody took the time and effort to optimize the first case, and you think it is "pointless" to see if it actually works? I disagree. What we conclude from the results of the benchmark is a separate issue from the results themselves. We might legitimate conclude "well don't write your code like that". We might conclude "this is a problem that needs fixing". We might punt, as indeed the Python core developers have done for this specific one, and decided that the language Python need not make any performance guarantees about repeated string concatenation, but implementations are allowed to optimize it or not, as they prefer. The speed of repeated string concatenation is a *quality of implementation* issue. Exactly the sort of thing which, arguable, ought to be benchmarked. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 10:34 +0000 |
| Message-ID | <nc0r6l$te6$1@dont-email.me> |
| In reply to | #104654 |
On 12/03/2016 01:15, Michael Torrie wrote: > On 03/11/2016 03:24 PM, BartC wrote: >> On 11/03/2016 21:59, Mark Lawrence wrote: >>> On 11/03/2016 18:57, BartC wrote: >> >>> def test(): >>> s="" >>> for i in range(10000000): >>> s+="*" >>> print (len(s)) >>> >>> test() >> >>> The minor snag that you might like to correct with your microbenchmark, >>> which any experienced Python programmer knows, is that you *NEVER, EVER* >>> create strings like this. >> >> Why not? Chris said his version runs much faster (even allowing for >> different machines), and might have a special optimisation for it. >> >> And I think it can be optimised if, for example, there are no other >> references to the string that s refers to. >> >> So what's wrong with trying to fix it rather that using a workaround? > > The act of "fixing" it, as you say, would change the semantics of the > language in a fundamental and major way. Strings by definition are > immutable in Python. Yet INPLACE_ADD is a valid byte-code even when operating on strings. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-12 21:40 +1100 |
| Message-ID | <mailman.32.1457779256.12893.python-list@python.org> |
| In reply to | #104687 |
On Sat, Mar 12, 2016 at 9:34 PM, BartC <bc@freeuk.com> wrote: >> The act of "fixing" it, as you say, would change the semantics of the >> language in a fundamental and major way. Strings by definition are >> immutable in Python. > > > Yet INPLACE_ADD is a valid byte-code even when operating on strings. That's because INPLACE_ADD is a valid byte-code regardless of what it's working on. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-11 07:07 +1100 |
| Message-ID | <mailman.153.1457640433.15725.python-list@python.org> |
| In reply to | #104524 |
On Fri, Mar 11, 2016 at 1:22 AM, BartC <bc@freeuk.com> wrote: >> >> 1) Unicode support, intrinsic to the language, is crucial, even if >> BartC refuses to recognize this. Anything released beyond the confines >> of his personal workspace will need full Unicode support, otherwise it >> is a problem to the rest of the world, and should be destroyed with >> fire. Thanks. > > > I don't agree. If I distribute some text in the form of a series of ASCII > byte values (eg. classic TXT format, with either kind of line separator), > then that same data can be directly interpreted as UTF-8. What you call "classic TXT format" is still an encoding, which means you're acknowledging the difference between characters and bytes - that's the first step. But you have to be certain that you are interpreting it as UTF-8, in which case ASCII ceases to be significant, and what you've done is declare that your file consists of a stream of UTF-8-encoded Unicode characters, divided into lines with either U+000D U+000A or just U+000A. That's a nice clear encoding definition. And the difference between characters and bytes is only the first step (albeit the biggest and most important step). You _need_ to make sure that you're thinking about text as text, and that means being aware of RTL vs LTR, combining characters, case conversions, collations, etc, etc, etc, all in terms of Unicode rather than as eight-bit or seven-bit characters. (For example, a naïve MUD client might assume that one byte is one character is 8 pixels of width. I know this, because some years ago I wrote one exactly like that (well, the figure "8" came from measuring the current font, but other than at font changes, it was fixed). An intelligent Unicode-aware MUD client has to not only cope with variable width, but also characters that don't have any width at all, and those that use the same space as their base character, and those that are placed to the left of the preceding character.) You can't ignore this, although you might be able to leave full support for later - but it's a bug until you do. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-11 16:06 +1100 |
| Message-ID | <56e25245$0$1606$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104549 |
On Fri, 11 Mar 2016 07:07 am, Chris Angelico wrote: > You _need_ [emphasis in original] to make sure > that you're thinking about text as text, and that means being aware of > RTL vs LTR, combining characters, case conversions, collations, etc, > etc, etc, all in terms of Unicode rather than as eight-bit or > seven-bit characters. And I thought that I was a Unicode-evangelist... You don't "need" to do anything of the sort, any more than (say) Firefox needs to support displaying Scitex CT image files. If you want to put people off Unicode and make them even more resistant, the idea that there is no middle ground between "naive ASCII" and full, complete, total and utterly 100% coverage of the entire Unicode standard will do it nicely. Unicode covers a huge amount of ground, and most users won't need more than a fraction of it. Especially people like Bart, who are writing code for his own personal use. If Bart gets to the point of being able to correctly read and write his mostly ASCII text as UTF-8 files without moji-bake, that's probably more than he'll personally ever need. Or not. Only he will tell. > An intelligent Unicode-aware MUD client has to > not only cope with variable width That may be true, but that doesn't mean that there isn't still room in the world for dumb, just-barely Unicode capable clients. And frankly I would rather partial Unicode support than buggy Unicode support: I have a text editor which would be my preferred editor of choice except it has an annoying bug where it will (seemingly at random) switch to Right-To-Left mode for no reason, and then be impossible to switch back. Since I have *no* use for RTL, I would rather an editor that doesn't support that than one that supports it buggily. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-11 16:36 +1100 |
| Message-ID | <mailman.171.1457674574.15725.python-list@python.org> |
| In reply to | #104582 |
On Fri, Mar 11, 2016 at 4:06 PM, Steven D'Aprano <steve@pearwood.info> wrote: > That may be true, but that doesn't mean that there isn't still room in the > world for dumb, just-barely Unicode capable clients. And frankly I would > rather partial Unicode support than buggy Unicode support: I have a text > editor which would be my preferred editor of choice except it has an > annoying bug where it will (seemingly at random) switch to Right-To-Left > mode for no reason, and then be impossible to switch back. Since I have > *no* use for RTL, I would rather an editor that doesn't support that than > one that supports it buggily. What would this hypothetical "doesn't support RTL" editor do if given Arabic or Hebrew text? I'd rather it support it buggily (and acknowledge that those are bugs) than try to render the characters in a completely wrong way. Also, you trimmed off the last bit of my original post, which probably should have had more emphasis: [I said:] > You can't ignore this, although you might be able to leave > full support for later - but it's a bug until you do. You don't necessarily have to have perfect support for everything straight away; what you DO need is a mental attitude of "perfection means full Unicode support, and anything else is a bug". Bugs hang around in programs for a long time, but removing them is always an improvement. So, for instance, you might not properly support RTL text, but if a patch comes along that fixes RTL text, you would not dismiss it as "we've done it this way for years, so it's fine" - it's a bug that can be fixed. Same goes for correct handling of combining characters (the cursor shouldn't be able to go between a base char and a combining char, for instance); if you get something wrong, it's a bug, same as any other bug. There most definitely is room in the world for "just-barely Unicode capable" programs, just as there's room in the world for programs that segfault when you feed them certain types of invalid data. The program can still be useful even though it has bugs in it. Nobody would deny that segfaulting on invalid data is a flaw; and imperfect Unicode support should be treated the same way. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-10 13:18 +0000 |
| Message-ID | <mailman.128.1457615949.15725.python-list@python.org> |
| In reply to | #104509 |
On 10/03/2016 12:47, BartC wrote: > On 10/03/2016 12:15, Mark Lawrence wrote: >> On 10/03/2016 11:50, BartC wrote: > >>> Suppose you were on the development team that writes the optimising >>> stages of a C compiler. You need to test the performance of the code it >>> produces so that you can compare one optimisation with another. Would >>> you: >>> >>> (a) Test only the code that is generated by your compiler >>> >>> (b) Include also the runtime of third-party libraries consisting of >>> unknown code, written in an unknown language, with an unknown compiler >>> and with unknown optimisation settings? >> >> What has an optimising C compiler got to do with the run time speed of >> Python, which in many cases is perfectly adequate? > >> I'll repeat for >> possibly the fourth time, the vast majority of people > > The vast majority aren't implementing the language! No, they are complete weirdos called USERS. Have you ever met any? > >> have no interest >> in run time speed as they are fully aware that they'll be wasting their >> precious development time, as they know that their code will be waiting >> on the file, the database or the network. What have you failed to grasp >> about that? > > Tell that to the people who have been working on optimising compilers > for the last couple of decades. Why bother making that inner loop 10% > faster, when the program will most likely be blocked waiting for input > anyway? > > You just don't get it. At last you manage to get something correct, I do not get your obsession with run time speed. For the fifth time, the vast majority of users simply do not care. If it is fast enough, job done. I have dealt with some complete dumbos in the years that I've been online, but when it comes to thickos you're right up there with the RUE, and I can assure you that this is meant to be an insult. To your way of thinking run time speed is the sole issue with programming, and trivial details like accuracy are irrelevant. "Look, Python has taken a whole minute to process this data, but BartC has done it in one nanosecond". "Yes, but Python is 100% accurate, BartC is 100% inaccurate". "Who cares, only speed counts". -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-11 00:30 +1100 |
| Message-ID | <mailman.130.1457616633.15725.python-list@python.org> |
| In reply to | #104509 |
On Fri, Mar 11, 2016 at 12:18 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: > I have dealt with some complete dumbos in the years that I've been online, > but when it comes to thickos you're right up there with the RUE, and I can > assure you that this is meant to be an insult. > > To your way of thinking run time speed is the sole issue with programming, > and trivial details like accuracy are irrelevant. "Look, Python has taken a > whole minute to process this data, but BartC has done it in one nanosecond". > "Yes, but Python is 100% accurate, BartC is 100% inaccurate". "Who cares, > only speed counts". Mark, you don't need to be this vitriolic. It's possible to disagree with Bart without being a complete <censored> yourself. Please, have a read of my previous post, and give yourself a moment to cool down. At no time has Bart ever said that accuracy is unimportant; at worst, he's sacrificing dynamism, maybe maintainability, but not accuracy. A little calmness, please. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-10 13:46 +0000 |
| Message-ID | <mailman.133.1457617654.15725.python-list@python.org> |
| In reply to | #104509 |
On 10/03/2016 13:08, Chris Angelico wrote: > > When people want better performance out of a number-crunching Python > program, they have a few options. One is to rewrite their code in C or > Fortran or something. Another is to make small tweaks so the bulk of > the work is handled by numpy or Cython. A third is to keep their code > completely unchanged, but run it under PyPy instead of whatever they > were previously using (probably CPython). Generally, rewriting in > C/Fortran is generally a bad idea; you pay the price over the whole > application, when optimizing a small subset of it would give 99% of > the performance improvement. That's why actual CPython byte-code > interpretation performance isn't so critical; if we can change 5% of > the code so it uses numpy, we keep 95% of it in idiomatic Python, > while still having the bulk of the work done in Fortran. CPython has > other priorities than performance - not to say that "slow is fine", > but more that "slow and dynamic opens up possibilities that fast and > static precludes, so we're happy to pay the price for the features we > want". > > ChrisA > This should be the first option https://wiki.python.org/moin/PythonSpeed/PerformanceTips -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-10 18:43 +1100 |
| Message-ID | <mailman.110.1457595810.15725.python-list@python.org> |
| In reply to | #104461 |
Mark Lawrence <breamoreboy@yahoo.co.uk> writes: > Yes I am, as you appear to know squat. Cut it out, please. This is now bullying. Bart is interested in things that don't interest you; if you can't engage him cordially, please desist. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but what kind of rides do they have in Fabioland?” | _o__) —_Pinky and The Brain_ | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 18:55 +1100 |
| Message-ID | <mailman.111.1457596555.15725.python-list@python.org> |
| In reply to | #104461 |
On Thu, Mar 10, 2016 at 6:30 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: >> From what I've seen, a lot of software can't get [Unicode] right anyway. >> > > Are you referring to PEP393 having taken notice of the RUE? Even with PEP 393, there's no guarantee that a Python program will get Unicode right. The bytes/text split in Python 3 is a huge help, but proper handling of the entire Unicode range implies more than simply being able to represent all characters (although that's a critical prerequisite). There are design considerations with case folding (tip: it's easiest and safest to be case sensitive), collation/sorting (tip: it's impossible to be perfect unless you know which language is involved), text directionality (you probably know that Arabic is written right-to-left, but are you aware that there are also characters with "weak" directionality, distinct from those with "neutral" directionality?) and so on, plus a bunch of relatively straight-forward coding considerations (eg comparing two strings for equality generally requires NFC/NFC normalization, and might require NFKC/NFKD), which a number of programs still don't get right. PEP 393 actually isn't very much about correctness; a "wide build" of pre-3.3 Python has the correct behaviour, but is wasteful with memory. By removing the temptation to conserve memory using UTF-16, PEP 393 did improve correctness on Windows, but its main focus is on memory efficiency (and thus performance, thanks to cache locality). But hey. Just being able to represent all characters is probably about 95% of Unicode correctness. The rest is the little stuff. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-10 12:59 +1100 |
| Message-ID | <56e0d515$0$1615$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104456 |
On Thu, 10 Mar 2016 10:35 am, Mark Lawrence wrote: > On 09/03/2016 23:14, BartC wrote: >> (The byte-code compiler for the current version is written in itself. It >> can compile itself (some 25Kloc) in about 1 second (that's running >> interpreted, dynamic byte-code on a not-very-fast PC). > > Please answer my question, will it be tested against real world > benchmarks or microbenchmarks? The above paragraph, and several > following paragraphs, are completely irrelevant. Mark, Bart's answer is a very good answer. He has written a self-hosting interpreter and compiler. That is a good (although not perfect) "real world benchmark". I get it that you're keen to jump into the fray and defend the honour of Python, but Python doesn't need to be defended from Bart. He's just one guy, he's retired, and he has an interesting little language as a hobby. What's the threat? Don't go all Ranting Rick on us and think that the entire computing community is going to abandon Python for Bart's private and unpublished language. I've said it before, and I'll say it again: I think that Bart's language sounds interesting. I'm not sure exactly where it would sit in the computing ecosystem, but if it works for him, good for him. >> The interpreter for the byte-code is also written in another language of >> mine, which statically typed. The compiler for the latter is written in >> the interpreted language too. >> >> I'd quite like to port either of these compilers to Python, to see what >> PyPy can do with them. (It would also be quite cool to have them in pure >> Python). But I've find these difficult to optimise, because they have >> diverse execution patterns, while PyPy likes loops. I'll see. >> >> A compiler is another good 'pure language' task because, apart from >> input and output at each end, all the computation is self-contained.) > > I've no idea what this is meant to mean. Then you shouldn't criticise Bart for his lack of "knowledge of computing" just because he lacks of interest in Unicode. As they say, people in glass houses shouldn't throw stones. I think Bart is very old-school, and probably a bit behind the times when it comes to modern compiler and interpreter technologies. But that doesn't matter: the old timers knew a thing or two, and in some ways the old days were better: http://prog21.dadgum.com/116.html I fear that Bart still holds quite a few misapprehensions about Python. But he seems happy to discuss the language, and (unless he is lying to us and all his claims about his interpreter are pure Walter Mitty fantasy -- and I have no reason to think this is true), there's no doubt that he is knows what he is talking about in the areas of which he is qualified to speak. Does he know Unicode? No. Does he know compiler design? It seems so, which is more than can be said by either you or I. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 12:19 +0000 |
| Message-ID | <nbroiv$8nv$1@dont-email.me> |
| In reply to | #104465 |
On 10/03/2016 01:59, Steven D'Aprano wrote: > I think Bart is very old-school, and probably a bit behind the times when it > comes to modern compiler and interpreter technologies. That's true. I've reached a dead-end with what I can do with interpreted, dynamically typed byte-code, but it stills holds its own compared with other non-accelerated scripting languages, even PyPy sometimes. (Although other JIT projects I think are faster than PyPy, eg. LuaJIT. Very compact too.) (I could also go the JIT route, but it's very complicated and not much fun! And once you start generating custom native code, then you're competing with proper compilers.) But that doesn't > matter: the old timers knew a thing or two, and in some ways the old days > were better: > > http://prog21.dadgum.com/116.html > > > I fear that Bart still holds quite a few misapprehensions about Python. But > he seems happy to discuss the language I have an interest in C and in Python because those are probably the two languages I'd be using now, if I hadn't been spoilt by having to create my own versions in the 1980s. I've watched Python's development with interest because there were some parallels with the script language I was using for my applications (I decided my language needed byte-arrays bolted on; Python also added byte-arrays!) Python however decided to be far more dynamic. (Making efficient interpreters a bit harder to write.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 10:38 +1100 |
| Message-ID | <mailman.99.1457566720.15725.python-list@python.org> |
| In reply to | #104455 |
On Thu, Mar 10, 2016 at 10:14 AM, BartC <bc@freeuk.com> wrote: > On 09/03/2016 21:13, Mark Lawrence wrote: >> >> On 09/03/2016 12:02, BartC wrote: >>> >>> On 09/03/2016 08:40, Mark Lawrence wrote: >>> >>> Here's another: you have a program in Python that you'd quite like to >>> port to another dynamic language. Transcribing actual Python code is >>> straightforward. Until you come to an import of a module that you can't >>> find, because it's not written in Python. Now what? Now, you might >>> appreciate the advantage of a program in 100% pure Python. >>> >> >> That is not Python's problem, or my problem, that is your problem. > > > Maybe that's not the best example of why someone might prefer a 'Python' > program to be actually written in Python. Sometimes you want to understand > how code works or what it does or simply to learn from it. (Or sometimes, to > rip bits off.) Then it's frustrating when you come up against a dead-end so > quickly. Because the real meat isn't in Python at all. What *is* the real meat of a program? Every action is defined in terms of smaller actions - a Python program is built out of Python primitives and function calls, a C program is built out of C primitives and function calls, an 80x86 machine code program is built out of 80x86 CPU instructions and calls to other code. Does my MUD server need to have its own memory allocation code? No. Does it need an algorithm for adding two integers together? Certainly not! And nor does it need PNG encoding and decoding algorithms; I simply call on Image.PNG.encode() and Image.PNG.decode() to do the work, passing images around in my code as first-class objects. Does it detract from my code? Not in the least. My code treats "load an image from a PNG file" as a fundamental operation, and gets on with doing its stuff. Reinventing the wheel does NOT intrinsically make your code better. Unless there's something you're doing that's fundamentally different from what's already available (maybe a database client that uses non-blocking sockets with async/await), it's usually better to use what someone else has written. I'd much rather use a one-liner that reads an image from the disk than wade through your pages and pages of bitshift operations in Python (especially as it's all uncommented - how can I know if it's even correct, other than by finding a reference algorithm written in C?). >> Python 2.8 or RickedPython? Will the unicode handling be better than >> that of the dread Python 3.3+, PEP393 Flexible String Representation > as >> repeatedly pointed out by the RUE? > > I'm not much interested in Unicode at the minute. I'll pass. Then *get interested*. Unicode is the only way that you'll ever not be parochially bound to a subset of English - or, worse, bound to an arbitrary eight-bit codepage that you don't even control the choice of, such that your program behaves differently on different systems. FIX YOUR LANGUAGE and support non-English text. Integers, floating point numbers, lists, and images all need encodings; so does text. It's an abstract data type, just as the others are. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-03-09 23:48 +0000 |
| Message-ID | <slrnne1dnt.19u.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #104457 |
On 2016-03-09, Chris Angelico <rosuav@gmail.com> wrote: > Then *get interested*. Unicode is the only way that you'll ever not be > parochially bound to a subset of English - or, worse, bound to an > arbitrary eight-bit codepage that you don't even control the choice > of, such that your program behaves differently on different systems. > FIX YOUR LANGUAGE and support non-English text. You can't even support English text properly without Unicode. Plenty of English words use non-ASCII characters: café, crêpe, façade, naïve, dæmon, etc.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 11:03 +1100 |
| Message-ID | <mailman.100.1457568220.15725.python-list@python.org> |
| In reply to | #104458 |
On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote: > On 2016-03-09, Chris Angelico <rosuav@gmail.com> wrote: >> Then *get interested*. Unicode is the only way that you'll ever not be >> parochially bound to a subset of English - or, worse, bound to an >> arbitrary eight-bit codepage that you don't even control the choice >> of, such that your program behaves differently on different systems. >> FIX YOUR LANGUAGE and support non-English text. > > You can't even support English text properly without Unicode. > Plenty of English words use non-ASCII characters: > café, crêpe, façade, naïve, dæmon, etc. Like I said, a subset of English. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-03-10 02:38 +0000 |
| Message-ID | <slrnne1nmg.19u.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #104459 |
On 2016-03-10, Chris Angelico <rosuav@gmail.com> wrote: > On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens ><jon+usenet@unequivocal.co.uk> wrote: >> On 2016-03-09, Chris Angelico <rosuav@gmail.com> wrote: >>> Then *get interested*. Unicode is the only way that you'll ever not be >>> parochially bound to a subset of English - or, worse, bound to an >>> arbitrary eight-bit codepage that you don't even control the choice >>> of, such that your program behaves differently on different systems. >>> FIX YOUR LANGUAGE and support non-English text. >> >> You can't even support English text properly without Unicode. >> Plenty of English words use non-ASCII characters: >> café, crêpe, façade, naïve, dæmon, etc. > > Like I said, a subset of English. I profusely apologise for so rudely agreeing with you.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 14:43 +1100 |
| Message-ID | <mailman.104.1457581415.15725.python-list@python.org> |
| In reply to | #104467 |
On Thu, Mar 10, 2016 at 1:38 PM, Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote: > On 2016-03-10, Chris Angelico <rosuav@gmail.com> wrote: >> On Thu, Mar 10, 2016 at 10:48 AM, Jon Ribbens >><jon+usenet@unequivocal.co.uk> wrote: >>> On 2016-03-09, Chris Angelico <rosuav@gmail.com> wrote: >>>> Then *get interested*. Unicode is the only way that you'll ever not be >>>> parochially bound to a subset of English - or, worse, bound to an >>>> arbitrary eight-bit codepage that you don't even control the choice >>>> of, such that your program behaves differently on different systems. >>>> FIX YOUR LANGUAGE and support non-English text. >>> >>> You can't even support English text properly without Unicode. >>> Plenty of English words use non-ASCII characters: >>> café, crêpe, façade, naïve, dæmon, etc. >> >> Like I said, a subset of English. > > I profusely apologise for so rudely agreeing with you. I snapped off a very quick response as I was about to meet with a student, but let me assure you that I was not offended in any way by your post. You basically gave examples of exactly the problem that I alluded to with the words "a subset of", and it's an important enough consideration that it's well worth having the examples there. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 01:30 +0000 |
| Message-ID | <nbqii7$rh4$1@dont-email.me> |
| In reply to | #104457 |
On 09/03/2016 23:38, Chris Angelico wrote: > On Thu, Mar 10, 2016 at 10:14 AM, BartC <bc@freeuk.com> wrote: >> program to be actually written in Python. Sometimes you want to understand >> how code works or what it does or simply to learn from it. (Or sometimes, to >> rip bits off.) Then it's frustrating when you come up against a dead-end so >> quickly. Because the real meat isn't in Python at all. > > What *is* the real meat of a program? Every action is defined in terms > of smaller actions - a Python program is built out of Python > primitives and function calls, a C program is built out of C > primitives and function calls, an 80x86 machine code program is built > out of 80x86 CPU instructions and calls to other code. Does my MUD > server need to have its own memory allocation code? No. Does it need > an algorithm for adding two integers together? Certainly not! And nor > does it need PNG encoding and decoding algorithms; I simply call on > Image.PNG.encode() and Image.PNG.decode() to do the work, passing > images around in my code as first-class objects. Does it detract from > my code? Not in the least. My code treats "load an image from a PNG > file" as a fundamental operation, and gets on with doing its stuff. Yes we understand how libraries can be useful. But, someone had to write that Image.PNG.encode() function at some time. What language did they use? If it wasn't Python, then why not? Why is it OK to let some poor sod slave away in C++ or whatever (a ghastly language), while others then reap the benefits writing in an easy 'soft' language? I've been interested for a while in broadening the scope of scripting languages so that less work has to be done in 'hard' ones. (Although I admit that taking over imaging functions is probably not going to be viable, except perhaps for rather small images.) It seems other have the same idea with the advent of fast JIT systems. But the attitude in this group has been very different; Python /is/ slow, but so what? Just a general shrug. So long as /someone else/ uses the hard language to created the needed libraries, the speed of pure Python is irrelevant. New version of Python is now half the speed? Another shrug! > Reinventing the wheel does NOT intrinsically make your code better. But you might end up with a small, manageable wheel that does just what you want instead of the same 100' monster than everything else is using! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-10 13:29 +1100 |
| Message-ID | <mailman.103.1457577015.15725.python-list@python.org> |
| In reply to | #104464 |
BartC <bc@freeuk.com> writes: > But, someone had to write that Image.PNG.encode() function at some > time. What language did they use? If it wasn't Python, then why not? Because some operations actually need to be very fast, even at the expense of difficult-to-maintain code in a difficult-to-use language. > Why is it OK to let some poor sod slave away in C++ or whatever (a > ghastly language), while others then reap the benefits writing in an > easy 'soft' language? Because that's the whole point of writing a small re-usable library and maintaining it: countless gobs of badly-written imitations thereby never need to be written. > I've been interested for a while in broadening the scope of scripting > languages so that less work has to be done in 'hard' ones. Yes, that's pretty much the answer to the question you asked above. > But the attitude in this group has been very different; Python /is/ > slow, but so what? Just a general shrug. I'm sorry you drew that inference. Comprehensive answers – not a “general shrug” – have in fact been given to you. The answer boils down to the fact that there are trade-offs to be made. One that is easy to express is that Python trades preserving valuable programmer time, at the expense of some non-critical operations being slightly slower. And no, of course it's not “Python is slow”. Such a broad statement is erxactly what gets mocking scorn in response: you need to be *much* more specific about what is slow, under what conditions. Python is plenty fast enough at most of the things it is used for. > So long as /someone else/ uses the hard language to created the needed > libraries, the speed of pure Python is irrelevant. New version of > Python is now half the speed? Another shrug! Citation needed. I don't know of any released version of Python that was ever “twice as slow” – no qualifiers – than the previous release. Make such sweeping, hand-waving statements that are trivially demonstrated false, and yes your statements will be dismissed. With sneers by some, and with a shrug by most. -- \ “It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__) will play itself.” —Johann Sebastian Bach | Ben Finney
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web