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 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2013-03-28 14:51 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3879.1364482498.2939.python-list@python.org> |
| In reply to | #42119 |
On 28/03/2013 12:11, 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. 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. > Implementing the regex module (http://pypi.python.org/pypi/regex) would have been more difficult if the internal representation had been UTF-8, because of the need to decode, and the implementation would also have been slower for that reason.
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-03-29 14:57 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <ToidnaJP2ctAjMjMnZ2dnUVZ_vudnZ2d@westnet.com.au> |
| In reply to | #42137 |
MRAB:
> Implementing the regex module (http://pypi.python.org/pypi/regex) would
> have been more difficult if the internal representation had been UTF-8,
> because of the need to decode, and the implementation would also have
> been slower for that reason.
One way to build regex support for UTF-8 is to build a fixed width
version of the regex code and then interpose an object that converts
between the UTF-8 representation and that code.
The C++11 standard library contains a regex template that can be
instantiated over a UTF-8 representation in this way.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 02:07 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3883.1364483268.2939.python-list@python.org> |
| In reply to | #42119 |
On Fri, Mar 29, 2013 at 1:51 AM, MRAB <python@mrabarnett.plus.com> wrote:
> On 28/03/2013 12:11, 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. 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.
>>
> Implementing the regex module (http://pypi.python.org/pypi/regex) would
> have been more difficult if the internal representation had been UTF-8,
> because of the need to decode, and the implementation would also have
> been slower for that reason.
In fact, nearly ALL string parsing operations would need to be done
differently. The only method that I can think of that wouldn't be
impacted is a linear state-machine parser - something that could be
written inside a "for character in string" loop.
text = []
def initial(c):
global state
if c=='<': state=tag
else: text.append(c)
def tag(c):
global state
if c=='>': state=initial
state = initial
for character in string:
state(character)
print(''.join(text))
I'm pretty sure this will run in O(N) time, even with UTF-8 strings.
But it's an *extremely* simple parser.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2013-03-28 09:47 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3864.1364464047.2939.python-list@python.org> |
| In reply to | #42104 |
On 28 March 2013 09:03, jmfauth <wxjmfauth@gmail.com> 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. There are many people here and among the Python devs who understand unicode. Similarly they have understood the examples that you have given. It has been accepted that there are a handful of cases where performance has been reduced as a result of the change. There are also many cases where the performance has improved. It is certainly not clear that there is an *overall* performance reduction for people using non latin-1 characters as you have often suggested. The reason your initial posts received a poor reception is that they were accompanied with pointless rants and arrogant claims that no one understood the problem. Had you simply reported the timing differences without the rants then I imagine that you would have received a response like "Okay, there might be a few regressions. Can you open an issue on the tracker please?". Since then you have been relentlessly hijacking unrelated threads and this is clearly just trolling. > > 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. This is clearly untrue.The most significant design mistakes are the ones that lead to incorrect handling of unicode characters. This new implementation in Python 3.3 has been designed in a way that makes it possible to handle all unicode characters correctly. > > 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". Again you pretend that others here don't understand. Most people here are well aware of utf-8 is. Your suggestion that "maximum performance" would be achieved if Python use utf-8 internally ignores the fact that it would have many negative performance implications for slicing and indexing and so on. > > 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. Perhaps not, but it does now correctly handle all unicode characters (unlike many other languages and pieces of software). Oscar
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-28 21:30 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3868.1364466636.2939.python-list@python.org> |
| In reply to | #42104 |
On Thu, Mar 28, 2013 at 8:03 PM, jmfauth <wxjmfauth@gmail.com> wrote: > 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". You really REALLY need to sort out in your head the difference between correctness and performance. I still haven't seen one single piece of evidence from you that Python 3.3 fails on any point of Unicode correctness. Covering the whole range of Unicode has never been a problem. In terms of memory usage and performance, though, there's one obvious solution. Fork CPython 3.3 (or the current branch head[1]), change the internal representation of a string to be UTF-8 (by the way, that's the official spelling), and run the string benchmarks. Then post your code and benchmark figures so other people can replicate your results. > Python has certainly and definitvely not "revolutionize" > Unicode. This is one place where you're actually correct, though, because PEP 393 isn't the first instance of this kind of format - Pike's had it for years. Funny though, I don't think that was your point :) [1] Apologies if my terminology is wrong, I'm a git user and did one quick Google search to see if hg uses the same term. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 06:34 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <b3808ea9-03fa-4781-aefe-af428899ee9c@5g2000yqz.googlegroups.com> |
| In reply to | #42112 |
On 28 mar, 11:30, Chris Angelico <ros...@gmail.com> wrote: > On Thu, Mar 28, 2013 at 8:03 PM, jmfauth <wxjmfa...@gmail.com> wrote: ----- > You really REALLY need to sort out in your head the difference between > correctness and performance. I still haven't seen one single piece of > evidence from you that Python 3.3 fails on any point of Unicode > correctness. That's because you are not understanding unicode. Unicode takes you from the character to the unicoded transformed fomat via the code point, working with a unique set of characters with a contigoous range of code points. Then it is up to the "implementors" (languages, compilers, ...) to implement this utf. > Covering the whole range of Unicode has never been a > problem. ... for all those, who are following the scheme explained above. And it magically works smoothly. Of course, there are some variations due to the Character Encoding Form wich is later influenced by the Character Encoding Scheme (the serialization of the character Encoding Scheme). Rough explanation in other words. I does not matter if you are using utf-8, -16, -32, ucs2 or ucs4. All the single characters are handled in the same way with the "same algorithm". --- The flexible string representation takes the problem from the other side, it attempts to work with the characters by using their representations and it (can only) fails... PS I never propose to use utf-8. I only spoke about utf-8 as an example. If you start to discuss indexing, you are off-topic. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-03-28 10:33 -0600 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3901.1364488470.2939.python-list@python.org> |
| In reply to | #42125 |
On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfauth@gmail.com> wrote: > The flexible string representation takes the problem from the > other side, it attempts to work with the characters by using > their representations and it (can only) fails... This is false. As I've pointed out to you before, the FSR does not divide characters up by representation. It divides them up by codepoint -- more specifically, by the *bit-width* of the codepoint. We call the internal format of the string "ASCII" or "Latin-1" or "UCS-2" for conciseness and a point of reference, but fundamentally all of the FSR formats are simply byte arrays of *codepoints* -- you know, those things you keep harping on. The major optimization performed by the FSR is to consistently truncate the leading zero bytes from each codepoint when it is possible to do so safely. But regardless of to what extent this truncation is applied, the string is *always* internally just an array of codepoints, and the same algorithms apply for all representations.
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 09:55 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <2362b4e9-fc37-492a-a216-08a22632b28d@u20g2000yqj.googlegroups.com> |
| In reply to | #42167 |
Chris,
Your problem with int/long, the start of this thread, is
very intersting.
This is not a demonstration, a proof, rather an illustration.
Assume you have a set of integers {0...9} and an operator,
let say, the addition.
Idea.
Just devide this set in two chunks, {0...4} and {5...9}
and work hardly to optimize the addition of 2 operands in
the sets {0...4}.
The problems.
- When optimizing "{0...4}", your algorithm will most probably
weaken "{5...9}".
- When using "{5...9}", you do not benefit from your algorithm, you
will be penalized just by the fact you has optimized "{0...4}"
- And the first mistake, you are just penalized and impacted by the
fact you have to select in which subset you operands are when
working with "{0...9}".
Very interestingly, working with the representation (bytes) of
these integers will not help. You have to consider conceptually
{0..9} as numbers.
Now, replace numbers by characters, bytes by "encoded code points",
and you have qualitatively the flexible string representation.
In Unicode, there is one more level of abstraction: one conceptually
neither works with characters, nor with "encoded code points", but
with unicode transformed formated "entities". (see my previous post).
That means you can work very hardly on the "bytes levels",
you will never solves the problem which is one level higher
in the unicode hierarchy:
character -> code point -> utf -> bytes (implementation)
with the important fact that this construct can only go
from left to right.
---
In fact, by proposing a flexible representation of ints, you may
just fall in the same trap the flexible string representation
presents.
----
All this stuff is explained in good books about the coding of the
characters and/or unicode.
The unicode.org documention explains it too. It is a little
bit harder to discover, because the doc is presenting always
this stuff from a "technical" perspective.
You get it when reading a large part of the Unicode doc.
jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 04:13 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3902.1364490807.2939.python-list@python.org> |
| In reply to | #42168 |
On Fri, Mar 29, 2013 at 3:55 AM, jmfauth <wxjmfauth@gmail.com> wrote:
> Assume you have a set of integers {0...9} and an operator,
> let say, the addition.
>
> Idea.
> Just devide this set in two chunks, {0...4} and {5...9}
> and work hardly to optimize the addition of 2 operands in
> the sets {0...4}.
>
> The problems.
> - When optimizing "{0...4}", your algorithm will most probably
> weaken "{5...9}".
> - When using "{5...9}", you do not benefit from your algorithm, you
> will be penalized just by the fact you has optimized "{0...4}"
> - And the first mistake, you are just penalized and impacted by the
> fact you have to select in which subset you operands are when
> working with "{0...9}".
>
> Very interestingly, working with the representation (bytes) of
> these integers will not help. You have to consider conceptually
> {0..9} as numbers.
Yeah, and there's an easy representation of those numbers. But let's
look at Python's representations of integers. I have a sneaking
suspicion something takes note of how large the number is before
deciding how to represent it. Look!
>>> sys.getsizeof(1)
14
>>> sys.getsizeof(1<<2)
14
>>> sys.getsizeof(1<<4)
14
>>> sys.getsizeof(1<<8)
14
>>> sys.getsizeof(1<<31)
18
>>> sys.getsizeof(1<<30)
18
>>> sys.getsizeof(1<<16)
16
>>> sys.getsizeof(1<<12345)
1660
>>> sys.getsizeof(1<<123456)
16474
Small numbers are represented more compactly than large ones! And it's
not like in REXX, where all numbers are stored as strings.
Go fork CPython and make the changes you suggest. Then run real-world
code on it and see how it performs. Or at very least, run plausible
benchmarks like the strings benchmark from the standard tests.
My original post about integers was based on two comparisons: Python 2
and Pike. Both languages have an optimization for "small" integers
(where "small" is "within machine word" - on rechecking some of my
stats, I find that I perhaps should have used a larger offset, as the
64-bit Linux Python I used appeared to be a lot faster than it should
have been), which Python 3 doesn't have. Real examples, real
statistics, real discussion. (I didn't include Pike stats in what I
posted, for two reasons: firstly, it would require a reworking of the
code, rather than simply "run this under both interpreters"; and
secondly, Pike performance is completely different from CPython
performance, and is non-comparable. Pike is more similar to PyPy, able
to compile - in certain circumstances - to machine code. So the
comparisons were Py2 vs Py3.)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 10:48 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <7f993624-8105-4055-a268-3417e5fe21dc@g4g2000yqd.googlegroups.com> |
| In reply to | #42167 |
On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > The flexible string representation takes the problem from the > > other side, it attempts to work with the characters by using > > their representations and it (can only) fails... > > This is false. As I've pointed out to you before, the FSR does not > divide characters up by representation. It divides them up by > codepoint -- more specifically, by the *bit-width* of the codepoint. > We call the internal format of the string "ASCII" or "Latin-1" or > "UCS-2" for conciseness and a point of reference, but fundamentally > all of the FSR formats are simply byte arrays of *codepoints* -- you > know, those things you keep harping on. The major optimization > performed by the FSR is to consistently truncate the leading zero > bytes from each codepoint when it is possible to do so safely. But > regardless of to what extent this truncation is applied, the string is > *always* internally just an array of codepoints, and the same > algorithms apply for all representations. ----- You know, we can discuss this ad nauseam. What is important is Unicode. You have transformed Python back in an ascii oriented product. If Python had imlemented Unicode correctly, there would be no difference in using an "a", "é", "€" or any character, what the narrow builds did. If I am practically the only one, who speakes /discusses about this, I can ensure you, this has been noticed. Now, it's time to prepare the Asparagus, the "jambon cru" and a good bottle a dry white wine. jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 04:55 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3905.1364493306.2939.python-list@python.org> |
| In reply to | #42176 |
On Fri, Mar 29, 2013 at 4:48 AM, jmfauth <wxjmfauth@gmail.com> wrote: > If Python had imlemented Unicode correctly, there would > be no difference in using an "a", "é", "€" or any character, > what the narrow builds did. I'm not following your grammar perfectly here, but if Python were implementing Unicode correctly, there would be no difference between any of those characters, which is the way a *wide* build works. With a narrow build, there is a difference between BMP and non-BMP characters. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 13:26 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <e58e23e5-9af9-4baa-bf93-4383d3d490f8@k4g2000yqn.googlegroups.com> |
| In reply to | #42177 |
On 28 mar, 18:55, Chris Angelico <ros...@gmail.com> wrote: > On Fri, Mar 29, 2013 at 4:48 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > If Python had imlemented Unicode correctly, there would > > be no difference in using an "a", "é", "€" or any character, > > what the narrow builds did. > > I'm not following your grammar perfectly here, but if Python were > implementing Unicode correctly, there would be no difference between > any of those characters, which is the way a *wide* build works. With a > narrow build, there is a difference between BMP and non-BMP > characters. > > ChrisA -------- The wide build (I never used) is in my mind as correct as the narrow build. It "just" covers a different range in unicode (the whole range). Claiming that the narrow build is buggy, because it does not cover the whole unicode is not correct. Unicode does not stipulate, one has to cover the whole range. Unicode expects that every character in a range behaves the same way. This is clearly not realized with the flexible string representation. An user should not be somehow penalized simply because it not an ascii user. If you take the fonts in consideration (btw a problem nobody is speaking about) and you ensure your application, toolkit, ... is MES-X or WGL4 compliant, your are also deliberately (and correctly) working with a restriced unicode range. jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-03-29 08:45 +1100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3915.1364507145.2939.python-list@python.org> |
| In reply to | #42189 |
On Fri, Mar 29, 2013 at 7:26 AM, jmfauth <wxjmfauth@gmail.com> wrote: > The wide build (I never used) is in my mind as correct as > the narrow build. It "just" covers a different range in unicode > (the whole range). Actually it does; it covers all of the Unicode range, by using (effectively) UTF-16. Characters that cannot be represented in one 16-bit number are represented in two. That's not "just" covering a different range. It's being buggy. And it's creating a way for code to unexpectedly behave fundamentally differently on Windows and Linux (since the most common builds for Windows were narrow and for Linux were wide). This is a Bad Thing for Python. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-03-28 19:12 -0400 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3922.1364512357.2939.python-list@python.org> |
| In reply to | #42189 |
On 3/28/2013 4:26 PM, jmfauth wrote: Please provide references for your assertions. I have read the unicode standard, parts more than once, and your assertions contradict my memory. > Unicode does not stipulate, one has to cover the whole range. I believe it does. As I remember, the recognized encodings all encode the entire unicode codepoint range > Unicode expects that every character in a range behaves the same > way. I have no idea what you mean by 'same way'. Each codepoint is supposed to behave differently in some way. That is the reason for having multiple codepoints. One causes an 'a' to appear, another a 'b'. Indeed, the standard define multiple categories of codepoints and chars in different categories are supposed to act differently (or be treated differently). Glyphic chars versus control chars are one example. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Kaplan <benjamin.kaplan@case.edu> |
|---|---|
| Date | 2013-03-28 13:29 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3913.1364502948.2939.python-list@python.org> |
| In reply to | #42176 |
On Thu, Mar 28, 2013 at 10:48 AM, jmfauth <wxjmfauth@gmail.com> wrote: > On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: >> > The flexible string representation takes the problem from the >> > other side, it attempts to work with the characters by using >> > their representations and it (can only) fails... >> >> This is false. As I've pointed out to you before, the FSR does not >> divide characters up by representation. It divides them up by >> codepoint -- more specifically, by the *bit-width* of the codepoint. >> We call the internal format of the string "ASCII" or "Latin-1" or >> "UCS-2" for conciseness and a point of reference, but fundamentally >> all of the FSR formats are simply byte arrays of *codepoints* -- you >> know, those things you keep harping on. The major optimization >> performed by the FSR is to consistently truncate the leading zero >> bytes from each codepoint when it is possible to do so safely. But >> regardless of to what extent this truncation is applied, the string is >> *always* internally just an array of codepoints, and the same >> algorithms apply for all representations. > > ----- > > You know, we can discuss this ad nauseam. What is important > is Unicode. > > You have transformed Python back in an ascii oriented product. > > If Python had imlemented Unicode correctly, there would > be no difference in using an "a", "é", "€" or any character, > what the narrow builds did. > > If I am practically the only one, who speakes /discusses about > this, I can ensure you, this has been noticed. > > Now, it's time to prepare the Asparagus, the "jambon cru" > and a good bottle a dry white wine. > > jmf > > You still have yet to explain how Python's string representation is wrong. Just how it isn't optimal for one specific case. Here's how I understand it: 1) Strings are sequences of stuff. Generally, we talk about strings as either sequences of bytes or sequences of characters. 2) Unicode is a format used to represent characters. Therefore, Unicode strings are character strings, not byte strings. 2) Encodings are functions that map characters to bytes. They typically also define an inverse function that converts from bytes back to characters. 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I mentioned in the previous point. It happens to be one of the five standard encodings that is defined for all characters in the Unicode standard (the others being the little and big endian variants of UTF-16 and UTF-32). 4) The internal representation of a character string DOES NOT MATTER. All that matters is that the API represents it as a string of characters, regardless of the representation. We could implement character strings by putting the Unicode code-points in binary-coded decimal and it would be a Unicode character string. 5) The String type that .NET and Java (and unicode type in Python narrow builds) use is not a character string. It is a string of shorts, each of which corresponds to a UTF-16 code point. I know this is the case because in all of these, the length of "\u1f435" is 2 even though it only consists of one character. 6) The new string representation in Python 3.3 can successfully represent all characters in the Unicode standard. The actual number of bytes that each character consumes is invisible to the user.
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 14:11 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <691c604c-b643-4d66-a2ea-c5c52d603316@c6g2000yqh.googlegroups.com> |
| In reply to | #42190 |
On 28 mar, 21:29, Benjamin Kaplan <benjamin.kap...@case.edu> wrote: > On Thu, Mar 28, 2013 at 10:48 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: > >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: > >> > The flexible string representation takes the problem from the > >> > other side, it attempts to work with the characters by using > >> > their representations and it (can only) fails... > > >> This is false. As I've pointed out to you before, the FSR does not > >> divide characters up by representation. It divides them up by > >> codepoint -- more specifically, by the *bit-width* of the codepoint. > >> We call the internal format of the string "ASCII" or "Latin-1" or > >> "UCS-2" for conciseness and a point of reference, but fundamentally > >> all of the FSR formats are simply byte arrays of *codepoints* -- you > >> know, those things you keep harping on. The major optimization > >> performed by the FSR is to consistently truncate the leading zero > >> bytes from each codepoint when it is possible to do so safely. But > >> regardless of to what extent this truncation is applied, the string is > >> *always* internally just an array of codepoints, and the same > >> algorithms apply for all representations. > > > ----- > > > You know, we can discuss this ad nauseam. What is important > > is Unicode. > > > You have transformed Python back in an ascii oriented product. > > > If Python had imlemented Unicode correctly, there would > > be no difference in using an "a", "é", "€" or any character, > > what the narrow builds did. > > > If I am practically the only one, who speakes /discusses about > > this, I can ensure you, this has been noticed. > > > Now, it's time to prepare the Asparagus, the "jambon cru" > > and a good bottle a dry white wine. > > > jmf > > You still have yet to explain how Python's string representation is > wrong. Just how it isn't optimal for one specific case. Here's how I > understand it: > > 1) Strings are sequences of stuff. Generally, we talk about strings as > either sequences of bytes or sequences of characters. > > 2) Unicode is a format used to represent characters. Therefore, > Unicode strings are character strings, not byte strings. > > 2) Encodings are functions that map characters to bytes. They > typically also define an inverse function that converts from bytes > back to characters. > > 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I > mentioned in the previous point. It happens to be one of the five > standard encodings that is defined for all characters in the Unicode > standard (the others being the little and big endian variants of > UTF-16 and UTF-32). > > 4) The internal representation of a character string DOES NOT MATTER. > All that matters is that the API represents it as a string of > characters, regardless of the representation. We could implement > character strings by putting the Unicode code-points in binary-coded > decimal and it would be a Unicode character string. > > 5) The String type that .NET and Java (and unicode type in Python > narrow builds) use is not a character string. It is a string of > shorts, each of which corresponds to a UTF-16 code point. I know this > is the case because in all of these, the length of "\u1f435" is 2 even > though it only consists of one character. > > 6) The new string representation in Python 3.3 can successfully > represent all characters in the Unicode standard. The actual number of > bytes that each character consumes is invisible to the user. ---------- I shew enough examples. As soon as you are using non latin-1 chars your "optimization" just became irrelevant and not only this, you are penalized. I'm sorry, saying Python now is just covering the whole unicode range is not a valuable excuse. I prefer a "correct" version with a narrower range of chars, especially if this range represents the "daily used chars". I can go a step further, if I wish to write an application for Western European users, I'm better served if I'm using a coding scheme covering all thesee languages/scripts. What about cp1252 [*]? Does this not remind somthing? Python can do better, it only succeeds to do worth! [*] yes, I kwnow, internally .... jmf
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-28 14:33 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <88e569e8-9631-47df-a327-da52addb0ee7@k14g2000vbv.googlegroups.com> |
| In reply to | #42193 |
On 28 mar, 22:11, jmfauth <wxjmfa...@gmail.com> wrote: > On 28 mar, 21:29, Benjamin Kaplan <benjamin.kap...@case.edu> wrote: > > > > > > > > > > > On Thu, Mar 28, 2013 at 10:48 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > > On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: > > >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: > > >> > The flexible string representation takes the problem from the > > >> > other side, it attempts to work with the characters by using > > >> > their representations and it (can only) fails... > > > >> This is false. As I've pointed out to you before, the FSR does not > > >> divide characters up by representation. It divides them up by > > >> codepoint -- more specifically, by the *bit-width* of the codepoint. > > >> We call the internal format of the string "ASCII" or "Latin-1" or > > >> "UCS-2" for conciseness and a point of reference, but fundamentally > > >> all of the FSR formats are simply byte arrays of *codepoints* -- you > > >> know, those things you keep harping on. The major optimization > > >> performed by the FSR is to consistently truncate the leading zero > > >> bytes from each codepoint when it is possible to do so safely. But > > >> regardless of to what extent this truncation is applied, the string is > > >> *always* internally just an array of codepoints, and the same > > >> algorithms apply for all representations. > > > > ----- > > > > You know, we can discuss this ad nauseam. What is important > > > is Unicode. > > > > You have transformed Python back in an ascii oriented product. > > > > If Python had imlemented Unicode correctly, there would > > > be no difference in using an "a", "é", "€" or any character, > > > what the narrow builds did. > > > > If I am practically the only one, who speakes /discusses about > > > this, I can ensure you, this has been noticed. > > > > Now, it's time to prepare the Asparagus, the "jambon cru" > > > and a good bottle a dry white wine. > > > > jmf > > > You still have yet to explain how Python's string representation is > > wrong. Just how it isn't optimal for one specific case. Here's how I > > understand it: > > > 1) Strings are sequences of stuff. Generally, we talk about strings as > > either sequences of bytes or sequences of characters. > > > 2) Unicode is a format used to represent characters. Therefore, > > Unicode strings are character strings, not byte strings. > > > 2) Encodings are functions that map characters to bytes. They > > typically also define an inverse function that converts from bytes > > back to characters. > > > 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I > > mentioned in the previous point. It happens to be one of the five > > standard encodings that is defined for all characters in the Unicode > > standard (the others being the little and big endian variants of > > UTF-16 and UTF-32). > > > 4) The internal representation of a character string DOES NOT MATTER. > > All that matters is that the API represents it as a string of > > characters, regardless of the representation. We could implement > > character strings by putting the Unicode code-points in binary-coded > > decimal and it would be a Unicode character string. > > > 5) The String type that .NET and Java (and unicode type in Python > > narrow builds) use is not a character string. It is a string of > > shorts, each of which corresponds to a UTF-16 code point. I know this > > is the case because in all of these, the length of "\u1f435" is 2 even > > though it only consists of one character. > > > 6) The new string representation in Python 3.3 can successfully > > represent all characters in the Unicode standard. The actual number of > > bytes that each character consumes is invisible to the user. > > ---------- > > I shew enough examples. As soon as you are using non latin-1 chars > your "optimization" just became irrelevant and not only this, you > are penalized. > > I'm sorry, saying Python now is just covering the whole unicode > range is not a valuable excuse. I prefer a "correct" version with > a narrower range of chars, especially if this range represents > the "daily used chars". > > I can go a step further, if I wish to write an application for > Western European users, I'm better served if I'm using a coding > scheme covering all thesee languages/scripts. What about cp1252 [*]? > Does this not remind somthing? > > Python can do better, it only succeeds to do worth! > > [*] yes, I kwnow, internally .... > > jmf ----- Addendum. And you kwow what? Py34 will suffer from the same desease. You are spending your time in improving chunks of bytes, when the problem is elsewhere. In fact you are working for peanuts, eg the replacing method. If you are not satisfied with my examples, just pick up the examples of GvR (ascii-string) on the bug tracker, "timeit" them and you will see there is already a problem. Better, "timeit" them afeter having replaced his ascii-strings with non ascii characters... jmf and you will see, there is
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2013-03-28 21:50 +0000 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3916.1364507414.2939.python-list@python.org> |
| In reply to | #42193 |
On 28/03/2013 21:11, jmfauth wrote: > On 28 mar, 21:29, Benjamin Kaplan <benjamin.kap...@case.edu> wrote: >> On Thu, Mar 28, 2013 at 10:48 AM, jmfauth <wxjmfa...@gmail.com> wrote: >> > On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: >> >> > The flexible string representation takes the problem from the >> >> > other side, it attempts to work with the characters by using >> >> > their representations and it (can only) fails... >> >> >> This is false. As I've pointed out to you before, the FSR does not >> >> divide characters up by representation. It divides them up by >> >> codepoint -- more specifically, by the *bit-width* of the codepoint. >> >> We call the internal format of the string "ASCII" or "Latin-1" or >> >> "UCS-2" for conciseness and a point of reference, but fundamentally >> >> all of the FSR formats are simply byte arrays of *codepoints* -- you >> >> know, those things you keep harping on. The major optimization >> >> performed by the FSR is to consistently truncate the leading zero >> >> bytes from each codepoint when it is possible to do so safely. But >> >> regardless of to what extent this truncation is applied, the string is >> >> *always* internally just an array of codepoints, and the same >> >> algorithms apply for all representations. >> >> > ----- >> >> > You know, we can discuss this ad nauseam. What is important >> > is Unicode. >> >> > You have transformed Python back in an ascii oriented product. >> >> > If Python had imlemented Unicode correctly, there would >> > be no difference in using an "a", "é", "€" or any character, >> > what the narrow builds did. >> >> > If I am practically the only one, who speakes /discusses about >> > this, I can ensure you, this has been noticed. >> >> > Now, it's time to prepare the Asparagus, the "jambon cru" >> > and a good bottle a dry white wine. >> >> > jmf >> >> You still have yet to explain how Python's string representation is >> wrong. Just how it isn't optimal for one specific case. Here's how I >> understand it: >> >> 1) Strings are sequences of stuff. Generally, we talk about strings as >> either sequences of bytes or sequences of characters. >> >> 2) Unicode is a format used to represent characters. Therefore, >> Unicode strings are character strings, not byte strings. >> >> 2) Encodings are functions that map characters to bytes. They >> typically also define an inverse function that converts from bytes >> back to characters. >> >> 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I >> mentioned in the previous point. It happens to be one of the five >> standard encodings that is defined for all characters in the Unicode >> standard (the others being the little and big endian variants of >> UTF-16 and UTF-32). >> >> 4) The internal representation of a character string DOES NOT MATTER. >> All that matters is that the API represents it as a string of >> characters, regardless of the representation. We could implement >> character strings by putting the Unicode code-points in binary-coded >> decimal and it would be a Unicode character string. >> >> 5) The String type that .NET and Java (and unicode type in Python >> narrow builds) use is not a character string. It is a string of >> shorts, each of which corresponds to a UTF-16 code point. I know this >> is the case because in all of these, the length of "\u1f435" is 2 even >> though it only consists of one character. >> >> 6) The new string representation in Python 3.3 can successfully >> represent all characters in the Unicode standard. The actual number of >> bytes that each character consumes is invisible to the user. > > ---------- > > > I shew enough examples. As soon as you are using non latin-1 chars > your "optimization" just became irrelevant and not only this, you > are penalized. > > I'm sorry, saying Python now is just covering the whole unicode > range is not a valuable excuse. I prefer a "correct" version with > a narrower range of chars, especially if this range represents > the "daily used chars". > > I can go a step further, if I wish to write an application for > Western European users, I'm better served if I'm using a coding > scheme covering all thesee languages/scripts. What about cp1252 [*]? > Does this not remind somthing? > > Python can do better, it only succeeds to do worth! > > [*] yes, I kwnow, internally .... > If you're that concerned about it, why don't you modify the source code so that the string representation chooses between only 2 bytes and 4 bytes per codepoint, and then see whether that you prefer that situation. How do the memory usage and speed compare?
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Kaplan <benjamin.kaplan@case.edu> |
|---|---|
| Date | 2013-03-28 14:52 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3917.1364507551.2939.python-list@python.org> |
| In reply to | #42193 |
On Thu, Mar 28, 2013 at 2:11 PM, jmfauth <wxjmfauth@gmail.com> wrote: > On 28 mar, 21:29, Benjamin Kaplan <benjamin.kap...@case.edu> wrote: >> On Thu, Mar 28, 2013 at 10:48 AM, jmfauth <wxjmfa...@gmail.com> wrote: >> > On 28 mar, 17:33, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> >> On Thu, Mar 28, 2013 at 7:34 AM, jmfauth <wxjmfa...@gmail.com> wrote: >> >> > The flexible string representation takes the problem from the >> >> > other side, it attempts to work with the characters by using >> >> > their representations and it (can only) fails... >> >> >> This is false. As I've pointed out to you before, the FSR does not >> >> divide characters up by representation. It divides them up by >> >> codepoint -- more specifically, by the *bit-width* of the codepoint. >> >> We call the internal format of the string "ASCII" or "Latin-1" or >> >> "UCS-2" for conciseness and a point of reference, but fundamentally >> >> all of the FSR formats are simply byte arrays of *codepoints* -- you >> >> know, those things you keep harping on. The major optimization >> >> performed by the FSR is to consistently truncate the leading zero >> >> bytes from each codepoint when it is possible to do so safely. But >> >> regardless of to what extent this truncation is applied, the string is >> >> *always* internally just an array of codepoints, and the same >> >> algorithms apply for all representations. >> >> > ----- >> >> > You know, we can discuss this ad nauseam. What is important >> > is Unicode. >> >> > You have transformed Python back in an ascii oriented product. >> >> > If Python had imlemented Unicode correctly, there would >> > be no difference in using an "a", "é", "€" or any character, >> > what the narrow builds did. >> >> > If I am practically the only one, who speakes /discusses about >> > this, I can ensure you, this has been noticed. >> >> > Now, it's time to prepare the Asparagus, the "jambon cru" >> > and a good bottle a dry white wine. >> >> > jmf >> >> You still have yet to explain how Python's string representation is >> wrong. Just how it isn't optimal for one specific case. Here's how I >> understand it: >> >> 1) Strings are sequences of stuff. Generally, we talk about strings as >> either sequences of bytes or sequences of characters. >> >> 2) Unicode is a format used to represent characters. Therefore, >> Unicode strings are character strings, not byte strings. >> >> 2) Encodings are functions that map characters to bytes. They >> typically also define an inverse function that converts from bytes >> back to characters. >> >> 3) UTF-8 IS NOT UNICODE. It is an encoding- one of those functions I >> mentioned in the previous point. It happens to be one of the five >> standard encodings that is defined for all characters in the Unicode >> standard (the others being the little and big endian variants of >> UTF-16 and UTF-32). >> >> 4) The internal representation of a character string DOES NOT MATTER. >> All that matters is that the API represents it as a string of >> characters, regardless of the representation. We could implement >> character strings by putting the Unicode code-points in binary-coded >> decimal and it would be a Unicode character string. >> >> 5) The String type that .NET and Java (and unicode type in Python >> narrow builds) use is not a character string. It is a string of >> shorts, each of which corresponds to a UTF-16 code point. I know this >> is the case because in all of these, the length of "\u1f435" is 2 even >> though it only consists of one character. >> >> 6) The new string representation in Python 3.3 can successfully >> represent all characters in the Unicode standard. The actual number of >> bytes that each character consumes is invisible to the user. > > ---------- > > > I shew enough examples. As soon as you are using non latin-1 chars > your "optimization" just became irrelevant and not only this, you > are penalized. > > I'm sorry, saying Python now is just covering the whole unicode > range is not a valuable excuse. I prefer a "correct" version with > a narrower range of chars, especially if this range represents > the "daily used chars". > > I can go a step further, if I wish to write an application for > Western European users, I'm better served if I'm using a coding > scheme covering all thesee languages/scripts. What about cp1252 [*]? > Does this not remind somthing? > > Python can do better, it only succeeds to do worth! > > [*] yes, I kwnow, internally .... > > jmf By that logic, we should all be using ASCII because it's "correct" for the 127 characters that I (as an English speaker) use, and therefore it's all that we should care about. I don't care if é counts as two characters, it's faster and more memory efficient for all of my strings to just count bytes. There are certain domains where characters outside the basic multilingual plane are used. Python's job is to be correct in all of those circumstances, not just the ones you care about.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-03-28 19:53 -0400 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.3925.1364514854.2939.python-list@python.org> |
| In reply to | #42078 |
On Wed, 27 Mar 2013 23:12:21 -0700, Ethan Furman <ethan@stoneleaf.us>
declaimed the following in gmane.comp.python.general:
>
> At some point we have to stop being gentle / polite / politically correct and call a shovel a shovel... er, spade.
Call it an Instrument For the Transplantation of Dirt
(Is an antique Steam Shovel ever a Steam Spade?)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web