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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-03-31 00:35 -0700 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <f34a1c9a-57a3-45fd-b7e0-c33d06e02335@j9g2000vbz.googlegroups.com> |
| In reply to | #42294 |
------
Neil Hodgson:
"The counter-problem is that a French document that needs to include
one mathematical symbol (or emoji) outside Latin-1 will double in size
as a Python string."
Serious developers/typographers/users know that you can not compose
a text in French with "latin-1". This is now also the case with
German (Germany).
---
Neil's comment is correct,
>>> sys.getsizeof('a' * 1000 + 'z')
1026
>>> sys.getsizeof('a' * 1000 + '€')
2040
This is not really the problem. "Serious users" may
notice sooner or later, Python and Unicode are walking in
opposite directions (technically and in spirit).
>>> timeit.repeat("'a' * 1000 + 'ẞ'")
[1.1088995672090292, 1.0842266613261913, 1.1010779011941594]
>>> timeit.repeat("'a' * 1000 + 'z'")
[0.6362570846925735, 0.6159128762502917, 0.6200501673623791]
(Just an opinion)
jmf
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-03-31 08:22 +0000 |
| Subject | ASCII versus non-ASCII [was Re: flaming vs accuracy [was Re: Performance of int/long in Python 3]] |
| Message-ID | <5157f258$0$29974$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42360 |
On Sun, 31 Mar 2013 00:35:23 -0700, jmfauth wrote:
> This is not really the problem. "Serious users" may notice sooner or
> later, Python and Unicode are walking in opposite directions
> (technically and in spirit).
>
>>>> timeit.repeat("'a' * 1000 + 'ẞ'")
> [1.1088995672090292, 1.0842266613261913, 1.1010779011941594]
>>>> timeit.repeat("'a' * 1000 + 'z'")
> [0.6362570846925735, 0.6159128762502917, 0.6200501673623791]
Perhaps you should stick to Python 3.2, where ASCII strings are no faster
than non-ASCII strings.
Python 3.2 versus Python 3.3, no significant difference:
# 3.2
py> timeit.repeat("'a' * 1000 + 'ẞ'")
[1.7418999671936035, 1.7198870182037354, 1.763346004486084]
# 3.3
py> timeit.repeat("'a' * 1000 + 'ẞ'")
[1.8083378580026329, 1.818592812011484, 1.7922867869958282]
Python 3.2, ASCII vs Non-ASCII:
py> timeit.repeat("'a' * 1000 + 'z'")
[1.756322135925293, 1.8002049922943115, 1.721085958480835]
py> timeit.repeat("'a' * 1000 + 'ẞ'")
[1.7209150791168213, 1.7162668704986572, 1.7260780334472656]
In other words, if you stick to non-ASCII strings, Python 3.3 is no
slower than Python 3.2.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-03-31 13:55 +0100 |
| Subject | Re: flaming vs accuracy [was Re: Performance of int/long in Python 3] |
| Message-ID | <mailman.4013.1364734495.2939.python-list@python.org> |
| In reply to | #42360 |
On 31/03/2013 08:35, jmfauth wrote:
> ------
>
> Neil Hodgson:
>
> "The counter-problem is that a French document that needs to include
> one mathematical symbol (or emoji) outside Latin-1 will double in size
> as a Python string."
>
> Serious developers/typographers/users know that you can not compose
> a text in French with "latin-1". This is now also the case with
> German (Germany).
>
> ---
>
> Neil's comment is correct,
>
>>>> sys.getsizeof('a' * 1000 + 'z')
> 1026
>>>> sys.getsizeof('a' * 1000 + '€')
> 2040
>
> This is not really the problem. "Serious users" may
> notice sooner or later, Python and Unicode are walking in
> opposite directions (technically and in spirit).
>
>>>> timeit.repeat("'a' * 1000 + 'ẞ'")
> [1.1088995672090292, 1.0842266613261913, 1.1010779011941594]
>>>> timeit.repeat("'a' * 1000 + 'z'")
> [0.6362570846925735, 0.6159128762502917, 0.6200501673623791]
>
>
> (Just an opinion)
>
> jmf
>
I'm feeling very sorry for this horse, it's been flogged so often it's
down to bare bones.
--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.
Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-03-31 22:33 -0700 |
| Message-ID | <6a146aba-a032-4aac-b2d3-7acedcebd804@q3g2000pbv.googlegroups.com> |
| In reply to | #42366 |
On Mar 31, 5:55 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote: <snipped jmf's broken-record whine> > I'm feeling very sorry for this horse, it's been flogged so often it's > down to bare bones. While I am now joining the camp of those fed up with jmf's whining, I do wonder if we are shooting the messenger… From a recent Roy mysqldb-unicode thread: > My unicode-fu is a bit weak. Are we looking at a Python problem, a > MySQLdb problem, or a problem with the underlying MySQL server? We've > certainly inserted utf-8 data before without any problems. It's > possible this is the first time we've tried to handle a character > outside the BMP. : : > OK, that leads to the next question. Is there anyway I can (in Python > 2.7) detect when a string is not entirely in the BMP? If I could find > all the non-BMP characters, I could replace them with U+FFFD > (REPLACEMENT CHARACTER) and life would be good (enough). Steven's: > But it means that if you're one of the 99.9% of users who mostly use > characters in the BMP, … And from http://www.tlg.uci.edu/~opoudjis/unicode/unicode_astral.html > The informal name for the supplementary planes of Unicode is "astral planes", since > (especially in the late '90s) their use seemed to be as remote as > the theosophical "great beyond". … > As of this writing for instance, Dreamweaver MX for MacOSX (which I am currently using > to prepare this) will let you paste BMP text into its WYSIWYG window; but pasting > Supplementary Plane text there will make it crash. So I really wonder: Is python losing more by supporting SMP with performance hit on BMP? The problem as I see it is that a choice that is sufficiently skew is no more a straightforward choice. An example will illustrate: I can choose to drive or not -- a choice. Statistics tell me that on average there are 3 fatalities every day; I am very concerned that I could get killed so I choose not to drive. Which neglects that there are a couple of million safe-drives at the same time as the '3 fatalities' [What if anything this has to do with jmf's rants I dont know because I dont know if anyone (including jmf) knows what he is ranting about. ]
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-03-31 23:52 -0600 |
| Message-ID | <mailman.4048.1364795616.2939.python-list@python.org> |
| In reply to | #42443 |
On Sun, Mar 31, 2013 at 11:33 PM, rusi <rustompmody@gmail.com> wrote: > > So I really wonder: Is python losing more by supporting SMP with > performance hit on BMP? I don't believe so. Although performance is undeniably worse for some benchmarks, it is also better for some others. Nobody has yet demonstrated an actual, real-world program that is affected negatively by the Unicode change. All of jmf's complaints amount to cherry-picking data and leaping to conclusions.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-01 16:57 +1100 |
| Message-ID | <mailman.4049.1364795879.2939.python-list@python.org> |
| In reply to | #42443 |
On Mon, Apr 1, 2013 at 4:33 PM, rusi <rustompmody@gmail.com> wrote: > So I really wonder: Is python losing more by supporting SMP with > performance hit on BMP? If your strings fit entirely within the BMP, then you should see no penalty compared to previous versions of Python. If they happen to fit inside ASCII, then there may well be significant improvements. But regardless, what you gain is the ability to work with *any* string, regardless of its content, without worrying about it. You can count characters regardless of their content. Imagine if a tuple of integers behaved differently if some of those integers flipped to being long ints: x = (1, 2, 4, 8, 1<<30, 1<<300, 1<<10) Wouldn't you be surprised if len(x) returned 8? I certainly would be. And that's what a narrow build of Python does with Unicode. Unicode strings are approximately comparable to tuples of integers. In fact, they can be interchanged fairly readily: string = "Treble clef: \U0001D11E" array = tuple(map(ord,string)) assert(len(array) == 14) out_string = ''.join(map(chr,array)) assert(out_string == string) This doesn't work in Python 2.6 on Windows, partly because of surrogates, but also because chr() isn't designed for Unicode strings. There's probably a solution to the second, but not really to the first. The tuple of ords should match the way the characters are laid out to a human. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-01 08:14 +0000 |
| Message-ID | <515941d8$0$29967$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42443 |
On Sun, 31 Mar 2013 22:33:45 -0700, rusi wrote: > On Mar 31, 5:55 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote: > > <snipped jmf's broken-record whine> > >> I'm feeling very sorry for this horse, it's been flogged so often it's >> down to bare bones. > > While I am now joining the camp of those fed up with jmf's whining, I do > wonder if we are shooting the messenger… No. The trouble is that the messenger is shouting that the Unicode world is ending on December 21st 2012, and hasn't noticed that was over three months ago and the world didn't end. [...] >> OK, that leads to the next question. Is there anyway I can (in Python >> 2.7) detect when a string is not entirely in the BMP? If I could find >> all the non-BMP characters, I could replace them with U+FFFD >> (REPLACEMENT CHARACTER) and life would be good (enough). Of course you can do this, but you should not. If your input data includes character C, you should deal with character C and not just throw it away unnecessarily. That would be rude, and in Python 3.3 it should be unnecessary. Although, since the person you are quoting is stuck in Python 2.7, it may be less bad than having to deal with potentially broken Unicode strings. > Steven's: >> But it means that if you're one of the 99.9% of users who mostly use >> characters in the BMP, … Yes. "Mostly" does not mean exclusively, and given (say) a billion computer users, that leaves about a million users who have significant need for non-BMP characters. If you don't agree with my estimate, feel free to invent your own :-) > And from http://www.tlg.uci.edu/~opoudjis/unicode/unicode_astral.html >> The informal name for the supplementary planes of Unicode is "astral >> planes", since (especially in the late '90s) their use seemed to be as >> remote as the theosophical "great beyond". … That was nearly two decades ago. Two decades ago, the idea that the entire computing world could standardize on a single character set, instead of having to deal with dozens of different "code pages", seemed as likely as people landing on the Moon seemed in 1940. Today, the entire computing world has standardized on such a system, "code pages" (encodings) are mostly only needed for legacy data and shitty applications, but most implementations don't support the entire Unicode range. A couple of programming languages, including Pike and Python, support Unicode fully and correctly. Pike has never had the same high-profile as Python, but now that Python can support the entire Unicode range without broken surrogate support, maybe users of other languages will start to demand the same. > So I really wonder: Is python losing more by supporting SMP with > performance hit on BMP? No. As many people have demonstrated, both with code snippets and whole- program benchmarks, Python 3.3 is *as fast* or *faster* than Python 3.2 narrow builds. In practice, Python 3.3 saves enough memory by using sensible string implementations that real world software is faster in Python 3.3 than in 3.2. > The problem as I see it is that a choice that is sufficiently skew is no > more a straightforward choice. An example will illustrate: > > I can choose to drive or not -- a choice. Statistics tell me that on > average there are 3 fatalities every day; I am very concerned that I > could get killed so I choose not to drive. Which neglects that there are > a couple of million safe-drives at the same time as the '3 fatalities' Clear as mud. What does this have to do with supporting Unicode? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-01 08:15 -0400 |
| Message-ID | <roy-04FB84.08155301042013@news.panix.com> |
| In reply to | #42450 |
In article <515941d8$0$29967$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> [...]
> >> OK, that leads to the next question. Is there anyway I can (in Python
> >> 2.7) detect when a string is not entirely in the BMP? If I could find
> >> all the non-BMP characters, I could replace them with U+FFFD
> >> (REPLACEMENT CHARACTER) and life would be good (enough).
>
> Of course you can do this, but you should not. If your input data
> includes character C, you should deal with character C and not just throw
> it away unnecessarily. That would be rude, and in Python 3.3 it should be
> unnecessary.
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.
It turns out, the problem is that the version of MySQL we're using
doesn't support non-BMP characters. Newer versions do (but you have to
declare the column to use the utf8bm4 character set). I could upgrade
to a newer MySQL version, but it's just not worth it.
Actually, I did try spinning up a 5.5 instance (one of the nice things
of being in the cloud) and experimented with that, but couldn't get it
to work there either. I'll admit that I didn't invest a huge amount of
effort to make that work before just writing this:
def bmp_filter(self, s):
"""Filter a unicode string to remove all non-BMP (basic
multilingual plane) characters. All such characters are
replaced with U+FFFD (Unicode REPLACEMENT CHARACTER).
"""
if all(ord(c) <= 0xffff for c in s):
return s
else:
self.logger.warning("making %r BMP-clean", s)
bmp_chars = [(c if ord(c) <= 0xffff else u'\ufffd') for c in
s]
return ''.join(bmp_chars)
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-01 06:11 -0700 |
| Message-ID | <2bfc9e3f-cddc-4c65-a9b9-fc9794f57d86@9g2000pba.googlegroups.com> |
| In reply to | #42460 |
On Apr 1, 5:15 pm, Roy Smith <r...@panix.com> wrote: > In article <515941d8$0$29967$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > > > [...] > > >> OK, that leads to the next question. Is there anyway I can (in Python > > >> 2.7) detect when a string is not entirely in the BMP? If I could find > > >> all the non-BMP characters, I could replace them with U+FFFD > > >> (REPLACEMENT CHARACTER) and life would be good (enough). > > > Of course you can do this, but you should not. If your input data > > includes character C, you should deal with character C and not just throw > > it away unnecessarily. That would be rude, and in Python 3.3 it should be > > unnecessary. > > 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. That works out to 0.000003%. Of course I assume it is US only data. Still its good to know how skew the distribution is.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-01 17:02 +0000 |
| Message-ID | <5159bdab$0$29967$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42462 |
On Mon, 01 Apr 2013 06:11:50 -0700, rusi wrote: > On Apr 1, 5:15 pm, Roy Smith <r...@panix.com> 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. > > That works out to 0.000003%. Of course I assume it is US only data. > Still its good to know how skew the distribution is. If the data included Japanese names, or used Emoji, it would be much closer to 100% than 0.000003%. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-01 17:07 +0000 |
| Message-ID | <5159beb6$0$29967$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42460 |
On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote: > In article <515941d8$0$29967$c3e8da3$5496439d@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > >> [...] >> >> OK, that leads to the next question. Is there anyway I can (in >> >> Python 2.7) detect when a string is not entirely in the BMP? If I >> >> could find all the non-BMP characters, I could replace them with >> >> U+FFFD (REPLACEMENT CHARACTER) and life would be good (enough). >> >> Of course you can do this, but you should not. If your input data >> includes character C, you should deal with character C and not just >> throw it away unnecessarily. That would be rude, and in Python 3.3 it >> should be unnecessary. > > 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. > It turns out, the problem is that the version of MySQL we're using Well there you go. Why don't you use a real database? http://www.postgresql.org/docs/9.2/static/multibyte.html :-) Postgresql has supported non-broken UTF-8 since at least version 8.1. > doesn't support non-BMP characters. Newer versions do (but you have to > declare the column to use the utf8bm4 character set). I could upgrade > to a newer MySQL version, but it's just not worth it. My brain just broke. So-called "UTF-8" in MySQL only includes up to a maximum of three-byte characters. There has *never* been a time where UTF-8 excluded four-byte characters. What were the developers thinking, arbitrarily cutting out support for 50% of UTF-8? > Actually, I did try spinning up a 5.5 instance (one of the nice things > of being in the cloud) and experimented with that, but couldn't get it > to work there either. I'll admit that I didn't invest a huge amount of > effort to make that work before just writing this: > > def bmp_filter(self, s): > """Filter a unicode string to remove all non-BMP (basic > multilingual plane) characters. All such characters are > replaced with U+FFFD (Unicode REPLACEMENT CHARACTER). > > """ I expect that in 5-10 years, applications that remove or mangle non-BMP characters will be considered as unacceptable as applications that mangle BMP characters. Or for that matter, applications that cannot handle names with apostrophes. Hell, if your customer base is in Asia, chances are that mangling non-BMP characters is *already* considered unacceptable. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-02 04:20 +1100 |
| Message-ID | <mailman.2.1364836833.17481.python-list@python.org> |
| In reply to | #42470 |
On Tue, Apr 2, 2013 at 4:07 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote: >> It turns out, the problem is that the version of MySQL we're using > > Well there you go. Why don't you use a real database? > > http://www.postgresql.org/docs/9.2/static/multibyte.html > > :-) > > Postgresql has supported non-broken UTF-8 since at least version 8.1. Not only that, but I *rely* on PostgreSQL to test-or-reject stuff that comes from untrustworthy languages, like PHP. If it's malformed in any way, it won't get past the database. >> doesn't support non-BMP characters. Newer versions do (but you have to >> declare the column to use the utf8bm4 character set). I could upgrade >> to a newer MySQL version, but it's just not worth it. > > My brain just broke. So-called "UTF-8" in MySQL only includes up to a > maximum of three-byte characters. There has *never* been a time where > UTF-8 excluded four-byte characters. What were the developers thinking, > arbitrarily cutting out support for 50% of UTF-8? Steven, you punctuated that wrongly. What, were the developers *thinking*? Arbitrarily etc? It really is brain-breaking. I could understand a naive UTF-8 codec being too permissive (allowing over-long encodings, allowing codepoints above what's allocated (eg FA 80 80 80 80, which would notionally represent U+2000000), etc), but why should it arbitrarily stop short? There must have been some internal limitation - that, perhaps, collation was defined only within the BMP. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | MRAB <python@mrabarnett.plus.com> |
|---|---|
| Date | 2013-04-01 18:53 +0100 |
| Message-ID | <mailman.5.1364838820.17481.python-list@python.org> |
| In reply to | #42470 |
On 01/04/2013 18:07, Steven D'Aprano wrote: > On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote: > >> In article <515941d8$0$29967$c3e8da3$5496439d@news.astraweb.com>, >> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >> >>> [...] >>> >> OK, that leads to the next question. Is there anyway I can (in >>> >> Python 2.7) detect when a string is not entirely in the BMP? If I >>> >> could find all the non-BMP characters, I could replace them with >>> >> U+FFFD (REPLACEMENT CHARACTER) and life would be good (enough). >>> >>> Of course you can do this, but you should not. If your input data >>> includes character C, you should deal with character C and not just >>> throw it away unnecessarily. That would be rude, and in Python 3.3 it >>> should be unnecessary. >> >> 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. > > >> It turns out, the problem is that the version of MySQL we're using > > Well there you go. Why don't you use a real database? > > http://www.postgresql.org/docs/9.2/static/multibyte.html > > :-) > > Postgresql has supported non-broken UTF-8 since at least version 8.1. > > >> doesn't support non-BMP characters. Newer versions do (but you have to >> declare the column to use the utf8bm4 character set). I could upgrade >> to a newer MySQL version, but it's just not worth it. > > My brain just broke. So-called "UTF-8" in MySQL only includes up to a > maximum of three-byte characters. There has *never* been a time where > UTF-8 excluded four-byte characters. What were the developers thinking, > arbitrarily cutting out support for 50% of UTF-8? > [snip] 50%? The BMP is one of 17 planes, so wouldn't that be 94%?
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-01 12:15 -0700 |
| Message-ID | <4103dc28-a0dc-4740-bb38-b6bcb58bedfb@h1g2000vbx.googlegroups.com> |
| In reply to | #42475 |
---------
I'm not whining or and I'm not complaining (and never did).
I always exposed facts.
I'm not especially interested in Python, I'm interested in
Unicode.
Usualy when I posted examples, there are confirmed.
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.
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.
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).
jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-02 06:28 +1100 |
| Message-ID | <mailman.11.1364844536.17481.python-list@python.org> |
| In reply to | #42485 |
On Tue, Apr 2, 2013 at 6:15 AM, jmfauth <wxjmfauth@gmail.com> wrote:
> 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]
This is what's called a microbenchmark. Can you show me any instance
in production code where an operation like this is done repeatedly, in
a time-critical place? It's a contrived example, and it's usually
possible to find regressions in any system if you fiddle enough with
the example. Do you have, for instance, a web server that can handle
1000 tps on 3.2 and only 600 tps on 3.3, all other things being equal?
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-01 13:28 -0700 |
| Message-ID | <ba4dc276-a3a4-4dc5-a1a8-8345174cbe7a@he10g2000vbb.googlegroups.com> |
| In reply to | #42487 |
On 1 avr, 21:28, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 6:15 AM, jmfauth <wxjmfa...@gmail.com> wrote:
> > 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]
>
> This is what's called a microbenchmark. Can you show me any instance
> in production code where an operation like this is done repeatedly, in
> a time-critical place? It's a contrived example, and it's usually
> possible to find regressions in any system if you fiddle enough with
> the example. Do you have, for instance, a web server that can handle
> 1000 tps on 3.2 and only 600 tps on 3.3, all other things being equal?
>
> ChrisA
-----
Of course this is an example, as many I gave. Examples you may find in
apps.
Can you point and give at least a bunch of examples, showing
there is no regression, at least to contradict me. The only
one I succeed to see (in month), is the one given by Steven, a status
quo.
I will happily accept them. The only think I read is "this is faster",
"it has been tested", ...
jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-02 07:35 +1100 |
| Message-ID | <mailman.17.1364848545.17481.python-list@python.org> |
| In reply to | #42497 |
On Tue, Apr 2, 2013 at 7:28 AM, jmfauth <wxjmfauth@gmail.com> wrote: > Of course this is an example, as many I gave. Examples you may find in > apps. > Show me an *entire app* that suffers. Show me one. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-01 22:38 +0100 |
| Message-ID | <mailman.18.1364852207.17481.python-list@python.org> |
| In reply to | #42497 |
On 01/04/2013 21:35, Chris Angelico wrote: > On Tue, Apr 2, 2013 at 7:28 AM, jmfauth <wxjmfauth@gmail.com> wrote: >> Of course this is an example, as many I gave. Examples you may find in >> apps. >> > > Show me an *entire app* that suffers. > > Show me one. > > ChrisA > Please don't hold your breath. -- 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 22:43 +0100 |
| Message-ID | <mailman.19.1364852532.17481.python-list@python.org> |
| In reply to | #42497 |
On 01/04/2013 21:28, jmfauth wrote:
> On 1 avr, 21:28, Chris Angelico <ros...@gmail.com> wrote:
>> On Tue, Apr 2, 2013 at 6:15 AM, jmfauth <wxjmfa...@gmail.com> wrote:
>>> 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]
>>
>> This is what's called a microbenchmark. Can you show me any instance
>> in production code where an operation like this is done repeatedly, in
>> a time-critical place? It's a contrived example, and it's usually
>> possible to find regressions in any system if you fiddle enough with
>> the example. Do you have, for instance, a web server that can handle
>> 1000 tps on 3.2 and only 600 tps on 3.3, all other things being equal?
>>
>> ChrisA
>
> -----
>
> Of course this is an example, as many I gave. Examples you may find in
> apps.
You've given many examples of the same type of micro benchmark, not many
examples of different types of benchmark.
>
> Can you point and give at least a bunch of examples, showing
> there is no regression, at least to contradict me. The only
> one I succeed to see (in month), is the one given by Steven, a status
> quo.
Once again you deliberately choose to ignore the memory saving and
correctness to concentrate on the performance slowdown in some cases.
>
> I will happily accept them. The only think I read is "this is faster",
> "it has been tested", ...
>
I do not believe that you will ever accept any facts unless you yourself
provide them.
> jmf
>
--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.
Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Neil Hodgson <nhodgson@iinet.net.au> |
|---|---|
| Date | 2013-04-02 10:43 +1100 |
| Message-ID | <Y5adnc_9yJMbgcfMnZ2dnUVZ_s2dnZ2d@westnet.com.au> |
| In reply to | #42505 |
Mark Lawrence:
> You've given many examples of the same type of micro benchmark, not many
> examples of different types of benchmark.
Trying to work out what jmfauth is on about I found what appears to
be a performance regression with '<' string comparisons on Windows
64-bit. Its around 30% slower on a 25 character string that differs in
the last character and 70-100% on a 100 character string that differs at
the end.
Can someone else please try this to see if its reproducible? Linux
doesn't show this problem.
>c:\python32\python -u "charwidth.py"
3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/z']176
[0.7116295577956576, 0.7055591343157613, 0.7203483026429418]
a=['C:/Users/Neil/Documents/λ','C:/Users/Neil/Documents/η']176
[0.7664397841378787, 0.7199902325464409, 0.713719289812504]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/η']176
[0.7341851791817691, 0.6994205901833599, 0.7106807593741005]
a=['C:/Users/Neil/Documents/𠀀','C:/Users/Neil/Documents/𠀁']180
[0.7346812372666784, 0.6995411113377914, 0.7064768417728411]
>c:\python33\python -u "charwidth.py"
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit
(AMD64)]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/z']108
[0.9913326076446045, 0.9455845241056282, 0.9459076605341776]
a=['C:/Users/Neil/Documents/λ','C:/Users/Neil/Documents/η']192
[1.0472289217234318, 1.0362342484091207, 1.0197109728048384]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/η']192
[1.0439643704533834, 0.9878581050301687, 0.9949265834034335]
a=['C:/Users/Neil/Documents/𠀀','C:/Users/Neil/Documents/𠀁']312
[1.0987483965446412, 1.0130257167690004, 1.024832248526499]
Here is the code:
# encoding:utf-8
import os, sys, timeit
print(sys.version)
examples = [
"a=['$b','$z']",
"a=['$λ','$η']",
"a=['$b','$η']",
"a=['$\U00020000','$\U00020001']"]
baseDir = "C:/Users/Neil/Documents/"
#~ baseDir = "C:/Users/Neil/Documents/Visual Studio
2012/Projects/Sigma/QtReimplementation/HLFKBase/Win32/x64/Debug"
for t in examples:
t = t.replace("$", baseDir)
# Using os.write as simple way get UTF-8 to stdout
os.write(sys.stdout.fileno(), t.encode("utf-8"))
print(sys.getsizeof(t))
print(timeit.repeat("a[0] < a[1]",t,number=5000000))
print()
For a more significant performance difference try replacing the
baseDir setting with (may be wrapped):
baseDir = "C:/Users/Neil/Documents/Visual Studio
2012/Projects/Sigma/QtReimplementation/HLFKBase/Win32/x64/Debug"
Neil
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web