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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-10 14:32 +0000 |
| Message-ID | <nbs0bl$7q1$1@dont-email.me> |
| In reply to | #104466 |
On 10/03/2016 02:29, Ben Finney wrote: > BartC <bc@freeuk.com> writes: >> 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. That was an exaggeration. Yet there was some basis in fact: elsewhere in the thread, I gave an example of a two-line loop that took 2.1 times as long to execute in Py3.4.3 as on Py2.7.11. With some intervening versions, but a 2.7.11 user upgrading direct to 3.4.3 could be in for a shock, if he's into running pointless loops! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-10 13:45 +1100 |
| Message-ID | <56e0dfaf$0$22141$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104464 |
On Thu, 10 Mar 2016 12:30 pm, BartC wrote: > But the attitude in this group has been very different; Python is > slow, but so what? Just a general shrug. I think that sometimes people here get a bit defensive because they've experienced too many people making snap dismissals of Python due to some completely artificial benchmark that doesn't relate to the work that their actually doing. These are the people who would rather spend two weeks writing a buggy C program to do a one-off processing task that takes 10 minutes to run that we could do correctly in half a day in Python because their code is "100 times faster". You might think I'm exaggerating, but I've seen people do that. Anyway, the Python community as a whole is *very* aware that Python is not the speediest language in the world (although it is faster than Ruby, faster than at least some Javascript implementations, and neither of those two are suffering in popularity due to slowness). Speed is not the number 1 priority, and possibly not even the number 2 priority, but it is a priority somewhere in the top 10. Hence there is a whole range of performance-related factors to be considered: - speed.python.org allows the core developers (and anyone else) to monitor Python's performance; - PyPy is a self-hosted[1] powerful Just-In-Time compiler aimed especially at long-running code in loops; - the author of Nuitka is re-writing Python in C++ with the eventual aim of making it a highly-optimized Ahead-Of-Time compiler; - one of the core devs, Victor Stinner, is working on FAT Python, an optimizing implementation; - other projects include Pyston, Pyjion, HotPy, Cython, Numba, Parakeet. Some discussion here: https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en So don't think that the community as a whole is dismissive of speed issues. But they're more interested in speeding up Python where it matters. [1] Well, sort of. PyPy is actually written in RPython, a restricted subset of Python. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-10 11:21 +1100 |
| Message-ID | <mailman.101.1457569335.15725.python-list@python.org> |
| In reply to | #104455 |
Chris Angelico <rosuav@gmail.com> writes: > On Thu, Mar 10, 2016 at 10:14 AM, BartC <bc@freeuk.com> wrote: > > 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. Yes. Any program (and therefore, any programmer) that deals with text in any way today needs to be Unicode-aware. This is true whether or not you care about diverse languages. It's no longer the case that ASCII is enough *even if you arbitrarily limit your program to English text*. English text uses non-ASCII characters all the time. Proper punctuation (e.g. quotation, dashes). Proper spacing (e.g. thin space, no-break space). Currency symbols (e.g. the Yuan, the Euro, the pound). Official symbols (e.g. copyright, trademark, degree, section). If your program fails to preserve these and many other non-ASCII characters, fails to treat them like any other text, your program does not handle English-language text. Many names – of people and places and organisations – cannot be spelled correctly, even in English, without using non-ASCII characters. Text was never the same as bytes. Programs hobbled along in the 20th century making that false assumption, and the problems led to the creation of Unicode. Your program will read and write bytes in byte streams (such as files). They will not write text directly. The only sense in which you can say that you get text from a file is if you know the text encoding of the bytes. This is just a brute fact. You can't have text being anywhere near bytes, without knowing the text encoding. Guessing is not good enough in the third millennium. -- \ “[…] we don’t understand what we mean when we say that [God] is | `\ ‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case | _o__) For God_, 2009 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 12:23 +1100 |
| Message-ID | <mailman.18.1457400239.15725.python-list@python.org> |
| In reply to | #104289 |
On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote: > Yes of course it does. As does 'being slow'. Take another microbenchmark: > > def whiletest(): > | i=0 > | while i<=100000000: > | | i+=1 > > whiletest() > > Python 2.7: 8.4 seconds > Python 3.1: 12.5 seconds > Python 3.4: 18.0 seconds > > Even if you don't care about speed, you must admit that there appears to be > something peculiar going on here: why would 3.4 take more than twice as long > as 2.7? What do they keep doing to 3.x to cripple it on each new version? How do your benchmarks compare on this code: pass ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 01:33 +0000 |
| Message-ID | <nbl9vp$mhm$1@dont-email.me> |
| In reply to | #104295 |
On 08/03/2016 01:23, Chris Angelico wrote: > On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote: >> Yes of course it does. As does 'being slow'. Take another microbenchmark: >> >> def whiletest(): >> | i=0 >> | while i<=100000000: >> | | i+=1 >> >> whiletest() >> >> Python 2.7: 8.4 seconds >> Python 3.1: 12.5 seconds >> Python 3.4: 18.0 seconds >> >> Even if you don't care about speed, you must admit that there appears to be >> something peculiar going on here: why would 3.4 take more than twice as long >> as 2.7? What do they keep doing to 3.x to cripple it on each new version? > > How do your benchmarks compare on this code: > > pass Let me ask you a follow-on question first: how slow does a new Python version have to be before even you would take notice? Compared with 2.7, 3.4 above is spending nearly an extra ten seconds doing .... what? I can't understand why someone just wouldn't care. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-08 12:38 +1100 |
| Message-ID | <mailman.20.1457401118.15725.python-list@python.org> |
| In reply to | #104297 |
BartC <bc@freeuk.com> writes: > Let me ask you a follow-on question first: how slow does a new Python > version have to be before even you would take notice? Slow *at doing what*, in particular? It matters which specific operation we're discussing. -- \ “The generation of random numbers is too important to be left | `\ to chance.” —Robert R. Coveyou | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 12:40 +1100 |
| Message-ID | <mailman.21.1457401253.15725.python-list@python.org> |
| In reply to | #104297 |
On Tue, Mar 8, 2016 at 12:33 PM, BartC <bc@freeuk.com> wrote: > On 08/03/2016 01:23, Chris Angelico wrote: >> >> On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote: >>> >>> Yes of course it does. As does 'being slow'. Take another microbenchmark: >>> >>> def whiletest(): >>> | i=0 >>> | while i<=100000000: >>> | | i+=1 >>> >>> whiletest() >>> >>> Python 2.7: 8.4 seconds >>> Python 3.1: 12.5 seconds >>> Python 3.4: 18.0 seconds >>> >>> Even if you don't care about speed, you must admit that there appears to >>> be >>> something peculiar going on here: why would 3.4 take more than twice as >>> long >>> as 2.7? What do they keep doing to 3.x to cripple it on each new version? >> >> >> How do your benchmarks compare on this code: >> >> pass > > > Let me ask you a follow-on question first: how slow does a new Python > version have to be before even you would take notice? > > Compared with 2.7, 3.4 above is spending nearly an extra ten seconds doing > .... what? I can't understand why someone just wouldn't care. Performance matters, when you actually have something useful to measure. Startup performance matters enormously if interpreter startup is what you're doing a lot of (for example, the "feel" of Mercurial depends heavily on Python startup performance). It matters not a whit if your process keeps running for a long time, and handles many requests (for example, a web server). You need to be VERY clear about exactly what you're measuring. Are you using the 'timeit' module to measure execution of one line of code? Are you putting your code into a file and running that with /usr/bin/time? Are you putting the code into Idle and running it in a loop with 'exec' and using time.time() around the outside? Your numbers do not concern me *because they mean nothing*. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 02:02 +0000 |
| Message-ID | <nblbmu$qpn$1@dont-email.me> |
| In reply to | #104302 |
On 08/03/2016 01:40, Chris Angelico wrote: > On Tue, Mar 8, 2016 at 12:33 PM, BartC <bc@freeuk.com> wrote: >> Let me ask you a follow-on question first: how slow does a new Python >> version have to be before even you would take notice? >> >> Compared with 2.7, 3.4 above is spending nearly an extra ten seconds doing >> .... what? I can't understand why someone just wouldn't care. > > Performance matters, when you actually have something useful to > measure. Startup performance matters enormously if interpreter startup > is what you're doing a lot of (for example, the "feel" of Mercurial > depends heavily on Python startup performance). It matters not a whit > if your process keeps running for a long time, and handles many > requests (for example, a web server). > > You need to be VERY clear about exactly what you're measuring. Are you > using the 'timeit' module to measure execution of one line of code? > Are you putting your code into a file and running that with > /usr/bin/time? Are you putting the code into Idle and running it in a > loop with 'exec' and using time.time() around the outside? Your > numbers do not concern me *because they mean nothing*. So they're just random numbers? I write interpreters. If I suddenly saw a 115% increase in runtime from one version to another, /even on a trivial 2-line loop/ (or even on /any/ program doing the same task), then I'd want to know why! Because experience tells me that something is wrong. Of course I don't know here what they've been doing to Python. Maybe they know exactly why it's slower. But then they should explain why it is, otherwise it could be a bug. Maybe someone left a debug flag turned on or something. Or there's some other technical reason, but it would be nice to know what it is. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-08 13:28 +1100 |
| Message-ID | <mailman.26.1457404134.15725.python-list@python.org> |
| In reply to | #104310 |
BartC <bc@freeuk.com> writes: > On 08/03/2016 01:40, Chris Angelico wrote: > > You need to be VERY clear about exactly what you're measuring. Are > > you using the 'timeit' module to measure execution of one line of > > code? Are you putting your code into a file and running that with > > /usr/bin/time? Are you putting the code into Idle and running it in > > a loop with 'exec' and using time.time() around the outside? Your > > numbers do not concern me *because they mean nothing*. > > So they're just random numbers? That's not an implication from what Chris is saying. Rather, the implication is the numbers do not have the meaning you're ascribing to them. > I write interpreters. If I suddenly saw a 115% increase in runtime > from one version to another, /even on a trivial 2-line loop/ (or even > on /any/ program doing the same task), then I'd want to know why! > Because experience tells me that something is wrong. Sure. Experience is not, though, going to tell you *what* is wrong until you can be much more specific in your observations, and verifiably attribute observations to behaviour. Until then, with all the experience in the world, to claim you know the explanation is merely unfounded assertion. -- \ “Skepticism is the highest duty and blind faith the one | `\ unpardonable sin.” —Thomas Henry Huxley, _Essays on | _o__) Controversial Questions_, 1889 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2016-03-08 02:47 +0000 |
| Message-ID | <mailman.29.1457405230.15725.python-list@python.org> |
| In reply to | #104297 |
On 2016-03-08 01:33, BartC wrote: > On 08/03/2016 01:23, Chris Angelico wrote: >> On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote: >>> Yes of course it does. As does 'being slow'. Take another microbenchmark: >>> >>> def whiletest(): >>> | i=0 >>> | while i<=100000000: >>> | | i+=1 >>> >>> whiletest() >>> >>> Python 2.7: 8.4 seconds >>> Python 3.1: 12.5 seconds >>> Python 3.4: 18.0 seconds >>> >>> Even if you don't care about speed, you must admit that there appears to be >>> something peculiar going on here: why would 3.4 take more than twice as long >>> as 2.7? What do they keep doing to 3.x to cripple it on each new version? >> >> How do your benchmarks compare on this code: >> >> pass > > Let me ask you a follow-on question first: how slow does a new Python > version have to be before even you would take notice? > > Compared with 2.7, 3.4 above is spending nearly an extra ten seconds > doing .... what? I can't understand why someone just wouldn't care. > Part of it will be that Python 2 has 2 integer types: 'int' (fixed length) and 'long' (variable length). Originally, 'int' addition could overflow, but it was more friendly to promote the result to 'long' instead. Python 3 dropped 'int' and renamed 'long' to 'int'.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 11:15 +0000 |
| Message-ID | <nbmc33$j5m$1@dont-email.me> |
| In reply to | #104316 |
On 08/03/2016 02:47, MRAB wrote: > On 2016-03-08 01:33, BartC wrote: >> Compared with 2.7, 3.4 above is spending nearly an extra ten seconds >> doing .... what? I can't understand why someone just wouldn't care. >> > Part of it will be that Python 2 has 2 integer types: 'int' (fixed > length) and 'long' (variable length). > > Originally, 'int' addition could overflow, but it was more friendly to > promote the result to 'long' instead. That was my first thought on reading the thread and was going to post that as the reason for 3 being a little more sluggish. But then I tested Python 2 (2.7.11), and I couldn't get integer arithmetic to overflow at all! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jussi.piitulainen@helsinki.fi> |
|---|---|
| Date | 2016-03-08 13:45 +0200 |
| Message-ID | <lf5k2ld19ci.fsf@ling.helsinki.fi> |
| In reply to | #104328 |
BartC writes: > On 08/03/2016 02:47, MRAB wrote: >> On 2016-03-08 01:33, BartC wrote: > >>> Compared with 2.7, 3.4 above is spending nearly an extra ten seconds >>> doing .... what? I can't understand why someone just wouldn't care. >>> >> Part of it will be that Python 2 has 2 integer types: 'int' (fixed >> length) and 'long' (variable length). >> >> Originally, 'int' addition could overflow, but it was more friendly to >> promote the result to 'long' instead. > > That was my first thought on reading the thread and was going to post > that as the reason for 3 being a little more sluggish. > > But then I tested Python 2 (2.7.11), and I couldn't get integer > arithmetic to overflow at all! It overflows to the long type. Replace 0, 100000000 and 1 with 0L, 100000000L and 1L in Python2 version of your while loop test to see the effect. When I tried it this morning, it almost closed the gap between 2.7 and 3.4 on my laptop. (I don't remember the minor versions.) The latter was still slower but not by much.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 12:09 +0000 |
| Message-ID | <nbmf8j$ukk$1@dont-email.me> |
| In reply to | #104329 |
On 08/03/2016 11:45, Jussi Piitulainen wrote: > BartC writes: > >> On 08/03/2016 02:47, MRAB wrote: >>> On 2016-03-08 01:33, BartC wrote: >> >>>> Compared with 2.7, 3.4 above is spending nearly an extra ten seconds >>>> doing .... what? I can't understand why someone just wouldn't care. >>>> >>> Part of it will be that Python 2 has 2 integer types: 'int' (fixed >>> length) and 'long' (variable length). >>> >>> Originally, 'int' addition could overflow, but it was more friendly to >>> promote the result to 'long' instead. >> >> That was my first thought on reading the thread and was going to post >> that as the reason for 3 being a little more sluggish. >> >> But then I tested Python 2 (2.7.11), and I couldn't get integer >> arithmetic to overflow at all! > > It overflows to the long type. So the difference is that Py2 has int and long types, and overflows silently from int to long? (That seems sensible enough; I wonder why they changed it? When int is 64 bits, then probably 99.9% of code will not need anything more.) > Replace 0, 100000000 and 1 with 0L, 100000000L and 1L in Python2 version > of your while loop test to see the effect. When I tried it this morning, > it almost closed the gap between 2.7 and 3.4 on my laptop. (I don't > remember the minor versions.) The latter was still slower but not by > much. I tried that and it was 1 second slower than 3.4! (19 seconds compared with 18 seconds.) That would at first sight offer a plausible explanation for the discrepancy (which IMO would be too big a cost for the minor benefit of a single integer type). And maybe this particular combination of byte-codes just happened to show up the difference more dramatically. But then, 3.1 took only 12.5 seconds; same byte-codes, same unified 'long' type for integers... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-03-07 22:39 -0500 |
| Message-ID | <mailman.32.1457408419.15725.python-list@python.org> |
| In reply to | #104297 |
On 3/7/2016 8:33 PM, BartC wrote:
>> On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote:
>>> def whiletest():
>>> | i=0
>>> | while i<=100000000:
>>> | | i+=1
>>>
>>> whiletest()
>>>
>>> Python 2.7: 8.4 seconds
>>> Python 3.1: 12.5 seconds
>>> Python 3.4: 18.0 seconds
>>>
>>> Even if you don't care about speed, you must admit that there appears
>>> to be
>>> something peculiar going on here: why would 3.4 take more than twice
>>> as long
>>> as 2.7? What do they keep doing to 3.x to cripple it on each new
>>> version?
> Let me ask you a follow-on question first: how slow does a new Python
> version have to be before even you would take notice?
We now run a suite of benchmarks daily on latest versions of 2.7 and
default (3.6) to compare not to each other but to previous days to
detect changes within either branch.
I verified your result with installed 64 bit 2.7.11 versus 3.5.1
import time
def test():
i=0
while i<=100000000:
i+=1
start = time.time()
test()
print(time.time() - start)
4.4 (2.7) versus 10.7 (3.5)
Running loop at top level instead of inside the function doubled the
time. Replacing globals dict lookup with function locals array lookup
really helps.
Next, I replaced the body of the function with
for i in range(100000000): pass
This time, 3.5 wins: 3.8 versus 2.7. Whoops, unfair. Change range to
xrange in 2.7 and the time is 1.5.
Neither version optimizes the do-nothing loop away. A further version
of CPython might. There are people working on improving the speed of
CPython. Integer operations are not their focus, though, because that
can be done in numpy. Text operations have been getting work, and at
least one person is actively working on an ast optimizer.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 03:48 +0000 |
| Message-ID | <mailman.34.1457409006.15725.python-list@python.org> |
| In reply to | #104297 |
On 08/03/2016 03:39, Terry Reedy wrote: > On 3/7/2016 8:33 PM, BartC wrote: >>> On Tue, Mar 8, 2016 at 12:00 PM, BartC <bc@freeuk.com> wrote: > >>>> def whiletest(): >>>> | i=0 >>>> | while i<=100000000: >>>> | | i+=1 >>>> >>>> whiletest() >>>> >>>> Python 2.7: 8.4 seconds >>>> Python 3.1: 12.5 seconds >>>> Python 3.4: 18.0 seconds >>>> >>>> Even if you don't care about speed, you must admit that there appears >>>> to be >>>> something peculiar going on here: why would 3.4 take more than twice >>>> as long >>>> as 2.7? What do they keep doing to 3.x to cripple it on each new >>>> version? > >> Let me ask you a follow-on question first: how slow does a new Python >> version have to be before even you would take notice? > > We now run a suite of benchmarks daily on latest versions of 2.7 and > default (3.6) to compare not to each other but to previous days to > detect changes within either branch. > > I verified your result with installed 64 bit 2.7.11 versus 3.5.1 > > import time > def test(): > i=0 > while i<=100000000: > i+=1 > start = time.time() > test() > print(time.time() - start) > > 4.4 (2.7) versus 10.7 (3.5) > > Running loop at top level instead of inside the function doubled the > time. Replacing globals dict lookup with function locals array lookup > really helps. > > Next, I replaced the body of the function with > for i in range(100000000): pass > > This time, 3.5 wins: 3.8 versus 2.7. Whoops, unfair. Change range to > xrange in 2.7 and the time is 1.5. > > Neither version optimizes the do-nothing loop away. A further version > of CPython might. There are people working on improving the speed of > CPython. Integer operations are not their focus, though, because that > can be done in numpy. Text operations have been getting work, and at > least one person is actively working on an ast optimizer. > For reference all of the tips of the trade are given here 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-08 11:09 +1100 |
| Subject | What will I get when reading from a file? (was: Pyhon 2.x or 3.x, which is faster?) |
| Message-ID | <mailman.9.1457395811.15725.python-list@python.org> |
| In reply to | #104261 |
BartC <bc@freeuk.com> writes: > I'm using [a third-party library function] because this kind of file > reading in Python is a mess. If I do a read, will I get a string, a > byte sequence object, a byte-array, or array-array, or what? That's a strange statement; there is virtually no mystery in what you'll get from a Python 3 file object, because you're eessentially forced to declare explicitly what kind of results you want from it. In fact, this no-mystery is fairly special to Python. Most other languages will guess aspects of the file and won't force the programmer to be explicit; if anything, newcomers are frustrated at how *little* guesswork (i.e. how much explicit declaration) is involved in opening a Python 3 file. If you want bytes, you open the file in that mode. If you want text, you must instead open it with that mode and tell it what text codec to use. And so on. Where are you seeing mysterious results? -- \ “Any intelligent fool can make things bigger and more complex… | `\ It takes a touch of genius – and a lot of courage – to move in | _o__) the opposite direction.” —Albert Einstein | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-08 13:12 +1100 |
| Message-ID | <56de3513$0$1621$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104261 |
On Tue, 8 Mar 2016 09:39 am, BartC wrote:
> On 07/03/2016 20:47, Chris Angelico wrote:
>> On Tue, Mar 8, 2016 at 7:19 AM, BartC <bc@freeuk.com> wrote:
>
>>> What can be more perfect for comparing two implementations?
>
>> rosuav@sikorsky:~$ python2 -m timeit -s 'from fp import Float'
>> 'Float("1234.567")'
>> 1000000 loops, best of 3: 1.84 usec per loop
>> rosuav@sikorsky:~$ python3 -m timeit -s 'from fp import Float'
>> 'Float("1234.567")'
>> 100000 loops, best of 3: 2.76 usec per loop
>>
>> Look! Creating a floating-point value is faster under Python 2 than
>> Python 3. What could be more perfect?
>
>> This is like a microbenchmark in that it doesn't tell you anything
>> about real-world usage.
>
> Microbenchmarks have their uses, when you are concentrating on a
> particular aspect of a language. But I tried your code, calling Float a
> million times, and 2.7 took 8.3 seconds; 3.4 took 10.5 seconds. But that
> is meaningless according to you.
I think Chris is looking at this as a fair test of Python's speed. Nobody in
their right mind would use his pure-Python Float when built-in floats
exist.
But I think Chris is wrong. He may remember that Python gained a Decimal
class written in pure Python. Does he think that it is invalid to ask how
fast Decimal is? Surely not. Creating millions of Decimal instances might
not be the single biggest bottleneck slowing your code down, but I'm pretty
sure we would want that to be as fast as possible.
(In fact, in Python 3.4 [by memory], Decimal was re-written in C for speed.)
Anyway, just for comparisons sake, I ran the same micro-benchmark:
[steve@ando ~]$ python2.6 -m timeit -s 'from fp import
Float' 'Float("1234.567")'
100000 loops, best of 3: 11.1 usec per loop
[steve@ando ~]$ python2.7 -m timeit -s 'from fp import
Float' 'Float("1234.567")'
100000 loops, best of 3: 12.1 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s 'from fp import
Float' 'Float("1234.567")'
100000 loops, best of 3: 13.6 usec per loop
[steve@ando ~]$ python/python-dev/3.5/python -m timeit -s 'from fp import
Float' 'Float("1234.567")'
10000 loops, best of 3: 54 usec per loop
So you can see on my computer, there is an apparent slowdown between 2.6 and
2.7, and 2.7 and 3.3. I say "apparent" because it may not be statistically
meaningful: time results are notoriously fickle. I ran 2.7 again three
times, and got three faster results:
100000 loops, best of 3: 11.8 usec per loop
100000 loops, best of 3: 11.7 usec per loop
100000 loops, best of 3: 11.6 usec per loop
I'm pretty sure that the "11.8 .7 .6" pattern is just a coincidence, because
I ran it again:
100000 loops, best of 3: 12.4 usec per loop
So there is considerable variation in timing results.
What about 3.5? That's four times slower than 3.3? What happened there?
Simple: I compiled 3.3 with all the debugging code turned on.
> (3.1 took 8.5 seconds. What happened between 3.1 and 3.4 to cause such a
> slow-down? Do you think it might be a good idea for /someone/ at least
> to take pay some attention to that, before it grinds to a halt
> completely by version 4.0?)
This is the whole point of the speed.python.org site, to monitor and
benchmark the speed of the language.
[...]
>> CPython 2.5 and 2.7 are very different. Even 2.7.0 and 2.7.11 are
>> going to differ in performance. And that's without even looking at
>> what core devs would refer to as "other Pythons", which would include
>> IronPython, Jython, PyPy (well, you got that, but you're treating it
>> as an afterthought), MicroPython, Brython, wpython, Nuitka,
>> Cython..... these are *other Pythons*.
>
> What are you suggesting here? That all these Pythons are going to be
> faster or slower than each other? I would guess that most of them are
> going to be roughly the same, other than PyPy. If there was a fast
> version, then I would have heard about it!
I think Chris exaggerates the performance differences between bug fix
releases, at least in general. There's unlikely to be a major change in the
interpreter applied to (say) 2.7.11 that would speed it up drastically
compared to 2.7.0. But there may be a series of small performance
enhancements which, *together*, add up to a moderate increase in overall
speed (while being all but invisible to sufficiently small
micro-benchmarks.
But typically, it is very, very hard to definitively say that one version or
implementation of Python is faster than another. That will often depend on
what you're trying to do! But, with lots of hand-waving and a certain
amount of trepidation, I'd like to offer this as the "conventional wisdom"
for the speed of pure-Python on a semi-arbitrary set of benchmarks which
may or may not reflect actual use by anyone:
# slowest
jython
cpython + stackless
ironpython
pypy
# fastest
>> the
>> performance of array.array() is far from stable. It's not a core
>> language feature; you're using it because it's the most obvious
>> translation of your C algorithm,
>
> I'm using it because this kind of file reading in Python is a mess. If I
> do a read, will I get a string, a byte sequence object, a byte-array, or
> array-array, or what?
Calling it "a mess" is an exaggeration. There is a change between Python 2
and 3:
- in Python 2, reading from a file gives you bytes, that is, the
so-called "str" type, not unicode;
- in Python 3, reading from a file in binary mode gives you bytes, that is,
the "bytes" type; reading in text mode gives you a string, the "str" type.
How is this a mess?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 11:53 +0000 |
| Message-ID | <nbmeaf$r45$1@dont-email.me> |
| In reply to | #104311 |
On 08/03/2016 02:12, Steven D'Aprano wrote:
> On Tue, 8 Mar 2016 09:39 am, BartC wrote:
>> I'm using it because this kind of file reading in Python is a mess. If I
>> do a read, will I get a string, a byte sequence object, a byte-array, or
>> array-array, or what?
>
> Calling it "a mess" is an exaggeration. There is a change between Python 2
> and 3:
>
> - in Python 2, reading from a file gives you bytes, that is, the
> so-called "str" type, not unicode;
>
> - in Python 3, reading from a file in binary mode gives you bytes, that is,
> the "bytes" type; reading in text mode gives you a string, the "str" type.
>
> How is this a mess?
Python 2 Python 3
Text mode 'str' 'str'
Binary mode 'bytes' 'str'
For certain file formats, text mode can't be used because byte values
such as 10 could be expanded to the two bytes 13,10 on some systems.
So binary needs to be used. But Py2 and Py3 return different results;
and indexing a bytes object gives you an int, a str object gives you a str.
If you pass a file-handle to a function, that function can't just do a
read from that handle without considering whether the file might be in
text or binary mode, or whether it's running under Py2 or Py3.
And I think someone pointed out the difference between 'bytes',
'bytearray' and 'array.array', but I can't find that post at the minute.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-09 10:28 +1100 |
| Message-ID | <56df602a$0$1591$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104330 |
On Tue, 8 Mar 2016 10:53 pm, BartC wrote:
> On 08/03/2016 02:12, Steven D'Aprano wrote:
>> On Tue, 8 Mar 2016 09:39 am, BartC wrote:
>
>>> I'm using it because this kind of file reading in Python is a mess. If I
>>> do a read, will I get a string, a byte sequence object, a byte-array, or
>>> array-array, or what?
>>
>> Calling it "a mess" is an exaggeration. There is a change between Python
>> 2 and 3:
>>
>> - in Python 2, reading from a file gives you bytes, that is, the
>> so-called "str" type, not unicode;
>>
>> - in Python 3, reading from a file in binary mode gives you bytes, that
>> is, the "bytes" type; reading in text mode gives you a string, the "str"
>> type.
>>
>> How is this a mess?
>
> Python 2 Python 3
>
> Text mode 'str' 'str'
> Binary mode 'bytes' 'str'
That table is incorrect. In Python 2, bytes is just an alias for str:
[steve@ando ~]$ python2.7 -c "print bytes is str"
True
and reading from a file returns a result depending on whether it is opened
in text or binary mode:
[steve@ando ~]$ echo foo > /tmp/junk
[steve@ando ~]$ python2.7 -c "print type(open('/tmp/junk', 'r').read())"
<type 'str'>
[steve@ando ~]$ python2.7 -c "print type(open('/tmp/junk', 'rb').read())"
<type 'str'>
In Python 3, you get bytes in binary mode, and Unicode strings (known
as "str") in text mode:
[steve@ando ~]$ python3 -c "print(type(open('/tmp/junk', 'r').read()))"
<class 'str'>
[steve@ando ~]$ python3 -c "print(type(open('/tmp/junk', 'rb').read()))"
<class 'bytes'>
Here it is in a table form:
-------- -------- --------
Mode Python 2 Python 3
-------- -------- --------
Text bytes text
Binary bytes bytes
-------- -------- --------
And here is a table summarising the name changes around text and byte
strings:
------------ --------- --------
Type Python 2 Python 3
------------ --------- --------
Byte strings str/bytes bytes
Text strings unicode str
------------ --------- --------
Remember that when Python first named its string type, Unicode didn't even
exist and there was no concept of strings being anything but a pseudo-ASCII
byte string.
> For certain file formats, text mode can't be used because byte values
> such as 10 could be expanded to the two bytes 13,10 on some systems.
If it is a *text* file, then it shouldn't matter whether your lines end with
\r, \n or \r\n. Indeed, in text mode, Python will automatically concert all
of these to \n on reading. (For writing, it will write what you tell it to
write.)
Python will never expand \n to \r\n. But it may translate \r\n to \n.
> So binary needs to be used. But Py2 and Py3 return different results;
> and indexing a bytes object gives you an int, a str object gives you a
> str.
It is true, and unfortunate, that indexing byte objects give ints instead of
a byte string of length 1:
[steve@ando ~]$ python3 -c "print(b'Aardvark'[0])"
65
In hindsight, it was a mistake, but as we are now in Python 3.5, breaking
backwards compatibility in the 3.x series means we are stuck with it
without some pain. Fortunately is it easy enough to work around: take a
one-element slice.
[steve@ando ~]$ python3 -c "print(b'Aardvark'[0:1])"
b'A'
> If you pass a file-handle to a function, that function can't just do a
> read from that handle without considering whether the file might be in
> text or binary mode, or whether it's running under Py2 or Py3.
Why not? file.read() works exactly the same in all four cases.
It's hard to argue against your statement when I don't understand what
problem you think you have. A concrete example of this "mess" would help.
> And I think someone pointed out the difference between 'bytes',
> 'bytearray' and 'array.array', but I can't find that post at the minute.
Er, yes? Of course there is a differences between those three types. There's
also a difference between list, set and dict. What's your point?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-09 00:09 +0000 |
| Message-ID | <nbnpev$hc2$1@dont-email.me> |
| In reply to | #104361 |
On 08/03/2016 23:28, Steven D'Aprano wrote:
> On Tue, 8 Mar 2016 10:53 pm, BartC wrote:
>> Python 2 Python 3
>>
>> Text mode 'str' 'str'
>> Binary mode 'bytes' 'str'
>
> That table is incorrect. In Python 2, bytes is just an alias for str:
>
> [steve@ando ~]$ python2.7 -c "print bytes is str"
> True
>
>
> and reading from a file returns a result depending on whether it is opened
> in text or binary mode:
>
> [steve@ando ~]$ echo foo > /tmp/junk
> [steve@ando ~]$ python2.7 -c "print type(open('/tmp/junk', 'r').read())"
> <type 'str'>
> [steve@ando ~]$ python2.7 -c "print type(open('/tmp/junk', 'rb').read())"
> <type 'str'>
>
>
> In Python 3, you get bytes in binary mode, and Unicode strings (known
> as "str") in text mode:
>
> [steve@ando ~]$ python3 -c "print(type(open('/tmp/junk', 'r').read()))"
> <class 'str'>
> [steve@ando ~]$ python3 -c "print(type(open('/tmp/junk', 'rb').read()))"
> <class 'bytes'>
>
>
> Here it is in a table form:
>
> -------- -------- --------
> Mode Python 2 Python 3
> -------- -------- --------
> Text bytes text
> Binary bytes bytes
> -------- -------- --------
That doesn't correspond to your results above. Going with the reported
type of what is read, it would be:
-------- -------- --------
Mode Python 2 Python 3
-------- -------- --------
Text str str
Binary str bytes
-------- -------- --------
Notice the odd-one-out is now the bottom left, not the the top right.
> Python will never expand \n to \r\n. But it may translate \r\n to \n.
Well, OK, you might lose bytes with the value 13. That's also bad.
>> If you pass a file-handle to a function, that function can't just do a
>> read from that handle without considering whether the file might be in
>> text or binary mode, or whether it's running under Py2 or Py3.
>
> Why not? file.read() works exactly the same in all four cases.
Didn't you just demonstrate that it can give different results?
> It's hard to argue against your statement when I don't understand what
> problem you think you have. A concrete example of this "mess" would help.
>
>> And I think someone pointed out the difference between 'bytes',
>> 'bytearray' and 'array.array', but I can't find that post at the minute.
>
> Er, yes? Of course there is a differences between those three types. There's
> also a difference between list, set and dict. What's your point?
OK, I take it back; if it's not a mess, then it's just confusing!
If someone asked me when I'd use a byte sequence, and when I'd use a
bytearray object, then I wouldn't have a clue.
(Looking it up, it appears than one is mutable, and the other isn't.
This isn't quite the same as the difference between a list and a dict.)
As for array.arrays, those apparently can also be arrays of bytes.
Presumably, mutable. OK. Definitely nothing here that could be tidied up...
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web