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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-09 11:36 +1100 |
| Message-ID | <mailman.59.1457483772.15725.python-list@python.org> |
| In reply to | #104365 |
On Wed, Mar 9, 2016 at 11:09 AM, BartC <bc@freeuk.com> wrote: > On 08/03/2016 23:28, Steven D'Aprano wrote: >> >> 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. Please, please, PLEASE get an understanding of the difference between text and bytes. The fact that the byte string in Py2 happens to have the same name as the text string in Py3 should be considered a *coincidence* when you're discussing these differences. Whenever you open a file in binary mode, you get back bytes. In Python 2, opening a file in text mode still gives back bytes, which is anomalous. Python 3 handles this properly: when you open a file in text mode, you specify an encoding, and it is decoded to Unicode text. >> 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 that bothers you, open the file in binary mode. Then you get a stream of bytes. In text mode, you're declaring that you expect the file to be a stream of lines. Lines might be ended by \r\n or \n, and you usually don't care. (Sometimes you do. Often you don't.) > 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... It's no difference from the question of when you use a tuple and when you use a list. They're very similar object types, with nearly the same methods and operations available. One's mutable and one's not. When should you use a tuple? Is it just a frozenlist? These are the sorts of questions that keep coming up on this list, and that's not a problem. They're coding design questions. When should you use an float, when a fractions.Fraction, when decimal.Decimal, etc? The fact that people have to ask does not mean the language should lose some of them. If someone asked me when I should use Windows Services and when I should use the Scheduler, I wouldn't know. If ever the situation comes up, I'd probably have to ask. That's not a problem; that's what mailing lists are for. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-08 21:03 -0500 |
| Message-ID | <mailman.66.1457489010.15725.python-list@python.org> |
| In reply to | #104361 |
On Wed, 09 Mar 2016 10:28:40 +1100, Steven D'Aprano <steve@pearwood.info>
declaimed the following:
>
>Python will never expand \n to \r\n. But it may translate \r\n to \n.
>
Not on input, but it will on output (on Windows)
>>> fout = open("C:/temp/dummy.txt", "w")
>>> fout.write("line1\nline2\n")
>>> fout.close()
>>>
PS C:\temp> get-content -Encoding byte .\dummy.txt
108
105
110
101
49
13
10
108
105
110
101
50
13
10
Note the "13" (<cr>) preceding the "10" (<lf>)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-10 03:07 +1100 |
| Message-ID | <56e04a36$0$1603$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104378 |
On Wed, 9 Mar 2016 01:03 pm, Dennis Lee Bieber wrote: > On Wed, 09 Mar 2016 10:28:40 +1100, Steven D'Aprano <steve@pearwood.info> > declaimed the following: > > >> >>Python will never expand \n to \r\n. But it may translate \r\n to \n. >> > Not on input, but it will on output (on Windows) That surprises me. Perhaps I read the documentation wrongly? Ah yes, apparently I did -- Python optionally will modify line endings in both directions, controlled by the user. In Python 3: https://docs.python.org/3.5/library/functions.html#open Thanks for the correction. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2016-03-08 14:48 +0200 |
| Message-ID | <mailman.40.1457441340.15725.python-list@python.org> |
| In reply to | #104311 |
On 08.03.16 04:12, Steven D'Aprano wrote:
> [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
>
> What about 3.5? That's four times slower than 3.3? What happened there?
This is interesting question. On my computer (32-bit) all versions from
3.3 to 3.6 have the same performance in this microbenchmark.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-08 12:34 +1100 |
| Message-ID | <56de2c36$0$1607$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104255 |
On Tue, 8 Mar 2016 07:47 am, Chris Angelico wrote: > You write *real world* code and then profile that. You get actual real > programs that you actually really use, and you run those through > timing harnesses. Chris, I think that's exactly what BartC has done: he has a program that he actually uses, one which processes JPG files. It's written in pure Python, so he's not comparing the quality of C libraries, he's comparing Python versus Python. I haven't looked at his code, so I don't know if its a fair comparison of Python versus Bart's Private Language. But that's not the point. Idiomatic Python or not, "best practice" production level code or not, it is a fair comparison of Python 2 versus Python 3, or CPython versus PyPy, because it's the same Python code being run each time. Could Bart's code be improved for production use? Almost certainly. I'm sure that by using a C image processing library, like pillow, it would be ten or a hundred times faster. If Bart were saying "Python is crap, it's too slow" then a perfectly acceptable response would be "no, you're just misusing it, here you want to use it as an interface to this library and let the library do the heavy lifting". That's what Python is designed for. But that's not what Bart is saying. I'm impressed that pure Python code running in CPython is even *usable* for whatever sort of image processing BartC is doing. He must be doing something right, given that its not unusably slow. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-08 12:49 +1100 |
| Message-ID | <mailman.22.1457401790.15725.python-list@python.org> |
| In reply to | #104298 |
On Tue, Mar 8, 2016 at 12:34 PM, Steven D'Aprano <steve@pearwood.info> wrote: > On Tue, 8 Mar 2016 07:47 am, Chris Angelico wrote: > >> You write *real world* code and then profile that. You get actual real >> programs that you actually really use, and you run those through >> timing harnesses. > > > Chris, I think that's exactly what BartC has done: he has a program that he > actually uses, one which processes JPG files. It's written in pure Python, > so he's not comparing the quality of C libraries, he's comparing Python > versus Python. The trouble is that we can't be sure _what_ he's done. All we have is that it takes longer under some circumstances than others. Without knowing a lot more about how the measurements are done, I don't know that we can get anything from it. And I remember seeing a performance analysis that showed that array.array() actually sucks for performance; hence my recommendation to try other ways of doing things, before saying "Python 3 is slower than Python 2". > Could Bart's code be improved for production use? Almost certainly. I'm sure > that by using a C image processing library, like pillow, it would be ten or > a hundred times faster. If Bart were saying "Python is crap, it's too slow" > then a perfectly acceptable response would be "no, you're just misusing it, > here you want to use it as an interface to this library and let the library > do the heavy lifting". That's what Python is designed for. But that's not > what Bart is saying. > > I'm impressed that pure Python code running in CPython is even *usable* for > whatever sort of image processing BartC is doing. He must be doing > something right, given that its not unusably slow. Fair point. Although these are only small files (as far as I know), so even if there's an O(N**2) memory allocation (eg with a naive "take a byte off the front and give me back the rest" algorithm), it'd quite probably still be usable. I've had N Squareds in code that sat there until the day I did some stupid benchmark on a gig of data, and only then started seeing problems. Readably-written code isn't necessarily that much slower than tightly-optimized code. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2016-03-08 15:05 +0200 |
| Message-ID | <mailman.41.1457442373.15725.python-list@python.org> |
| In reply to | #104298 |
On 08.03.16 03:34, Steven D'Aprano wrote: > Chris, I think that's exactly what BartC has done: he has a program that he > actually uses, one which processes JPG files. It's written in pure Python, > so he's not comparing the quality of C libraries, he's comparing Python > versus Python. > > I haven't looked at his code, so I don't know if its a fair comparison of > Python versus Bart's Private Language. But that's not the point. Idiomatic > Python or not, "best practice" production level code or not, it is a fair > comparison of Python 2 versus Python 3, or CPython versus PyPy, because > it's the same Python code being run each time. Comparing the quality of programmers by the time for which they ran a sprint is not fair.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-08 12:19 +1100 |
| Message-ID | <56de28a1$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104253 |
On Tue, 8 Mar 2016 07:19 am, BartC wrote:
> I don't have to hand a jpeg file that it can't
> decode.
Run this under Python 2:
from random import randint
blob = [randint(0, 256) for i in range(16*1024)]
with open('broken.jpg', 'wb') as f:
f.write(''.join(blob))
If your software can decode that, it will be a miracle.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 01:41 +0000 |
| Message-ID | <nblae9$nl0$1@dont-email.me> |
| In reply to | #104294 |
On 08/03/2016 01:19, Steven D'Aprano wrote:
> On Tue, 8 Mar 2016 07:19 am, BartC wrote:
>
>> I don't have to hand a jpeg file that it can't
>> decode.
>
>
> Run this under Python 2:
>
>
>
> from random import randint
> blob = [randint(0, 256) for i in range(16*1024)]
>
> with open('broken.jpg', 'wb') as f:
> f.write(''.join(blob))
>
>
>
>
> If your software can decode that, it will be a miracle.
>
That's not a jpeg file.
(You code didn't run even on Python 2, but I created a 16KB file of
random bytes by other means. It said 'Reading past end of data',
presumably looking for some marker or other.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-03-08 15:40 +1100 |
| Message-ID | <56de57b5$0$1590$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104303 |
On Tuesday 08 March 2016 12:41, BartC wrote:
> On 08/03/2016 01:19, Steven D'Aprano wrote:
>> On Tue, 8 Mar 2016 07:19 am, BartC wrote:
>>
>>> I don't have to hand a jpeg file that it can't
>>> decode.
>>
>> Run this under Python 2:
>>
>> from random import randint
>> blob = [randint(0, 256) for i in range(16*1024)]
>>
>> with open('broken.jpg', 'wb') as f:
>> f.write(''.join(blob))
>>
>> If your software can decode that, it will be a miracle.
>>
>
> That's not a jpeg file.
Nevertheless, in the real world, you have to deal with corrupt JPGs and
files mislabelled as JPGs. And "crashing" doesn't count as "deal with" :-)
> (You code didn't run even on Python 2
Serves me right for not testing it before posting :-(
Change the second line to:
blob = [chr(randint(0, 255)) for i in range(16*1024)]
and it works for me.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 13:49 +0000 |
| Message-ID | <nbml2q$l4n$1@dont-email.me> |
| In reply to | #104323 |
On 08/03/2016 04:40, Steven D'Aprano wrote:
> On Tuesday 08 March 2016 12:41, BartC wrote:
>
>> On 08/03/2016 01:19, Steven D'Aprano wrote:
>>> On Tue, 8 Mar 2016 07:19 am, BartC wrote:
>>>
>>>> I don't have to hand a jpeg file that it can't
>>>> decode.
>>>
>>> Run this under Python 2:
>>>
>>> from random import randint
>>> blob = [randint(0, 256) for i in range(16*1024)]
>>>
>>> with open('broken.jpg', 'wb') as f:
>>> f.write(''.join(blob))
>>>
>>> If your software can decode that, it will be a miracle.
>>>
>>
>> That's not a jpeg file.
>
> Nevertheless, in the real world, you have to deal with corrupt JPGs and
> files mislabelled as JPGs. And "crashing" doesn't count as "deal with" :-)
OK, I changed the 'raise' line to 'exit(0)'. Job done!
(I couldn't recreate the problem easily because the common failures
didn't call abortjpeg() at all.)
It doesn't make Py3 any faster than Py2 though...
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 16:15 +0000 |
| Message-ID | <mailman.46.1457453768.15725.python-list@python.org> |
| In reply to | #104335 |
On 08/03/2016 13:49, BartC wrote: > On 08/03/2016 04:40, Steven D'Aprano wrote: >> On Tuesday 08 March 2016 12:41, BartC wrote: >> >> Nevertheless, in the real world, you have to deal with corrupt JPGs and >> files mislabelled as JPGs. And "crashing" doesn't count as "deal with" >> :-) > > OK, I changed the 'raise' line to 'exit(0)'. Job done! > > (I couldn't recreate the problem easily because the common failures > didn't call abortjpeg() at all.) > > It doesn't make Py3 any faster than Py2 though... > So what, if 99% of people couldn't care less about that fact? -- 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 | wxjmfauth@gmail.com |
|---|---|
| Date | 2016-03-08 09:23 -0800 |
| Message-ID | <8f22bffc-e29d-4e61-b7f5-934cbf1a5215@googlegroups.com> |
| In reply to | #104338 |
This is much more interesting.
>>> timeit.timeit("s = 'asdf'; 'a' in s")
0.08400959240925197
>>> timeit.timeit("s = 'asdf'; 'EURO' in s")
0.0845499432670982
versus
>>> timeit.timeit("s = 'asdf'; 'a' in s")
0.12534446382583372
>>> timeit.timeit("s = 'asdf'; 'EURO' in s")
0.11553544162064178
- But why discuss?
- It's only an *illustration* of the problematic.
- Readers can be lucky, I'm not presenting BDFL examples.
jmf
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 19:02 +0000 |
| Message-ID | <nbn7dl$39g$1@dont-email.me> |
| In reply to | #104338 |
On 08/03/2016 16:15, Mark Lawrence wrote: > On 08/03/2016 13:49, BartC wrote: >> On 08/03/2016 04:40, Steven D'Aprano wrote: >>> On Tuesday 08 March 2016 12:41, BartC wrote: >>> >>> Nevertheless, in the real world, you have to deal with corrupt JPGs and >>> files mislabelled as JPGs. And "crashing" doesn't count as "deal with" >>> :-) >> >> OK, I changed the 'raise' line to 'exit(0)'. Job done! >> >> (I couldn't recreate the problem easily because the common failures >> didn't call abortjpeg() at all.) >> >> It doesn't make Py3 any faster than Py2 though... >> > > So what, if 99% of people couldn't care less about that fact? Um, because that's what the thread is about? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-09 11:04 +1100 |
| Message-ID | <56df6873$0$1588$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104335 |
On Wed, 9 Mar 2016 12:49 am, BartC wrote:
>> Nevertheless, in the real world, you have to deal with corrupt JPGs and
>> files mislabelled as JPGs. And "crashing" doesn't count as "deal with"
>> :-)
>
> OK, I changed the 'raise' line to 'exit(0)'. Job done!
Possibly a really amateurish, lazy job, but still done.
So now when you can't process a file, you silently exit, giving no
indication that there was a problem or what the problem was. You suppress
the helpful traceback, making sure that it is as difficult as possible for
the user to diagnose the problem. You even exit with an exit code of 0
("success") in order to confuse any scripts they use. Brilliant! I love
helpful tools like that!
How many years did you say you have been programming?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-09 01:28 +0000 |
| Message-ID | <nbnu1m$u1m$1@dont-email.me> |
| In reply to | #104364 |
On 09/03/2016 00:04, Steven D'Aprano wrote:
> On Wed, 9 Mar 2016 12:49 am, BartC wrote:
>
>>> Nevertheless, in the real world, you have to deal with corrupt JPGs and
>>> files mislabelled as JPGs. And "crashing" doesn't count as "deal with"
>>> :-)
>>
>> OK, I changed the 'raise' line to 'exit(0)'. Job done!
>
>
> Possibly a really amateurish, lazy job, but still done.
>
> So now when you can't process a file, you silently exit, giving no
> indication that there was a problem or what the problem was. You suppress
> the helpful traceback, making sure that it is as difficult as possible for
> the user to diagnose the problem. You even exit with an exit code of 0
> ("success") in order to confuse any scripts they use. Brilliant! I love
> helpful tools like that!
>
> How many years did you say you have been programming?
You forget to mention that the name of the input file is hard-coded,
making it awkward to use from a script.
That might give you a clue that it's not a serious, polished utility.
It's just a test, primarily as something useful for PyPy to get its
teeth into, but it's also the first time I'd ported a sizeable program
into Python.
(Which wasn't as painful as I'd expected. However the next project I
have in mind is 20K lines rather than 0.7K. For that I'm looking at some
mechanical translation I think. And probably some library to wrap around
Python's i/o.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-09 13:18 +1100 |
| Message-ID | <56df87f7$0$1620$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104372 |
On Wed, 9 Mar 2016 12:28 pm, BartC wrote: > (Which wasn't as painful as I'd expected. However the next project I > have in mind is 20K lines rather than 0.7K. For that I'm looking at some > mechanical translation I think. And probably some library to wrap around > Python's i/o.) You almost certainly don't need another wrapper around Python's I/O, making it slower still. You need to understand what Python's I/O is doing. If you open a file in binary mode, Python will give you a stream of bytes (ordinal values 0 through 255 inclusive). Python won't modify or change those bytes in any way. Whatever it reads from disk, it will give to you. If you open a file in text mode, Python 3 will give you a stream of Unicode code points (ordinal values 0 through 0x10FFFF). Earlier versions of Python 3 may behave somewhat strangely with so-called "astral characters": I recommend that you avoid anything below version 3.3. Unless you are including (e.g.) Chinese or ancient Phoenician in your text file, you probably won't care. In text mode by default, unless you tell it differently, Python will modify the ending of each line so that it is presented to you as \n regardless of whether the text file was created on a Mac, Windows, or Linux system. It won't modify lines when you write them, only when you read them. If you open a file in text mode, Python 2 will give you a stream of bytes, but it too will modify the line endings. In text mode, on Windows, Python *may* stop reading at a Ctrl-Z character and treat it as End Of File. I think. I can across this once, many years ago, but I no longer have access to Python on Windows to verify if that is still the case. There's more, but that's the basics to get you started. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2016-03-09 02:11 -0800 |
| Message-ID | <d700a9eb-0da5-4d49-875f-dff5f3d74604@googlegroups.com> |
| In reply to | #104380 |
Le mercredi 9 mars 2016 03:18:48 UTC+1, Steven D'Aprano a écrit :
>
> In text mode, on Windows, Python *may* stop reading at a Ctrl-Z character
> and treat it as End Of File. I think. I can across this once, many years
> ago, but I no longer have access to Python on Windows to verify if that is
> still the case.
>
> There's more, but that's the basics to get you started.
>
Python 3.2.5 (default, May 15 2013, 23:06:03) [MSC v.1500 32 bit (Intel)] on win32
>>> eta runs etazero.py...
...etazero has been executed
>>> with open('tmp.txt', 'rb') as f:
... r = f.read()
...
>>> print(r, len(r))
b'abc\x1adef\x80' 8
>>> with open('tmp.txt', 'r', encoding='cp1252') as f:
... rr = f.read()
...
>>> print(rr, len(rr))
abcdef€ 8
>>>
>>> # ሴ⌲
jmf
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-09 14:03 +0000 |
| Message-ID | <nbpaaa$uic$1@dont-email.me> |
| In reply to | #104380 |
On 09/03/2016 02:18, Steven D'Aprano wrote: > On Wed, 9 Mar 2016 12:28 pm, BartC wrote: > >> (Which wasn't as painful as I'd expected. However the next project I >> have in mind is 20K lines rather than 0.7K. For that I'm looking at some >> mechanical translation I think. And probably some library to wrap around >> Python's i/o.) > > You almost certainly don't need another wrapper around Python's I/O, making > it slower still. You need to understand what Python's I/O is doing. Well, the original project will be using its file i/o library. So it'll use the same interface that will be reimplemented on top of Python i/o. And input operations mainly consist of grabbing an entire file at once. Output is a little more mixed. > If you open a file in binary mode, Python will give you a stream of bytes > (ordinal values 0 through 255 inclusive). Python won't modify or change > those bytes in any way. Whatever it reads from disk, it will give to you. > > If you open a file in text mode, Python 3 will give you a stream of Unicode > code points (ordinal values 0 through 0x10FFFF). Earlier versions of Python > 3 may behave somewhat strangely with so-called "astral characters": I > recommend that you avoid anything below version 3.3. Unless you are > including (e.g.) Chinese or ancient Phoenician in your text file, you > probably won't care. I've just tried a UTF-8 file and getting some odd results. With a file containing [three euro symbols]: €€€ (including a 3-byte utf-8 marker at the start), and opened in text mode, Python 3 gives me this series of bytes (ie. the ord() of each character): 239 187 191 226 8218 172 226 8218 172 226 8218 172 And prints the resulting string as: €€€. Although this latter might depend on my console's code page setting. Changing it to UTF-8 however (CHCP 65001 in Windows) gives me this error when I run the program again: ---------- Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: cp65001 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ---------- (That was with 3.1; 3.4 gives the same set of characters as above, and shows the string differently, but still wrong. While PyPy 3.2.4 gives a different set of byte values, all 0..255, and a different string again, although it now contains some actual € characters. So I think I'll skip Unicode handling to start off with! (I've already had plenty of fun and games with it in the past.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-10 01:11 +1100 |
| Message-ID | <mailman.77.1457532681.15725.python-list@python.org> |
| In reply to | #104410 |
On Thu, Mar 10, 2016 at 1:03 AM, BartC <bc@freeuk.com> wrote: > I've just tried a UTF-8 file and getting some odd results. With a file > containing [three euro symbols]: > > €€€ > > (including a 3-byte utf-8 marker at the start), and opened in text mode, > Python 3 gives me this series of bytes (ie. the ord() of each character): > > 239 > 187 > 191 > 226 > 8218 > 172 > 226 > 8218 > 172 > 226 > 8218 > 172 > > And prints the resulting string as: €€€. The first three bytes are the "UTF-8 BOM", which suggests you may have created this in a broken editor like Notepad. For the rest, I'm not sure how you told Python to open this as text, but you certainly did NOT specify an encoding of UTF-8. The 8218 entries in there are completely bogus. Can you show your code, please, and also what you get if you open the file as binary? Unicode handling is easy as long as you (a) understand the fundamental difference between text and bytes, and (b) declare your encodings. Python isn't magical. It can't know the encoding without being told. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web