Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #41834 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2013-03-26 08:51 +1100 |
| Last post | 2013-03-28 12:39 +0000 |
| Articles | 20 on this page of 206 — 30 participants |
Back to article view | Back to comp.lang.python
Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 08:51 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-25 23:35 +0000
Re: Performance of int/long in Python 3 Dan Stromberg <drsalists@gmail.com> - 2013-03-25 17:12 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-26 17:26 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 13:38 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 01:08 +1100
Re: Performance of int/long in Python 3 Cousin Stanley <cousinstanley@gmail.com> - 2013-03-26 16:41 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 03:54 +1100
Re: Performance of int/long in Python 3 Terry Reedy <tjreedy@udel.edu> - 2013-03-26 14:24 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 11:50 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 06:03 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-26 13:44 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 20:50 +0000
Re: Performance of int/long in Python 3 Grant Edwards <invalid@invalid.invalid> - 2013-03-26 21:08 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 08:14 +1100
Re: Performance of int/long in Python 3 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2013-03-27 12:10 +1300
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 19:19 -0400
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-26 21:26 +0000
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-03-26 17:28 -0400
Re: Performance of int/long in Python 3 Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-26 23:14 -0400
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-03-27 13:30 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-03-27 07:52 +1100
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 17:00 -0700
Re: Performance of int/long in Python 3 rurpy@yahoo.com - 2013-03-26 21:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 00:20 +0000
Re: Performance of int/long in Python 3 Ned Deily <nad@acm.org> - 2013-03-26 18:31 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-27 11:51 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 01:47 +0000
flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 20:18 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 20:49 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 05:20 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rusi <rustompmody@gmail.com> - 2013-03-27 22:42 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 07:48 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-28 12:54 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 13:31 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 14:52 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 08:51 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Grant Edwards <invalid@invalid.invalid> - 2013-03-29 16:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] rurpy@yahoo.com - 2013-03-29 14:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-29 16:07 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-31 00:35 -0700
ASCII versus non-ASCII [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-31 08:22 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-31 13:55 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-03-31 22:33 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-31 23:52 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-01 16:57 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 08:14 +0000
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-01 08:15 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-01 06:11 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:02 +0000
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-01 17:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 04:20 +1100
Re: Performance of int/long in Python 3 MRAB <python@mrabarnett.plus.com> - 2013-04-01 18:53 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 12:15 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 06:28 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-01 13:28 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 07:35 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:38 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 22:43 +0100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 10:43 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 00:24 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-02 19:03 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 08:35 +0000
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:24 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 10:43 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 11:58 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 06:42 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-02 14:03 +0000
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 15:39 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:02 +0100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 08:12 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 16:43 +0100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 10:08 -0700
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-02 17:33 -0400
Re: Performance of int/long in Python 3 Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-02 23:40 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:09 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-02 15:12 +0100
Re: Performance of int/long in Python 3 Steve Simmons <square.steve@gmail.com> - 2013-04-02 16:03 +0100
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-02 08:17 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 09:57 -0700
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 11:22 -0700
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 11:50 -0700
Re: Performance of int/long in Python 3 Lele Gaifax <lele@metapensiero.it> - 2013-04-03 00:52 +0200
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-02 02:20 -0700
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-02 13:44 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 14:31 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 20:53 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 15:03 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-02 22:11 -0700
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:22 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:28 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:38 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 00:10 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:15 +1100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:25 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 00:34 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 05:32 +0000
Re: Performance of int/long in Python 3 Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-03 02:19 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:27 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:25 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 17:29 +1100
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 17:52 +1100
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 01:06 -0600
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 18:24 +1100
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 18:37 +1100
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 01:07 -0700
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 19:22 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 06:20 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-03 22:05 +1100
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 07:52 -0400
Sorting [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 14:43 +0000
Re: Sorting [was Re: Performance of int/long in Python 3] Roy Smith <roy@panix.com> - 2013-04-03 11:00 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:30 -0600
Re: Performance of int/long in Python 3 Dave Angel <davea@davea.name> - 2013-04-03 13:51 -0400
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-04 09:58 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 07:53 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-03 19:02 +1100
Re: Performance of int/long in Python 3 jmfauth <wxjmfauth@gmail.com> - 2013-04-03 01:08 -0700
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 12:27 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 09:43 -0400
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 01:17 +1100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:07 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:57 +1100
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-06 12:09 +0300
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-07 07:24 +1000
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-06 14:58 -0700
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 19:58 -0600
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-06 22:18 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 23:22 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 08:29 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-06 20:00 -0600
Re: Performance of int/long in Python 3 Serhiy Storchaka <storchaka@gmail.com> - 2013-04-07 11:02 +0300
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-07 16:14 +0100
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 15:02 +0000
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:38 -0600
Re: Performance of int/long in Python 3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-03 17:43 +0000
Re: Performance of int/long in Python 3 Chris Angelico <rosuav@gmail.com> - 2013-04-04 08:55 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 23:39 +0100
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:49 -0400
Re: Performance of int/long in Python 3 rusi <rustompmody@gmail.com> - 2013-04-03 09:10 -0700
Re: Performance of int/long in Python 3 Ethan Furman <ethan@stoneleaf.us> - 2013-04-03 10:09 -0700
Re: Performance of int/long in Python 3 Roy Smith <roy@panix.com> - 2013-04-03 20:46 -0400
Re: Performance of int/long in Python 3 Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-03 10:53 -0600
Re: Performance of int/long in Python 3 Neil Hodgson <nhodgson@iinet.net.au> - 2013-04-02 20:28 +1100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-03 14:56 +0100
Re: Performance of int/long in Python 3 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-01 20:54 +0100
Re: Performance of int/long in Python 3 roy@panix.com (Roy Smith) - 2013-04-01 16:31 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:35 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:22 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ned Deily <nad@acm.org> - 2013-03-28 13:23 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ethan Furman <ethan@stoneleaf.us> - 2013-03-27 23:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 02:03 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Foote <ian@feete.org> - 2013-03-28 09:36 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-28 23:11 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-28 13:01 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 07:12 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 01:38 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:14 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:21 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 08:45 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 12:01 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:11 -0600
Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 00:39 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:54 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-29 02:37 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 13:44 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:11 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-29 00:22 -0600
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Terry Reedy <tjreedy@udel.edu> - 2013-03-29 14:06 -0400
Re: Surrogate pairs in new flexible string representation Christian Heimes <christian@python.org> - 2013-03-29 23:05 +0100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 01:03 +0000
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Chris Angelico <rosuav@gmail.com> - 2013-03-29 12:10 +1100
Re: Surrogate pairs in new flexible string representation [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] MRAB <python@mrabarnett.plus.com> - 2013-03-29 02:00 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 03:16 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:01 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:34 +1100
unicode and the FSR [was: Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] Ethan Furman <ethan@stoneleaf.us> - 2013-03-28 21:56 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 16:33 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 16:46 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 14:51 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Neil Hodgson <nhodgson@iinet.net.au> - 2013-03-29 14:57 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 02:07 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-03-28 09:47 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 21:30 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 06:34 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Ian Kelly <ian.g.kelly@gmail.com> - 2013-03-28 10:33 -0600
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 09:55 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:13 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 10:48 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 04:55 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 13:26 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 08:45 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Terry Reedy <tjreedy@udel.edu> - 2013-03-28 19:12 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 13:29 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:11 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] jmfauth <wxjmfauth@gmail.com> - 2013-03-28 14:33 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] MRAB <python@mrabarnett.plus.com> - 2013-03-28 21:50 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-03-28 14:52 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-03-28 19:53 -0400
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-29 11:03 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-29 00:15 +0000
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Chris Angelico <rosuav@gmail.com> - 2013-03-28 14:40 +1100
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] 88888 Dihedral <dihedral88888@googlemail.com> - 2013-03-28 16:04 -0700
Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-28 12:39 +0000
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-03 09:10 -0700 |
| Message-ID | <aa3b500f-bebf-4d77-9855-3d90b07eaa6c@y7g2000pbu.googlegroups.com> |
| In reply to | #42668 |
On Apr 3, 6:43 pm, Roy Smith <r...@panix.com> wrote: > This has to inspect the entire string, no? I posted (essentially) this > a few days ago: > > if all(ord(c) <= 0xffff for c in s): > return "it's all bmp" > else: > return "it's got astral crap in it" Astral crap? CRAP? Verily sir I am offended! You dont play with Mahjong characters? How crude! You dont know about cuneiform? How illiterate! You dont compose poetry with Egyptian hieroglyphs? How rude! Shavian has not reformed you? How backward! In short you are a complete philistine No… On second thoughts I take that back. For all we know philistine may be one of the blessings of the Unicode gods? So following the ilustrious example of jmf, I shall pronounce upon you the ultimate curse: You are American!
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-04-03 10:09 -0700 |
| Message-ID | <mailman.69.1365009475.3114.python-list@python.org> |
| In reply to | #42681 |
On 04/03/2013 09:10 AM, rusi wrote: > On Apr 3, 6:43 pm, Roy Smith <r...@panix.com> wrote: >> This has to inspect the entire string, no? I posted (essentially) this >> a few days ago: >> >> if all(ord(c) <= 0xffff for c in s): >> return "it's all bmp" >> else: >> return "it's got astral crap in it" > > Astral crap? CRAP? > Verily sir I am offended! > > You dont play with Mahjong characters? How crude! > You dont know about cuneiform? How illiterate! > You dont compose poetry with Egyptian hieroglyphs? How rude! > Shavian has not reformed you? How backward! > > In short you are a complete philistine > No… On second thoughts I take that back. For all we know philistine > may be one of the blessings of the Unicode gods? > So following the ilustrious example of jmf, I shall pronounce upon you > the ultimate curse: > > You are American! LOL!
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 20:46 -0400 |
| Message-ID | <roy-DA6270.20461803042013@news.panix.com> |
| In reply to | #42681 |
In article <aa3b500f-bebf-4d77-9855-3d90b07eaa6c@y7g2000pbu.googlegroups.com>, rusi <rustompmody@gmail.com> wrote: > On Apr 3, 6:43 pm, Roy Smith <r...@panix.com> wrote: > > This has to inspect the entire string, no? I posted (essentially) this > > a few days ago: > > > > if all(ord(c) <= 0xffff for c in s): > > return "it's all bmp" > > else: > > return "it's got astral crap in it" > > Astral crap? CRAP? > Verily sir I am offended! > [...] > You are American! This is true. But, to be fair, in the (I don't have the exact number here) roughly 200 million records in our recent big data import job, I found exactly FOUR strings with astral characters. Which boiled down to two versions of each of two different song titles. One had a Unicode Character 'BALLOON' (U+1F388). The other had some heart symbol (sorry, I don't remember the exact code point). These hardly seem a matter of national pride. And, if you don't believe there is astral crap, how do you explain U+1F4A9?
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-03 10:53 -0600 |
| Message-ID | <mailman.67.1365008072.3114.python-list@python.org> |
| In reply to | #42641 |
On Wed, Apr 3, 2013 at 1:53 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> (sys.getsizeof(s) - sys.getsizeof(''))/len(s)
>>> s = '\x80\x81\x82\x83\x84\x85'
>>> len(s)
6
>>> import sys
>>> sys.getsizeof(s)
43
>>> sys.getsizeof(s) - sys.getsizeof('')
18
>>> (sys.getsizeof(s) - sys.getsizeof('')) / len(s)
3.0
I didn't know there was a 3-byte-width representation. :-)
More seriously, it fails because '' is ASCII and s is not, and the
overhead for the two strings is different.
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-02 20:28 +1100 |
| Message-ID | <vL-dna7-tIDuOMfMnZ2dnUVZ_rqdnZ2d@westnet.com.au> |
| In reply to | #42545 |
jmfauth:
> 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
> [0.8343414906182101, 0.8336184057396241, 0.8330473419738562]
> 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
> [1.3840254166697845, 1.3933888932429768, 1.391664674507438]
That's a larger performance decrease than the 64-bit version.
Reported the issue as
http://bugs.python.org/issue17615
Neil
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-03 14:56 +0100 |
| Message-ID | <mailman.59.1364997258.3114.python-list@python.org> |
| In reply to | #42552 |
On 02/04/2013 10:28, Neil Hodgson wrote: > jmfauth: > >> 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] >> [0.8343414906182101, 0.8336184057396241, 0.8330473419738562] >> 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit >> [1.3840254166697845, 1.3933888932429768, 1.391664674507438] > > That's a larger performance decrease than the 64-bit version. > > Reported the issue as > http://bugs.python.org/issue17615 > > Neil FTR this has been closed as fixed see http://bugs.python.org/issue17615#msg185862 -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-01 20:54 +0100 |
| Message-ID | <mailman.14.1364845980.17481.python-list@python.org> |
| In reply to | #42485 |
On 01/04/2013 20:15, jmfauth wrote:
> ---------
>
>
> I'm not whining or and I'm not complaining (and never did).
> I always exposed facts.
The only fact I'm aware of is an edge case that is being addressed on
the Python bug tracker, sorry I'm too lazy to look up the number again.
>
> I'm not especially interested in Python, I'm interested in
> Unicode.
So why do you keep harping on about the same old edge case?
>
> Usualy when I posted examples, there are confirmed.
The only thing you've ever posted are the same old boring micro
benchmarks. You never, ever comment on the memory savings that are IIRC
extremely popular with the Django folks amongst others. Neither do you
comment on the fact that the unicode implementation in Python 3.3 is
correct. I can only assume that you prefer a fast but buggy
implementation to a correct but slow one. Except that in many cases the
3.3 implementation is actually faster, so you conveniently ignore this.
>
>
> What I see is this (std "download-abled" Python's on Windows 7 (and
> other
> Windows/platforms/machines):
>
> Py32
>>>> import timeit
>>>> timeit.repeat("'a' * 1000 + 'ẞ'")
> [0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
>>>> timeit.repeat("'a' * 1000 + 'z'")
> [0.7105829560031083, 0.6904999426964764, 0.6938637184431968]
>
> Py33
> import timeit
> timeit.repeat("'a' * 1000 + 'ẞ'")
> [1.1484035160337613, 1.1233738895227505, 1.1215708962703874]
> timeit.repeat("'a' * 1000 + 'z'")
> [0.6640958193635527, 0.6469043692851528, 0.6458961423900007]
>
> I have systematically such a behaviour, in 99.99999% of my tests.
Always run on your micro benchmarks, never anything else.
> When there is something better, it is usually because something else
> (3.2/3.3) has been modified.
>
> I have my idea where this is coming from.
I know where this is coming from as it's been stated umpteen times on
numerous threads. As usual you simply ignore any facts that you feel
like, particularly with respect to any real world use cases.
>
> Question: When it is claimed, that this has been tested,
> do you mean stringbench.py as proposed many times by Terry?
> (Thanks for an answer).
I find it amusing that you ask for an answer but refuse point blank to
provide answers yourself. I suspect that you've bitten off more than
you can chew.
>
> jmf
>
--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.
Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | roy@panix.com (Roy Smith) |
|---|---|
| Date | 2013-04-01 16:31 -0400 |
| Message-ID | <kjcqrv$3ma$1@panix2.panix.com> |
| In reply to | #42470 |
In article <5159beb6$0$29967$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >> The import job isn't done yet, but so far we've processed 116 million >> records and had to clean up four of them. I can live with that. >> Sometimes practicality trumps correctness. > >Well, true. It has to be said that few programming languages (and >databases) make it easy to do the right thing. On the other hand, you're >a programmer. Your job is to write correct code, not easy code. This is really getting off topic, but fundamentally, I'm an engineer. My job is to build stuff that make money for my company. That means making judgement calls about what's not worth fixing, because the cost to fix it exceeds the value.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-03-29 00:35 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <5154e1cb$0$29974$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42186 |
On Thu, 28 Mar 2013 12:54:20 -0700, rurpy wrote: > Even if you personally would prefer someone to respond by calling you a > liar, your personal preferences do not form a basis for desirable > posting behavior here. Whereas yours apparently are. Thanks for the feedback, I'll take it under advisement. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-28 21:22 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3866.1364466148.2939.python-list@python.org> |
| In reply to | #42100 |
On Thu, Mar 28, 2013 at 4:20 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Wed, 27 Mar 2013 20:49:20 -0700, rusi wrote: > >> In particular "You are a liar" is as bad as "You are an idiot" The same >> statement can be made non-abusively thus: "... is not true because ..." > > I accept that criticism, even if I disagree with it. Does that make > sense? I mean it in the sense that I accept that your opinion differs > from mine. > > Politeness does not always trump honesty, and stating that somebody's > statement "is not true because..." is not the same as stating that they > are deliberately telling lies (rather than merely being mistaken or > confused). There comes a time when a bit of rudeness is a small cost to pay for forum maintenance. Before you criticize someone for nit-picking, think what happens when someone reads the thread archive. Of course, that particular example can be done courteously too - cf the "def" vs "class" nit from a recent thread. But it'd still be of value even if done rudely, so the hundreds of subsequent readers would have a chance to know what's going on. I was researching a problem with ALSA a couple of weeks ago, and came across a forum thread that discussed exactly what I needed to know. A dozen or so courteous posts delivered misinformation; finally someone had the guts to be rude and call people out for posting incorrect points (and got criticized for doing so), and that one post was the most useful in the whole thread. I'd rather this list have some vinegar than it devolve into uselessness. Or, worse, if there's a hard-and-fast rule about courtesy, devolve into aspartame... everyone's courteous in words but hates each other underneath. Or am I taking the analogy too far? :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ned Deily <nad@acm.org> |
|---|---|
| Date | 2013-03-28 13:23 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3912.1364502234.2939.python-list@python.org> |
| In reply to | #42100 |
In article <CAPTjJmoZDHsmUQx7vcpuii2BwRcNzCx76Pm-6unB1DUq4dODGg@mail.gmail.com>, Chris Angelico <rosuav@gmail.com> wrote: > I'd rather this list have some vinegar than it devolve into > uselessness. Or, worse, if there's a hard-and-fast rule about > courtesy, devolve into aspartame... everyone's courteous in words but > hates each other underneath. Or am I taking the analogy too far? :) I think you are positing false choices. No one - at least I'm not - is advocating to avoid challenging false or misleading statements in the interests of maintaining some false "see how well we all get along" facade. The point is we can have meaningful, hard-nosed discussions without resorting to personal insults, i.e. flaming. I think the discussion in this topic over the past 24 hours or so demonstrates that. -- Ned Deily, nad@acm.org
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-03-27 23:12 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3860.1364451682.2939.python-list@python.org> |
| In reply to | #42078 |
On 03/27/2013 08:49 PM, rusi wrote: > In particular "You are a liar" is as bad as "You are an idiot" > The same statement can be made non-abusively thus: "... is not true > because ..." I don't agree. With all the posts and micro benchmarks and other drivel that jmf has inflicted on us, I find it /very/ hard to believe that he forgot -- which means he was deliberately lying. At some point we have to stop being gentle / polite / politically correct and call a shovel a shovel... er, spade. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 02:03 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <987c4bd9-0e5e-4387-9c78-1075a77d3c47@c6g2000yqh.googlegroups.com> |
| In reply to | #42102 |
On 28 mar, 07:12, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/27/2013 08:49 PM, rusi wrote: > > > In particular "You are a liar" is as bad as "You are an idiot" > > The same statement can be made non-abusively thus: "... is not true > > because ..." > > I don't agree. With all the posts and micro benchmarks and other drivel that jmf has inflicted on us, I find it /very/ > hard to believe that he forgot -- which means he was deliberately lying. > > At some point we have to stop being gentle / polite / politically correct and call a shovel a shovel... er, spade. > > -- > ~Ethan~ ----------- The problem is elsewhere. Nobody understand the examples I gave on this list, because nobody understand Unicode. These examples are not random examples, they are well thought. If you were understanding the coding of the characters, Unicode and what this flexible representation does, it would not be a problem for you to create analog examples. So, we are turning into circles. This flexible representation succeeds to cumulate in one shoot all the design mistakes it is possible to do, when one wishes to implements Unicode. Example of a good Unicode understanding. If you wish 1) to preserve memory, 2) to cover the whole range of Unicode, 3) to keep maximum performance while preserving the good work Unicode.org as done (normalization, sorting), there is only one solution: utf-8. For this you have to understand, what is really a "unicode transformation format". Why all the actors, active in the "text field", like MicroSoft, Apple, Adobe, the unicode compliant TeX engines, the foundries, the "organisation" in charge of the OpenType font specifications, are able to handle all this stuff correctly (understanding + implementation) and Python not?, I should say this is going beyond my understanding. Python has certainly and definitvely not "revolutionize" Unicode. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ian Foote <ian@feete.org> |
|---|---|
| Date | 2013-03-28 09:36 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3863.1364463394.2939.python-list@python.org> |
| In reply to | #42104 |
On 28/03/13 09:03, jmfauth wrote: > The problem is elsewhere. Nobody understand the examples > I gave on this list, because nobody understand Unicode. > These examples are not random examples, they are well > thought. > > If you were understanding the coding of the characters, > Unicode and what this flexible representation does, it > would not be a problem for you to create analog examples. > > So, we are turning into circles. > > This flexible representation succeeds to cumulate in one > shoot all the design mistakes it is possible to do, when > one wishes to implements Unicode. > > Example of a good Unicode understanding. > If you wish 1) to preserve memory, 2) to cover the whole range > of Unicode, 3) to keep maximum performance while preserving the > good work Unicode.org as done (normalization, sorting), there > is only one solution: utf-8. For this you have to understand, > what is really a "unicode transformation format". > > Why all the actors, active in the "text field", like MicroSoft, > Apple, Adobe, the unicode compliant TeX engines, the foundries, > the "organisation" in charge of the OpenType font specifications, > are able to handle all this stuff correctly (understanding + > implementation) and Python not?, I should say this is going > beyond my understanding. > > Python has certainly and definitvely not "revolutionize" > Unicode. > > jmf > You're confusing python's choice of internal string representation with the programmer's choice of encoding for communicating with other programs. I think most people agree that utf-8 is usually the best encoding to use for interoperating with other unicode aware software, but as a variable-length encoding it has disadvantages that make it unsuitable for use as an internal representation. Specifically, indexing a variable-length encoding like utf-8 is not as efficient as indexing a fixed-length encoding. Regards, Ian F
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-03-28 23:11 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <rOednY4OeOjbqcnMnZ2dnUVZ_oWdnZ2d@westnet.com.au> |
| In reply to | #42105 |
Ian Foote:
> Specifically, indexing a variable-length encoding like utf-8 is not as
> efficient as indexing a fixed-length encoding.
Many common string operations do not require indexing by character
which reduces the impact of this inefficiency. UTF-8 seems like a
reasonable choice for an internal representation to me. One benefit of
UTF-8 over Python's flexible representation is that it is, on average,
more compact over a wide set of samples.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-03-28 13:01 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <51543f45$0$29998$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42119 |
On Thu, 28 Mar 2013 23:11:55 +1100, Neil Hodgson wrote: > Ian Foote: > >> Specifically, indexing a variable-length encoding like utf-8 is not as >> efficient as indexing a fixed-length encoding. > > Many common string operations do not require indexing by character > which reduces the impact of this inefficiency. Which common string operations do you have in mind? Specifically in Python's case, the most obvious counter-example is the length of a string. But that's only because Python strings are immutable objects, and include a field that records the length. So once the string is created, checking its length takes constant time. Some string operations need to inspect every character, e.g. str.upper(). Even for them, the increased complexity of a variable-width encoding costs. It's not sufficient to walk the string inspecting a fixed 1, 2 or 4 bytes per character. You have to walk the string grabbing 1 byte at a time, and then decide whether you need another 1, 2 or 3 bytes. Even though it's still O(N), the added bit-masking and overhead of variable- width encoding adds to the overall cost. Any string method that takes a starting offset requires the method to walk the string byte-by-byte. I've even seen languages put responsibility for dealing with that onto the programmer: the "start offset" is given in *bytes*, not characters. I don't remember what language this was... it might have been Haskell? Whatever it was, it horrified me. > UTF-8 seems like a > reasonable choice for an internal representation to me. It's not. Haskell, for example, uses UTF-8 internally, and it warns that this makes string operations O(N) instead of O(1) precisely because of the need to walk the string inspecting every byte. Remember, when your string primitives are O(N), it is very easy to write code that becomes O(N**2). Using UTF-8 internally is just begging for user-written code to be O(N**2). > One benefit of > UTF-8 over Python's flexible representation is that it is, on average, > more compact over a wide set of samples. Sure. And over a different set of samples, it is less compact. If you write a lot of Latin-1, Python will use one byte per character, while UTF-8 will use two bytes per character. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 07:12 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <944f195c-cbfe-47e1-a963-05fe3d98238d@5g2000yqz.googlegroups.com> |
| In reply to | #42123 |
On 28 mar, 14:01, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Thu, 28 Mar 2013 23:11:55 +1100, Neil Hodgson wrote: > > Ian Foote: > > > > One benefit of > > UTF-8 over Python's flexible representation is that it is, on average, > > more compact over a wide set of samples. > > Sure. And over a different set of samples, it is less compact. If you > write a lot of Latin-1, Python will use one byte per character, while > UTF-8 will use two bytes per character. > This flexible string representation is so absurd that not only "it" does not know you can not write Western European Languages with latin-1, "it" penalizes you by just attempting to optimize latin-1. Shown in my multiple examples. (This is a similar case of the long and short int question/dicussion Chris Angelico opened). PS1: I received plenty of private mails. I'm suprise, how the dev do not understand unicode. PS2: Question I received once from a registrated French Python Developper (in another context). What are those French characters you can handle with cp1252 and not with latin-1? jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 01:38 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3876.1364481489.2939.python-list@python.org> |
| In reply to | #42128 |
On Fri, Mar 29, 2013 at 1:12 AM, jmfauth <wxjmfauth@gmail.com> wrote: > This flexible string representation is so absurd that not only > "it" does not know you can not write Western European Languages > with latin-1, "it" penalizes you by just attempting to optimize > latin-1. Shown in my multiple examples. PEP393 strings have two optimizations, or kinda three: 1a) ASCII-only strings 1b) Latin1-only strings 2) BMP-only strings 3) Everything else Options 1a and 1b are almost identical - I'm not sure what the detail is, but there's something flagging those strings that fit inside seven bits. (Something to do with optimizing encodings later?) Both are optimized down to a single byte per character. Option 2 is optimized to two bytes per character. Option 3 is stored in UTF-32. Once again, jmf, you are forgetting that option 2 is a safe and bug-free optimization. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 08:14 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <6c93d273-2289-4c49-a586-52675aea9567@p5g2000yqj.googlegroups.com> |
| In reply to | #42130 |
On 28 mar, 15:38, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Mar 29, 2013 at 1:12 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > This flexible string representation is so absurd that not only > > "it" does not know you can not write Western European Languages > > with latin-1, "it" penalizes you by just attempting to optimize > > latin-1. Shown in my multiple examples. > > PEP393 strings have two optimizations, or kinda three: > > 1a) ASCII-only strings > 1b) Latin1-only strings > 2) BMP-only strings > 3) Everything else > > Options 1a and 1b are almost identical - I'm not sure what the detail > is, but there's something flagging those strings that fit inside seven > bits. (Something to do with optimizing encodings later?) Both are > optimized down to a single byte per character. > > Option 2 is optimized to two bytes per character. > > Option 3 is stored in UTF-32. > > Once again, jmf, you are forgetting that option 2 is a safe and > bug-free optimization. > > ChrisA As long as you are attempting to devide a set of characters in chunks and try to handle them seperately, it will never work. Read my previous post about the unicode transformation format. I know what pep393 does. jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 02:21 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3888.1364484553.2939.python-list@python.org> |
| In reply to | #42143 |
On Fri, Mar 29, 2013 at 2:14 AM, jmfauth <wxjmfauth@gmail.com> wrote: > As long as you are attempting to devide a set of characters in > chunks and try to handle them seperately, it will never work. Okay. Let's look at integers. To properly represent the Python 3 'int' type (or the Python 2 'long'), we need to be able to encode ANY integer. And of course, any attempt to divide them up into chunks will never work. So we need a single representation that will cover ANY integer, right? Perfect. We already have one of those, detailed in RFC 2795. (It's coming up to its thirteenth anniversary in a day or two. Very appropriate.) http://tools.ietf.org/html/rfc2795#section-4 Are you saying Python's integers should be stored as I-TAGs? ChrisA
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web