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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-04 01:17 +1100 |
| Message-ID | <mailman.62.1364999064.3114.python-list@python.org> |
| In reply to | #42668 |
On Thu, Apr 4, 2013 at 12:43 AM, Roy Smith <roy@panix.com> wrote: > This has to inspect the entire string, no? I posted (essentially) this > a few days ago: > > if all(ord(c) <= 0xffff for c in s): > return "it's all bmp" > else: > return "it's got astral crap in it" > > I'm reasonably sure all() is smart enough to stop at the first False > value. Probably, but it still has to scan the body of the string. It'd not be too bad if it's all astral, but if it's all BMP, it has to scan the whole string. In the max() case, it has to scan the whole string anyway, as there's no other way to determine the maximum. I'm thinking here of this function: http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/width.html It's implemented as a simple lookup into the header. (Pike strings, like PEP 393 strings, are stored in the most compact way possible - 1, 2, or 4 bytes per character - with a conceptually similar header structure.) Is this something that would be worth having available? Should I post an issue about it? ChrisA more for self-ref than anyone else's: source of Pike's String.width(): http://pike-git.lysator.liu.se/gitweb.cgi?p=pike.git;a=blob;f=src/builtin.cmod;hb=HEAD#l1077
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 15:07 +0000 |
| Message-ID | <515c45ad$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42673 |
On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote: > Probably, but it still has to scan the body of the string. It'd not be > too bad if it's all astral, but if it's all BMP, it has to scan the > whole string. In the max() case, it has to scan the whole string anyway, > as there's no other way to determine the maximum. I'm thinking here of > this function: > > http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/ width.html > > It's implemented as a simple lookup into the header. (Pike strings, like > PEP 393 strings, are stored in the most compact way possible - 1, 2, or > 4 bytes per character - with a conceptually similar header structure.) > Is this something that would be worth having available? Should I post an > issue about it? I'm not really sure why I would want to know, apart from pure intellectual curiosity, but sure, post a feature request. Be sure to mention that Pike supports this feature. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-04 08:57 +1100 |
| Message-ID | <mailman.78.1365026247.3114.python-list@python.org> |
| In reply to | #42679 |
On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote: > >> Probably, but it still has to scan the body of the string. It'd not be >> too bad if it's all astral, but if it's all BMP, it has to scan the >> whole string. In the max() case, it has to scan the whole string anyway, >> as there's no other way to determine the maximum. I'm thinking here of >> this function: >> >> http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/ > width.html >> >> It's implemented as a simple lookup into the header. (Pike strings, like >> PEP 393 strings, are stored in the most compact way possible - 1, 2, or >> 4 bytes per character - with a conceptually similar header structure.) >> Is this something that would be worth having available? Should I post an >> issue about it? > > I'm not really sure why I would want to know, apart from pure > intellectual curiosity, but sure, post a feature request. Be sure to > mention that Pike supports this feature. http://bugs.python.org/issue17629 opened. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2013-04-06 12:09 +0300 |
| Message-ID | <mailman.201.1365275495.3114.python-list@python.org> |
| In reply to | #42679 |
04.04.13 00:57, Chris Angelico написав(ла): > On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote: >> >>> Probably, but it still has to scan the body of the string. It'd not be >>> too bad if it's all astral, but if it's all BMP, it has to scan the >>> whole string. In the max() case, it has to scan the whole string anyway, >>> as there's no other way to determine the maximum. I'm thinking here of >>> this function: >>> >>> http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/ >> width.html >>> >>> It's implemented as a simple lookup into the header. (Pike strings, like >>> PEP 393 strings, are stored in the most compact way possible - 1, 2, or >>> 4 bytes per character - with a conceptually similar header structure.) >>> Is this something that would be worth having available? Should I post an >>> issue about it? >> >> I'm not really sure why I would want to know, apart from pure >> intellectual curiosity, but sure, post a feature request. Be sure to >> mention that Pike supports this feature. > > http://bugs.python.org/issue17629 opened. See also the discussion at http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with rejection. This is an implementation detail and different Python implementations (including future CPython versions) can have different internal string implementations.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-07 07:24 +1000 |
| Message-ID | <mailman.213.1365283507.3114.python-list@python.org> |
| In reply to | #42679 |
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com> wrote: > 04.04.13 00:57, Chris Angelico написав(ла): >> http://bugs.python.org/issue17629 opened. > > > See also the discussion at > http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with > rejection. This is an implementation detail and different Python > implementations (including future CPython versions) can have different > internal string implementations. I really don't see why this means that there can't be a function in sys, or something. I mean, other Pythons aren't expected to return the exact same values from sys.getsizeof, are they? But clearly the weight of opinion is against me, so fine, I don't care that much. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-04-06 14:58 -0700 |
| Message-ID | <mailman.215.1365286584.3114.python-list@python.org> |
| In reply to | #42679 |
On 04/06/2013 02:24 PM, Chris Angelico wrote: > On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com> wrote: >> 04.04.13 00:57, Chris Angelico написав(ла): >>> http://bugs.python.org/issue17629 opened. >> >> >> See also the discussion at >> http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with >> rejection. This is an implementation detail and different Python >> implementations (including future CPython versions) can have different >> internal string implementations. > > I really don't see why this means that there can't be a function in > sys, or something. I mean, other Pythons aren't expected to return the > exact same values from sys.getsizeof, are they? What it boils down to is: - it can easily be done by hand now - it's a very uncommon need ergo: - it's not worth the time and on-going effort required -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-07 01:29 +0000 |
| Message-ID | <5160cbeb$0$29995$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42954 |
On Sat, 06 Apr 2013 14:58:23 -0700, Ethan Furman wrote:
> On 04/06/2013 02:24 PM, Chris Angelico wrote:
>> On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com>
>> wrote:
>>> 04.04.13 00:57, Chris Angelico написав(ла):
>>>> http://bugs.python.org/issue17629 opened.
>>>
>>>
>>> See also the discussion at
>>> http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with
>>> rejection. This is an implementation detail and different Python
>>> implementations (including future CPython versions) can have different
>>> internal string implementations.
>>
>> I really don't see why this means that there can't be a function in
>> sys, or something. I mean, other Pythons aren't expected to return the
>> exact same values from sys.getsizeof, are they?
>
> What it boils down to is:
>
> - it can easily be done by hand now
For some definition of "easily".
if implementation == "CPython":
if version < "3.3":
if sys.maxunicode exists:
use it to decide whether this is a wide or narrow build
if a wide build: return 4
else: return 2
else:
???
elif version == "3.3":
scan the string, in some efficient or inefficient way
return 1, 2, 4 depending on the largest character you find
else:
???
else:
???
> - it's a very uncommon need
Well, that at least is true. But then, needing to know the platform
you're running under, the size of objects, the id of a object, the
largest integer, the largest float, or the number of references seen by
the garbage collector are also uncommon needs. What really matters is not
how often you need it, but what you can do when you need it if you don't
have it.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-06 19:58 -0600 |
| Message-ID | <mailman.222.1365299932.3114.python-list@python.org> |
| In reply to | #42960 |
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > For some definition of "easily". > > if implementation == "CPython": > if version < "3.3": > if sys.maxunicode exists: > use it to decide whether this is a wide or narrow build > if a wide build: return 4 > else: return 2 > else: > ??? > elif version == "3.3": > scan the string, in some efficient or inefficient way > return 1, 2, 4 depending on the largest character you find > else: > ??? > else: > ??? None of which goes away if a char width function is added to 3.4 and you still want to support earlier versions as this does. It just adds another "if".
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-06 22:18 -0400 |
| Message-ID | <roy-8CD443.22180806042013@news.panix.com> |
| In reply to | #42965 |
In article <mailman.222.1365299932.3114.python-list@python.org>, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: > > For some definition of "easily". > > > > if implementation == "CPython": > > if version < "3.3": > > if sys.maxunicode exists: > > use it to decide whether this is a wide or narrow build > > if a wide build: return 4 > > else: return 2 > > else: > > ??? > > elif version == "3.3": > > scan the string, in some efficient or inefficient way > > return 1, 2, 4 depending on the largest character you find > > else: > > ??? > > else: > > ??? > > None of which goes away if a char width function is added to 3.4 and > you still want to support earlier versions as this does. It just adds > another "if". The same is true of any new feature. That doesn't mean we shouldn't add new features.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-06 23:22 -0600 |
| Message-ID | <mailman.231.1365312197.3114.python-list@python.org> |
| In reply to | #42968 |
On Sat, Apr 6, 2013 at 8:18 PM, Roy Smith <roy@panix.com> wrote: > In article <mailman.222.1365299932.3114.python-list@python.org>, > Ian Kelly <ian.g.kelly@gmail.com> wrote: > >> On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano >> <steve+comp.lang.python@pearwood.info> wrote: >> > For some definition of "easily". >> > >> > if implementation == "CPython": >> > if version < "3.3": >> > if sys.maxunicode exists: >> > use it to decide whether this is a wide or narrow build >> > if a wide build: return 4 >> > else: return 2 >> > else: >> > ??? >> > elif version == "3.3": >> > scan the string, in some efficient or inefficient way >> > return 1, 2, 4 depending on the largest character you find >> > else: >> > ??? >> > else: >> > ??? >> >> None of which goes away if a char width function is added to 3.4 and >> you still want to support earlier versions as this does. It just adds >> another "if". > > The same is true of any new feature. That doesn't mean we shouldn't add > new features. If you're interested in backward compatibility, then as noted the feature doesn't really make things any simpler for you. Otherwise, the only implementation that matters from the above is the 3.3 one, which isn't much more complex.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-07 08:29 +0000 |
| Message-ID | <51612e5f$0$29995$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42965 |
On Sat, 06 Apr 2013 19:58:02 -0600, Ian Kelly wrote: > On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> For some definition of "easily". >> >> if implementation == "CPython": >> if version < "3.3": >> if sys.maxunicode exists: >> use it to decide whether this is a wide or narrow build if >> a wide build: return 4 >> else: return 2 >> else: >> ??? >> elif version == "3.3": >> scan the string, in some efficient or inefficient way return 1, >> 2, 4 depending on the largest character you find >> else: >> ??? >> else: >> ??? > > None of which goes away if a char width function is added to 3.4 and you > still want to support earlier versions as this does. It just adds > another "if". I grant you that for supporting earlier versions. But it will help with *future* versions. In principle, by Python 3.9, there could be six different checks just in the CPython section, to say nothing of PyPy, Jython, IronPython, and any other implementation. An officially supported way of querying the kind of strings used will future-proof Python. In this regard, it's no different from (say) sys.float_info. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-06 20:00 -0600 |
| Message-ID | <mailman.223.1365300092.3114.python-list@python.org> |
| In reply to | #42679 |
On Sat, Apr 6, 2013 at 3:24 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com> wrote: >> 04.04.13 00:57, Chris Angelico написав(ла): >>> http://bugs.python.org/issue17629 opened. >> >> >> See also the discussion at >> http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with >> rejection. This is an implementation detail and different Python >> implementations (including future CPython versions) can have different >> internal string implementations. > > I really don't see why this means that there can't be a function in > sys, or something. I mean, other Pythons aren't expected to return the > exact same values from sys.getsizeof, are they? But clearly the weight > of opinion is against me, so fine, I don't care that much. If you want it, nobody is stopping you from writing it yourself as an extension module. But I don't think the use case is strong enough to warrant the devs adding it and then having to maintain it.
[toc] | [prev] | [next] | [standalone]
| From | Serhiy Storchaka <storchaka@gmail.com> |
|---|---|
| Date | 2013-04-07 11:02 +0300 |
| Message-ID | <mailman.235.1365321741.3114.python-list@python.org> |
| In reply to | #42679 |
On 07.04.13 00:24, Chris Angelico wrote: > On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com> wrote: >> See also the discussion at >> http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with >> rejection. This is an implementation detail and different Python >> implementations (including future CPython versions) can have different >> internal string implementations. > > I really don't see why this means that there can't be a function in > sys, or something. I mean, other Pythons aren't expected to return the > exact same values from sys.getsizeof, are they? But clearly the weight > of opinion is against me, so fine, I don't care that much. The most strong argument for adding this feature in stdlib is that it has O(1) complexity against of O(N) complexity of any manual implementation. But this argument is not valid for other implementations.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-07 16:14 +0100 |
| Message-ID | <mailman.244.1365347567.3114.python-list@python.org> |
| In reply to | #42679 |
On 06/04/2013 22:24, Chris Angelico wrote: > On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka <storchaka@gmail.com> wrote: >> 04.04.13 00:57, Chris Angelico написав(ла): >>> http://bugs.python.org/issue17629 opened. >> >> >> See also the discussion at >> http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with >> rejection. This is an implementation detail and different Python >> implementations (including future CPython versions) can have different >> internal string implementations. > > I really don't see why this means that there can't be a function in > sys, or something. I mean, other Pythons aren't expected to return the > exact same values from sys.getsizeof, are they? But clearly the weight > of opinion is against me, so fine, I don't care that much. > > ChrisA > There is nothing to stop anybody providing a patch to give this functionality. The downside is long term someone has to maintain it. I strongly prefer having python devs spending their time looking after the 3905 open issues of which 1729 have patches, see http://comments.gmane.org/gmane.comp.python.devel/138310 -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 15:02 +0000 |
| Message-ID | <515c448c$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42668 |
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
>> n = max(map(ord, s))
>> 4 if n > 0xffff else 2 if n > 0xff else 1
>
> This has to inspect the entire string, no?
Correct. A more efficient implementation would be:
def char_size(s):
for n in map(ord, s):
if n > 0xFFFF: return 4
if n > 0xFF: return 2
return 1
> I posted (essentially) this a few days ago:
>
> if all(ord(c) <= 0xffff for c in s):
> return "it's all bmp"
> else:
> return "it's got astral crap in it"
It's not "astral crap". People use it, and they'll use it more in the
future. Just because you don't, doesn't give you leave to make
disparaging remarks about it.
Honestly, it's really painful to see how history repeats itself:
"Bah humbug, why do we need to support the SMP astral crap? The Unicode
BMP is more than enough for everybody."
"Bah humbug, why do we need to support Unicode crap? Latin1 is more than
enough for everybody."
"Bah humbug, why do we need to support Latin1 crap? ASCII is more than
enough for everybody."
"Bah humbug, why do we need to support ASCII crap? Uppercase A-Z is more
than enough for everybody."
Seriously. Go back long enough, to the telegraph days, and you have
people arguing that there was no need for upper and lower case letters.
> I'm reasonably sure all() is smart enough to stop at the first False
> value.
Yes, all() and any() are guaranteed to be short-circuit functions. They
will stop as soon as they see a False or a True value respectively.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2013-04-03 10:38 -0600 |
| Message-ID | <mailman.66.1365007144.3114.python-list@python.org> |
| In reply to | #42678 |
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote: > > [...] >>> n = max(map(ord, s)) >>> 4 if n > 0xffff else 2 if n > 0xff else 1 >> >> This has to inspect the entire string, no? > > Correct. A more efficient implementation would be: > > def char_size(s): > for n in map(ord, s): > if n > 0xFFFF: return 4 > if n > 0xFF: return 2 > return 1 That's an incorrect implementation, as it would return 2 at the first non-Latin-1 BMP character, even if there were SMP characters later in the string. It's only safe to short-circuit return 4, not 2 or 1.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-03 17:43 +0000 |
| Message-ID | <515c6a57$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42685 |
On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote: > On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote: >> >> [...] >>>> n = max(map(ord, s)) >>>> 4 if n > 0xffff else 2 if n > 0xff else 1 >>> >>> This has to inspect the entire string, no? >> >> Correct. A more efficient implementation would be: >> >> def char_size(s): >> for n in map(ord, s): >> if n > 0xFFFF: return 4 >> if n > 0xFF: return 2 >> return 1 > > That's an incorrect implementation, as it would return 2 at the first > non-Latin-1 BMP character, even if there were SMP characters later in > the string. It's only safe to short-circuit return 4, not 2 or 1. Doh! I mean, well done sir, you have successfully passed my little test! -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-04 08:55 +1100 |
| Message-ID | <mailman.77.1365026152.3114.python-list@python.org> |
| In reply to | #42690 |
On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote:
>
>> On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
>>>
>>> [...]
>>>>> n = max(map(ord, s))
>>>>> 4 if n > 0xffff else 2 if n > 0xff else 1
>>>>
>>>> This has to inspect the entire string, no?
>>>
>>> Correct. A more efficient implementation would be:
>>>
>>> def char_size(s):
>>> for n in map(ord, s):
>>> if n > 0xFFFF: return 4
>>> if n > 0xFF: return 2
>>> return 1
>>
>> That's an incorrect implementation, as it would return 2 at the first
>> non-Latin-1 BMP character, even if there were SMP characters later in
>> the string. It's only safe to short-circuit return 4, not 2 or 1.
>
>
> Doh!
>
> I mean, well done sir, you have successfully passed my little test!
Try this:
def str_width(s):
width=1
for ch in map(ord,s):
if ch > 0xFFFF: return 4
if cn > 0xFF: width=2
return width
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-03 23:39 +0100 |
| Message-ID | <mailman.82.1365028707.3114.python-list@python.org> |
| In reply to | #42690 |
On 03/04/2013 22:55, Chris Angelico wrote: > On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote: >> >>> On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano >>> <steve+comp.lang.python@pearwood.info> wrote: >>>> On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote: >>>> >>>> [...] >>>>>> n = max(map(ord, s)) >>>>>> 4 if n > 0xffff else 2 if n > 0xff else 1 >>>>> >>>>> This has to inspect the entire string, no? >>>> >>>> Correct. A more efficient implementation would be: >>>> >>>> def char_size(s): >>>> for n in map(ord, s): >>>> if n > 0xFFFF: return 4 >>>> if n > 0xFF: return 2 >>>> return 1 >>> >>> That's an incorrect implementation, as it would return 2 at the first >>> non-Latin-1 BMP character, even if there were SMP characters later in >>> the string. It's only safe to short-circuit return 4, not 2 or 1. >> >> >> Doh! >> >> I mean, well done sir, you have successfully passed my little test! > > Try this: > > def str_width(s): > width=1 > for ch in map(ord,s): > if ch > 0xFFFF: return 4 > if cn > 0xFF: width=2 > return width > > ChrisA > Given the quality of some code posted here recently this patch can't be accepted until there are some unit tests :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2013-04-03 20:49 -0400 |
| Message-ID | <roy-6C5CB8.20491503042013@news.panix.com> |
| In reply to | #42678 |
In article <515c448c$0$29966$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote: > > [...] > >> n = max(map(ord, s)) > >> 4 if n > 0xffff else 2 if n > 0xff else 1 > > > > This has to inspect the entire string, no? > > Correct. A more efficient implementation would be: > > def char_size(s): > for n in map(ord, s): > if n > 0xFFFF: return 4 > if n > 0xFF: return 2 > return 1 > > > > > I posted (essentially) this a few days ago: > > > > if all(ord(c) <= 0xffff for c in s): > > return "it's all bmp" > > else: > > return "it's got astral crap in it" > > > It's not "astral crap". People use it, and they'll use it more in the > future. Just because you don't, doesn't give you leave to make > disparaging remarks about it. > > Honestly, it's really painful to see how history repeats itself: > > "Bah humbug, why do we need to support the SMP astral crap? The Unicode > BMP is more than enough for everybody." Come on, guys. It was a joke. I'm the guy who was complaining that my database doesn't support non-BMP, remember?
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web