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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2016-03-08 00:47 +0000 |
| Message-ID | <mailman.14.1457398068.15725.python-list@python.org> |
| In reply to | #104283 |
On 2016-03-08 00:22, BartC wrote:
> On 07/03/2016 23:40, Chris Angelico wrote:
>> On Tue, Mar 8, 2016 at 9:39 AM, BartC <bc@freeuk.com> 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?
>>
>> Uhh.... you'll get either a text string or a byte string, depending on
>> whether you opened the file as text or binary. Where's the mess?
>
> (Is a byte string the same as a byte array? Is a byte array the same as
> an array.array? If I remove this line from my code, where 'data' has
> just been read from a file:
>
> data=array.array('B',data)
>
> then it still works - Python 3. But not on Python 2. If I do .read on a
> binary file I get a byte string in Python 3, but a string in Python 2.
> That sort of mess.
>
In Python 2, an unmarked string literal _is_ a bytestring; in Python 3,
an unmarked string literal is Unicode.
> And how do I write that deceptively simple header on the output file
> without array.array because I tried all sorts:
>
> f = open(file+".ppm", "wb")
> s="P6\n%d %d\n255\n" % (hdr.width, hdr.height)
> sbytes=array.array('B',list(map(ord,s)))
> f.write(sbytes)
>
You don't need to use array.array:
sbytes = bytes(map(ord, s))
In Python 3.5, you can use '%' with a bytestring:
s = b"P6\n%d %d\n255\n" % (hdr.width, hdr.height)
[snip]
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-07 20:29 -0500 |
| Message-ID | <mailman.19.1457400559.15725.python-list@python.org> |
| In reply to | #104283 |
On Tue, 8 Mar 2016 00:22:06 +0000, BartC <bc@freeuk.com> declaimed the
following:
>On 07/03/2016 23:40, Chris Angelico wrote:
>> On Tue, Mar 8, 2016 at 9:39 AM, BartC <bc@freeuk.com> 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?
>>
>> Uhh.... you'll get either a text string or a byte string, depending on
>> whether you opened the file as text or binary. Where's the mess?
>
>(Is a byte string the same as a byte array? Is a byte array the same as
>an array.array? If I remove this line from my code, where 'data' has
>just been read from a file:
In Python 3, text strings are Unicode (in current versions they will be
1, 2, or 4 bytes per character, depending on the "worst" character in the
string... If everything is ASCII or ISO-Latin-1, a text string will be one
byte per character). In Python 2, text strings are ALWAYS one byte per
character (resulting in garbage if the real data is unicode). In Python 2,
you have to explicitly ask that text be parsed as Unicode; conversely,
Python 3 requires you to explicitly ask for binary bytes.
In Python 2 you have to use bytearray() to create a "byte array". Byte
array is mutable -- you can change values at each position without having
to decompose and recompose the whole. Text strings are not mutable.
>>> stng = "This is the end of the World"
>>> ba = bytearray(stng)
>>> ba
bytearray(b'This is the end of the World')
>>> stng[10] = "q"
Traceback (most recent call last):
File "<interactive input>", line 1, in <module>
TypeError: 'str' object does not support item assignment
>>> ba[10] = "q"
>>> stng
'This is the end of the World'
>>> ba
bytearray(b'This is thq end of the World')
>>>
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-03-07 22:51 -0500 |
| Message-ID | <mailman.35.1457409161.15725.python-list@python.org> |
| In reply to | #104283 |
On 3/7/2016 7:22 PM, BartC wrote:
> (Is a byte string the same as a byte array?
No, if by 'byte array' mean (mutable) bytearray.
Yes, in the sense that a byte string is an (immutable) array of ints in
range(256).
> Is a byte array the same as an array.array?
No, if by 'byte array' you mean the same as bytes.
Yes, if you mean bytearray and array.array('B'), in the sense that
bytearray is based on array.array('B').
> If I remove this line from my code, where 'data' has
> just been read from a file:
>
> data=array.array('B',data)
>
> then it still works - Python 3.
In 3.3, data = bytearray(data) would have the same effect, and the only
effect is to make data mutable, but if you do not mutate the image
bytes, that is useless.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-03-08 17:34 -0700 |
| Message-ID | <mailman.58.1457483711.15725.python-list@python.org> |
| In reply to | #104283 |
On 03/07/2016 05:45 PM, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 11:22 AM, BartC <bc@freeuk.com> wrote:
>>
>> (Is a byte string the same as a byte array? Is a byte array the same as an
>> array.array? If I remove this line from my code, where 'data' has just been
>> read from a file:
>>
>> data=array.array('B',data)
>>
>> then it still works - Python 3. But not on Python 2. If I do .read on a
>> binary file I get a byte string in Python 3, but a string in Python 2. That
>> sort of mess.
>
> The default string in Py2 *is* a byte string.
There are some interesting differences I found between a Python 2 string
(composed of bytes) and a Python 3 byte string, such as what you'd get
from calling read() on a file handle opened in binary mode. That is in
Python 2, indexing a string returns a string of length 1. In Python
3.5, indexing a byte string returns a value, the equivalent of calling
ord() on the single byte string. This makes it a bit difficult to make
the code easily work between Python 2 and 3 and handle bytes. Any ideas
there?
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-09 13:01 +1100 |
| Message-ID | <56df8411$0$1608$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104367 |
On Wed, 9 Mar 2016 11:34 am, Michael Torrie wrote: > There are some interesting differences I found between a Python 2 string > (composed of bytes) and a Python 3 byte string, such as what you'd get > from calling read() on a file handle opened in binary mode. That is in > Python 2, indexing a string returns a string of length 1. In Python > 3.5, indexing a byte string returns a value, the equivalent of calling > ord() on the single byte string. Yes, this sadly turned out to be a mistake, and one which we're probably stuck with. > This makes it a bit difficult to make > the code easily work between Python 2 and 3 and handle bytes. Any ideas > there? Use a single byte slice: the_bytes[i:i+1] which works identically in Python 2 and 3. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-09 11:38 +1100 |
| Message-ID | <mailman.60.1457483896.15725.python-list@python.org> |
| In reply to | #104283 |
On Wed, Mar 9, 2016 at 11:34 AM, Michael Torrie <torriem@gmail.com> wrote:
> On 03/07/2016 05:45 PM, Chris Angelico wrote:
>> On Tue, Mar 8, 2016 at 11:22 AM, BartC <bc@freeuk.com> wrote:
>>>
>>> (Is a byte string the same as a byte array? Is a byte array the same as an
>>> array.array? If I remove this line from my code, where 'data' has just been
>>> read from a file:
>>>
>>> data=array.array('B',data)
>>>
>>> then it still works - Python 3. But not on Python 2. If I do .read on a
>>> binary file I get a byte string in Python 3, but a string in Python 2. That
>>> sort of mess.
>>
>> The default string in Py2 *is* a byte string.
>
> There are some interesting differences I found between a Python 2 string
> (composed of bytes) and a Python 3 byte string, such as what you'd get
> from calling read() on a file handle opened in binary mode. That is in
> Python 2, indexing a string returns a string of length 1. In Python
> 3.5, indexing a byte string returns a value, the equivalent of calling
> ord() on the single byte string. This makes it a bit difficult to make
> the code easily work between Python 2 and 3 and handle bytes. Any ideas
> there?
As Steven commented, this is probably a design flaw in the Py3 bytes
type, but it can't be changed now. For perfect compatibility, just
slice:
>>> b"asdf"[2:3] # Py2
'd'
>>> b"asdf"[2:3] # Py3
b'd'
Works in both versions, with the only difference being the repr.
It's a bit clunky, but it does work.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-08 11:05 +1100 |
| Message-ID | <mailman.7.1457395587.15725.python-list@python.org> |
| In reply to | #104261 |
BartC <bc@freeuk.com> writes: > On 07/03/2016 20:47, Chris Angelico wrote: > > 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. The “micro” is not referring to the focus of the operation; that's a good thing to do and is a way to produce useful, salient results. Choose a specific aspect and design a test case which focusses as narrowly as possible on that aspect. Then you can gather data to make meaningful statements about that aspect in isolation from others. What is “micro” about the benchmark you showed is that it doesn't gather enough data to be useful. The test should not just do one statement; it should do some relevant complete unit of the algorithm. Focussed, but interesting: a huge amount of data, or a complex data conversion, or something else that qualifies as “real”. > Anyway, is reading a jpeg not real world usage? It's a task normally > done with a compiled language, but can also be a good test for an > interpreted one. Try testing on a large battery of highly varied JPEG images, and getting the aggregate results from that. Or something that is more interesting (i.e. relevant to the real usage) than one image. > If you want an interpreted language to take on wider range of tasks, > then you need to make it faster, and that means measuring how > efficient it is at executing algorithms itself, not measuring how long > some library in a different language takes to execute. That's quite true. The trick is to avoid being *so* focussed that you are mostly measuring a corner case, instead of a relevant use case. > > 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? At specific, highly-focussed operations? Of course. That is going to be true almost by definition: the implementations are different, so if your test cases are extremely focussed they will be much more likely to find variations in the implementations — differences that are not relevant to which version of the Python source you're coming from. > I would guess that most of them are going to be roughly the same, > other than PyPy. That's the kind of guess which should be subjected to testing. We humans are *very* bad at estimating those kinds of behaviour in implementation. This is especially true because we humans also demand baroque, highly-complex implementations in order to get our speed improvements. And those complexities of implementation will be a major factor thwarting our intuitions about how those implementations will perform. If you think you know how an implementation will perform, the data indicates you should not trust that instinct. > If there was a fast version, then I would have heard about it! The mistake, I think, is in assuming a “fast version” means anything. Different implementations will be faster at some things, slower at other things, where “things” can be a very lumpy and convoluted landscape of complex use cases. Test those assumptions with realistic benchmarks run under each implementation. -- \ “When [science] permits us to see the far side of some new | `\ horizon, we remember those who prepared the way – seeing for | _o__) them also.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 01:00 +0000 |
| Message-ID | <nbl81v$hii$1@dont-email.me> |
| In reply to | #104278 |
On 08/03/2016 00:05, Ben Finney wrote: > BartC <bc@freeuk.com> writes: > >> On 07/03/2016 20:47, Chris Angelico wrote: >>> 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. > > The “micro” is not referring to the focus of the operation; that's a > good thing to do and is a way to produce useful, salient results. Choose > a specific aspect and design a test case which focusses as narrowly as > possible on that aspect. Then you can gather data to make meaningful > statements about that aspect in isolation from others. > > What is “micro” about the benchmark you showed is that it doesn't gather > enough data to be useful. The test should not just do one statement; it > should do some relevant complete unit of the algorithm. Focussed, but > interesting: a huge amount of data, or a complex data conversion, or > something else that qualifies as “real”. What's the purpose of the measurement? In my case, I'm not just measuring, but also implementing: either developing a program (the decoder for example) and trying to get it fast, and/or using it to tweak some interpreter or other I'm working on. Then I might well want to focus on particular single byte-code or some narrow aspect of the program. >> Anyway, is reading a jpeg not real world usage? It's a task normally >> done with a compiled language, but can also be a good test for an >> interpreted one. > > Try testing on a large battery of highly varied JPEG images, and getting > the aggregate results from that. Or something that is more interesting > (i.e. relevant to the real usage) than one image. If your efforts manage to double the speed of reading file A, then probably the reading file B is also going to be improved! In practice you use a variety of files, but one at a time will do. >> If there was a fast version, then I would have heard about it! > > The mistake, I think, is in assuming a “fast version” means anything. 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? (For comparison, my interpreter managed 0.4s, PyPy 0.3s (it's hot on loops) and part-optimised C might be 0.07s (fully-optimised would be 0s).) So you might say that a 'fast' version wouldn't give silly timings like the above. Trying something like the silly loop above on a new language can be quite revealing. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 01:12 +0000 |
| Message-ID | <mailman.16.1457399576.15725.python-list@python.org> |
| In reply to | #104289 |
On 08/03/2016 01:00, BartC wrote: > > If your efforts manage to double the speed of reading file A, then > probably the reading file B is also going to be improved! In practice > you use a variety of files, but one at a time will do. > What is the difference in your timing when you first read the file, and then read it a second time when it's been cached by the OS? In other words, you are probably measuring more of the response time of the disk than the code that does the reading, hence making your figures useless. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 01:47 +0000 |
| Message-ID | <nblapf$ofi$1@dont-email.me> |
| In reply to | #104292 |
On 08/03/2016 01:12, Mark Lawrence wrote: > On 08/03/2016 01:00, BartC wrote: >> >> If your efforts manage to double the speed of reading file A, then >> probably the reading file B is also going to be improved! In practice >> you use a variety of files, but one at a time will do. >> > > What is the difference in your timing when you first read the file, and > then read it a second time when it's been cached by the OS? In other > words, you are probably measuring more of the response time of the disk > than the code that does the reading, hence making your figures useless. > It's not going to be significant. My hard drive is going to read at, what, 100MB per second? Probably more. One test file is 0.2MB. Load time is going to be negligible whether cached or not. The Python timing for that file is around 20 seconds, time enough to read 10000 copies from the disk. And a C program reads /and decodes/ the same file from the same disk in between 0.1 and 0.2 seconds. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 02:45 +0000 |
| Message-ID | <mailman.28.1457405184.15725.python-list@python.org> |
| In reply to | #104305 |
On 08/03/2016 01:47, BartC wrote: > On 08/03/2016 01:12, Mark Lawrence wrote: >> On 08/03/2016 01:00, BartC wrote: >>> >>> If your efforts manage to double the speed of reading file A, then >>> probably the reading file B is also going to be improved! In practice >>> you use a variety of files, but one at a time will do. >>> >> >> What is the difference in your timing when you first read the file, and >> then read it a second time when it's been cached by the OS? In other >> words, you are probably measuring more of the response time of the disk >> than the code that does the reading, hence making your figures useless. >> > > It's not going to be significant. My hard drive is going to read at, > what, 100MB per second? Probably more. > > One test file is 0.2MB. Load time is going to be negligible whether > cached or not. > > The Python timing for that file is around 20 seconds, time enough to > read 10000 copies from the disk. > > And a C program reads /and decodes/ the same file from the same disk in > between 0.1 and 0.2 seconds. > So how much of that time is Python startup time, compared to C which is effectively zero? Or are you suggesting that C code is always 100 times faster than Python? Of course I'd like to see you write C code 100 times faster than Python, but of course that's where Python shines, which is why it is so popular. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 11:09 +0000 |
| Message-ID | <nbmbnp$hsi$1@dont-email.me> |
| In reply to | #104315 |
On 08/03/2016 02:45, Mark Lawrence wrote: > On 08/03/2016 01:47, BartC wrote: >> The Python timing for that file is around 20 seconds, time enough to >> read 10000 copies from the disk. >> >> And a C program reads /and decodes/ the same file from the same disk in >> between 0.1 and 0.2 seconds. >> > > So how much of that time is Python startup time, compared to C which is > effectively zero? Virtually zero as well. That's if by start-up time you mean how long between invoking Python with the name of the main module, executing all the imports and defs in the main and imported modules, until it starts properly executing code. In the jpeg test, perhaps 50ms. And it would not depend on the size of the input since the start-up routines won't know that. > Or are you suggesting that C code is always 100 times > faster than Python? This test is one of those where C can clearly do a good job of reducing most of it down to a series of tight loops where everything is in registers. But yes, numeric algorithms are generally going to be a magnitude or two faster in optimised C, compared with CPython executing pure Python code. (But I also remember posting a test in comp.lang.c that was faster in Python than in C. It involved strings and Python had the edge because it used counted strings. A straightforward C version would use zero-terminated strings, although it could be speeded up with a bit more work.) > Of course I'd like to see you write C code 100 > times faster than Python, No, it would take longer. But the final result could be run hundreds of times a day by millions of people. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 16:09 +0000 |
| Message-ID | <mailman.45.1457453433.15725.python-list@python.org> |
| In reply to | #104327 |
On 08/03/2016 11:09, BartC wrote: > On 08/03/2016 02:45, Mark Lawrence wrote: >> On 08/03/2016 01:47, BartC wrote: > >>> The Python timing for that file is around 20 seconds, time enough to >>> read 10000 copies from the disk. >>> >>> And a C program reads /and decodes/ the same file from the same disk in >>> between 0.1 and 0.2 seconds. >>> >> >> So how much of that time is Python startup time, compared to C which is >> effectively zero? > > Virtually zero as well. Nonsense. > > That's if by start-up time you mean how long between invoking Python > with the name of the main module, executing all the imports and defs in > the main and imported modules, until it starts properly executing code. > > In the jpeg test, perhaps 50ms. And it would not depend on the size of > the input since the start-up routines won't know that. How did you obtain that figure? > >> Or are you suggesting that C code is always 100 times >> faster than Python? > > This test is one of those where C can clearly do a good job of reducing > most of it down to a series of tight loops where everything is in > registers. > > But yes, numeric algorithms are generally going to be a magnitude or two > faster in optimised C, compared with CPython executing pure Python code. > > (But I also remember posting a test in comp.lang.c that was faster in > Python than in C. It involved strings and Python had the edge because it > used counted strings. A straightforward C version would use > zero-terminated strings, although it could be speeded up with a bit more > work.) > > > Of course I'd like to see you write C code 100 >> times faster than Python, > > No, it would take longer. But the final result could be run hundreds of > times a day by millions of people. > Which also happens with Python, although I expect that many users aren't aware of 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 19:15 +0000 |
| Message-ID | <nbn871$8np$1@dont-email.me> |
| In reply to | #104337 |
On 08/03/2016 16:09, Mark Lawrence wrote: > On 08/03/2016 11:09, BartC wrote: >> On 08/03/2016 02:45, Mark Lawrence wrote: >>> On 08/03/2016 01:47, BartC wrote: >> >>>> The Python timing for that file is around 20 seconds, time enough to >>>> read 10000 copies from the disk. >>>> >>>> And a C program reads /and decodes/ the same file from the same disk in >>>> between 0.1 and 0.2 seconds. >>>> >>> >>> So how much of that time is Python startup time, compared to C which is >>> effectively zero? >> >> Virtually zero as well. > > Nonsense. > >> >> That's if by start-up time you mean how long between invoking Python >> with the name of the main module, executing all the imports and defs in >> the main and imported modules, until it starts properly executing code. >> >> In the jpeg test, perhaps 50ms. And it would not depend on the size of >> the input since the start-up routines won't know that. > > How did you obtain that figure? By printing a message followed by exit(0) just before the program was about to start doing its thing. Then I timed that using: $time python program.py in Linux. But this was hardly necessary as it was so obvious: it takes 150ms to process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to switch to PyPy here as I've never had time to hang about for it) 180 seconds for 80Mpixel file. Surely the start-up time would be the same no matter what the input. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-08 20:44 +0000 |
| Message-ID | <mailman.56.1457469902.15725.python-list@python.org> |
| In reply to | #104356 |
On 08/03/2016 19:15, BartC wrote: > On 08/03/2016 16:09, Mark Lawrence wrote: >> On 08/03/2016 11:09, BartC wrote: >>> On 08/03/2016 02:45, Mark Lawrence wrote: >>>> On 08/03/2016 01:47, BartC wrote: >>> >>>>> The Python timing for that file is around 20 seconds, time enough to >>>>> read 10000 copies from the disk. >>>>> >>>>> And a C program reads /and decodes/ the same file from the same >>>>> disk in >>>>> between 0.1 and 0.2 seconds. >>>>> >>>> >>>> So how much of that time is Python startup time, compared to C which is >>>> effectively zero? >>> >>> Virtually zero as well. >> >> Nonsense. >> >>> >>> That's if by start-up time you mean how long between invoking Python >>> with the name of the main module, executing all the imports and defs in >>> the main and imported modules, until it starts properly executing code. >>> >>> In the jpeg test, perhaps 50ms. And it would not depend on the size of >>> the input since the start-up routines won't know that. >> >> How did you obtain that figure? > > By printing a message followed by exit(0) just before the program was > about to start doing its thing. > > Then I timed that using: > > $time python program.py > > in Linux. > > But this was hardly necessary as it was so obvious: it takes 150ms to > process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to > switch to PyPy here as I've never had time to hang about for it) 180 > seconds for 80Mpixel file. > > Surely the start-up time would be the same no matter what the input. > Unless all of the background jobs are kicking in when you're testing. I assume that you do take such factors into account, by repeating your tests and taking an average, or perhaps even a worst case figure. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-08 22:38 +0000 |
| Message-ID | <nbnk3a$qoe$1@dont-email.me> |
| In reply to | #104358 |
On 08/03/2016 20:44, Mark Lawrence wrote: > On 08/03/2016 19:15, BartC wrote: >> Surely the start-up time would be the same no matter what the input. >> > > Unless all of the background jobs are kicking in when you're testing. I > assume that you do take such factors into account, by repeating your > tests and taking an average, or perhaps even a worst case figure. Really, that is not necessary, although I've also lost track of the point you're making. Here's a new, fuller set of figures for a 24Mpixel image, with a new version of PyPy that I've found: Load from disk (4MB) and decode into memory (70MB), all using the same algorithm and the Python code using pure Python: PyPy 2.7.10 17.0 seconds (PyPy 4.0.1 32-bit) PyPy 3.2.5 23.5 (PyPy 2.4.0 32-bit) Python 2.7.11 274 (All CPython on Windows) Python 3.1.2 280 Python 3.4.3 352 (C 1.5 gcc -O3) (Bart's 26.5 my bytecode language) That Python3 (3.4 version) is still insisting on being 30% slower than Python2! I doubt it's just doing an extra 80 seconds' worth of start-up code. But looking at the bigger picture, it's also 2000% slower than PyPy, as well as 23000% slower than C. From that point of view, I can see now why some would shrug at the relatively minor differences between versions of CPython. Still, if do you have to use CPython for this task (or any task with this scale of runtime), it means hanging about for more than an minute extra with Python 3.4. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-09 10:59 +1100 |
| Message-ID | <56df6761$0$1588$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104356 |
On Wed, 9 Mar 2016 06:15 am, BartC wrote: [...] > But this was hardly necessary as it was so obvious: it takes 150ms to > process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to > switch to PyPy here as I've never had time to hang about for it) 180 > seconds for 80Mpixel file. > > Surely the start-up time would be the same no matter what the input. I've been trying to follow this thread, but I'm completely lost as to why we're discussing startup time. Mark seems to think that it's completely irrelevant, but that's surely wrong. Startup time might be irrelevant for long-running processes (say, a tool that runs for minutes or hours processing millions of files, or a server that is expected to stay running for weeks at a time) but it has a very large effect on the performance of quick-running command line tools. For what it's worth, the core developers are aware that CPython's startup time has been increasing, and that it is large enough to impact the feeling of snappiness and responsiveness for command line tools. They are actively working on this to keep it as low as possible. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-09 08:40 +0000 |
| Message-ID | <mailman.72.1457512871.15725.python-list@python.org> |
| In reply to | #104363 |
On 08/03/2016 23:59, Steven D'Aprano wrote: > On Wed, 9 Mar 2016 06:15 am, BartC wrote: > > [...] >> But this was hardly necessary as it was so obvious: it takes 150ms to >> process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to >> switch to PyPy here as I've never had time to hang about for it) 180 >> seconds for 80Mpixel file. >> >> Surely the start-up time would be the same no matter what the input. > > > Mark seems to think that it's completely irrelevant, but that's surely wrong. > The exact opposite actually. I'm trying to make sense of these so called benchmark figures, and quite frankly can't make head nor tail of them. BartC also cannot seem to grasp that the vast majority of people often couldn't care less about them, but continues banging on as if Python will never take off as it's too slow, whereas the reality is that it's been doing rather well. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-09 12:02 +0000 |
| Message-ID | <nbp36e$560$1@dont-email.me> |
| In reply to | #104395 |
On 09/03/2016 08:40, Mark Lawrence wrote: > On 08/03/2016 23:59, Steven D'Aprano wrote: >> On Wed, 9 Mar 2016 06:15 am, BartC wrote: >> >> [...] >>> But this was hardly necessary as it was so obvious: it takes 150ms to >>> process a 300-pixel image, 20 seconds for a 2Mpixel one, and (I have to >>> switch to PyPy here as I've never had time to hang about for it) 180 >>> seconds for 80Mpixel file. >>> >>> Surely the start-up time would be the same no matter what the input. >> >> >> Mark seems to think that it's completely irrelevant, but that's surely >> wrong. >> > > The exact opposite actually. I'm trying to make sense of these so > called benchmark figures, and quite frankly can't make head nor tail of > them. BartC also cannot seem to grasp that the vast majority of people > often couldn't care less about them, but continues banging on as if > Python will never take off as it's too slow, whereas the reality is that > it's been doing rather well. The majority of its users (and not just Python; there are plenty of these dynamic languages such as Javascript) probably don't care about it. They might not appreciate the fact that when they run a script, they are most likely executing a library written in a different language by people who /do/ care about performance. There quite a few projects around to get these dynamic languages up to to speed, so that there is less reliance on needing to code in languages such as C and C++. (If languages such as Python were just as fast in executing pure code, who would want to use C++? No one.) I suspect here that you're just one of those users who don't care what goes on behind the scenes. Now it might be there are so many libraries around already implemented, that there is little need for anyone to need to do any pure coding any more; you just throw together a script to invoke a library that someone else has painstakingly put together in a different language. That's one point of view. Here's another: you have a program in Python that you'd quite like to port to another dynamic language. Transcribing actual Python code is straightforward. Until you come to an import of a module that you can't find, because it's not written in Python. Now what? Now, you might appreciate the advantage of a program in 100% pure Python. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-09 21:13 +0000 |
| Message-ID | <mailman.96.1457558042.15725.python-list@python.org> |
| In reply to | #104402 |
On 09/03/2016 12:02, BartC wrote: > On 09/03/2016 08:40, Mark Lawrence wrote: > > Here's another: you have a program in Python that you'd quite like to > port to another dynamic language. Transcribing actual Python code is > straightforward. Until you come to an import of a module that you can't > find, because it's not written in Python. Now what? Now, you might > appreciate the advantage of a program in 100% pure Python. > That is not Python's problem, or my problem, that is your problem. Not that it matters, when you release BartC or whatever you call your language it'll take over the world, so I'm looking forward to dropping Python. What is the release date? Could it be the same as that for Python 2.8 or RickedPython? Will the unicode handling be better than that of the dread Python 3.3+, PEP393 Flexible String Representation as repeatedly pointed out by the RUE? Performance wise will it be tested against real world benchmarks or microbechmarks? Better still, will it be bug free, such that I don't have to waste my time on the equivalent of bugs.python.org raising problems, which should have been foreseen by your one man crew? -- 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]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.python
csiph-web