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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-02 00:24 -0700 |
| Message-ID | <d23a1931-7199-4550-9a87-697ee9413408@cd3g2000vbb.googlegroups.com> |
| In reply to | #42523 |
On 2 avr, 01:43, Neil Hodgson <nhodg...@iinet.net.au> wrote:
> 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
--------
Hi,
>c:\python32\pythonw -u "charwidth.py"
3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
a=['D:\jm\jmpy\py3app\stringbenchb','D:\jm\jmpy\py3app
\stringbenchz']168
[0.8343414906182101, 0.8336184057396241, 0.8330473419738562]
a=['D:\jm\jmpy\py3app\stringbenchλ','D:\jm\jmpy\py3app
\stringbenchη']168
[0.818378092261062, 0.8180854713107406, 0.8192279926793571]
a=['D:\jm\jmpy\py3app\stringbenchb','D:\jm\jmpy\py3app
\stringbenchη']168
[0.8131353330542339, 0.8126985677326912, 0.8122744051977042]
a=['D:\jm\jmpy\py3app\stringbenchð €€','D:\jm\jmpy\py3app
\stringbenchð €']172
[0.8271094603211102, 0.82704053883214, 0.8265781741004083]
>Exit code: 0
>c:\Python33\pythonw -u "charwidth.py"
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
(Intel)]
a=['D:\jm\jmpy\py3app\stringbenchb','D:\jm\jmpy\py3app
\stringbenchz']94
[1.3840254166697845, 1.3933888932429768, 1.391664674507438]
a=['D:\jm\jmpy\py3app\stringbenchλ','D:\jm\jmpy\py3app
\stringbenchη']176
[1.6217970707185678, 1.6279369907932706, 1.6207041728220117]
a=['D:\jm\jmpy\py3app\stringbenchb','D:\jm\jmpy\py3app
\stringbenchη']176
[1.5150522562729396, 1.5130369919353992, 1.5121890607025037]
a=['D:\jm\jmpy\py3app\stringbenchð €€','D:\jm\jmpy\py3app
\stringbenchð €']316
[1.6135375194801664, 1.6117739170366434, 1.6134331526540109]
>Exit code: 0
- win7 32-bits
- The file is in utf-8
- Do not be afraid by this output, it is just a copy/paste for your
excellent editor, the coding output pane is configured to use the
locale
coding.
- Of course and as expected, similar behaviour from a console. (Which
btw
show, how good is you application).
==========
Something different.
From a previous msg, on this thread.
---
> Sure. And over a different set of samples, it is less compact. If you
> write a lot of Latin-1, Python will use one byte per character, while
> UTF-8 will use two bytes per character.
I think you mean writing a lot of Latin-1 characters outside
ASCII.
However, even people writing texts in, say, French will find that only
a
small proportion of their text is outside ASCII and so the cost of
UTF-8
is correspondingly small.
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.
---
I already explained this.
It is, how to say, a miss-understanding of Unicode. What's count,
is not the amount of non-ascii chars you have in a stream.
Relevant is the fact that every char is handled with the "same
algorithm", in that case utf-8.
Unicode takes you from the "char" up to the unicode transformated
form. Then it is a question of implementation.
This is exactly what you are doing in Scintilla (maybe without
realizing this deeply).
An editor may reflect very well the example a gave. You enter
thousand ascii chars, then - boum - as you enter a non ascii
char, your editor (assuming is uses a mechanism like the FSR),
has to internally reencode everything!
jmf
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-04-02 19:03 +1100 |
| Message-ID | <mailman.30.1364889805.17481.python-list@python.org> |
| In reply to | #42545 |
On Tue, Apr 2, 2013 at 6:24 PM, jmfauth <wxjmfauth@gmail.com> wrote: > An editor may reflect very well the example a gave. You enter > thousand ascii chars, then - boum - as you enter a non ascii > char, your editor (assuming is uses a mechanism like the FSR), > has to internally reencode everything! That assumes that the editor stores the entire buffer as a single Python string. Frankly, I think this unlikely; the nature of insertions and deletions makes this impractical. (I've known editors that do function this way. They're utterly unusable on large files.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-02 08:35 +0000 |
| Message-ID | <515a9851$0$29891$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42547 |
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: > On Tue, Apr 2, 2013 at 6:24 PM, jmfauth <wxjmfauth@gmail.com> wrote: >> An editor may reflect very well the example a gave. You enter thousand >> ascii chars, then - boum - as you enter a non ascii char, your editor >> (assuming is uses a mechanism like the FSR), has to internally reencode >> everything! > > That assumes that the editor stores the entire buffer as a single Python > string. Frankly, I think this unlikely; the nature of insertions and > deletions makes this impractical. (I've known editors that do function > this way. They're utterly unusable on large files.) Nevertheless, for *some* size of text block (a word? line? paragraph?) an implementation may need to re-encode the block as characters are inserted or deleted. So what? Who cares if it takes 0.00002 second to insert a character instead of 0.00001 second? That's still a hundred times faster than you can type. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-02 02:24 -0700 |
| Message-ID | <c4edd28c-3716-4f5d-b3c6-30f278882f12@a14g2000vbm.googlegroups.com> |
| In reply to | #42549 |
On 2 avr, 10:35, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: > > So what? Who cares if it takes 0.00002 second to insert a character > instead of 0.00001 second? That's still a hundred times faster than you > can type. > --------- This not the problem. The interesting point is that they are good and "less good" Unicode implementations. jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-02 10:43 +0100 |
| Message-ID | <mailman.33.1364895784.17481.python-list@python.org> |
| In reply to | #42551 |
On 02/04/2013 10:24, jmfauth wrote: > On 2 avr, 10:35, Steven D'Aprano <steve > +comp.lang.pyt...@pearwood.info> wrote: >> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: >> >> So what? Who cares if it takes 0.00002 second to insert a character >> instead of 0.00001 second? That's still a hundred times faster than you >> can type. >> > --------- > > This not the problem. The interesting point is that they > are good and "less good" Unicode implementations. > > jmf > The interesting point is that the Python 3.3 unicode implementation is correct, that of most other languages is buggy. Or have I fallen victim to the vicious propaganda of the various Pythonistas who frequent this list? -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steve Simmons <square.steve@gmail.com> |
|---|---|
| Date | 2013-04-02 11:58 +0100 |
| Message-ID | <mailman.35.1364900300.17481.python-list@python.org> |
| In reply to | #42551 |
On 02/04/2013 10:43, Mark Lawrence wrote: > On 02/04/2013 10:24, jmfauth wrote: >> On 2 avr, 10:35, Steven D'Aprano <steve >> +comp.lang.pyt...@pearwood.info> wrote: >>> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: >>> >>> So what? Who cares if it takes 0.00002 second to insert a character >>> instead of 0.00001 second? That's still a hundred times faster than you >>> can type. >>> >> --------- >> >> This not the problem. The interesting point is that they >> are good and "less good" Unicode implementations. >> >> jmf >> > > The interesting point is that the Python 3.3 unicode implementation is > correct, that of most other languages is buggy. Or have I fallen > victim to the vicious propaganda of the various Pythonistas who > frequent this list? > Mark, Thanks for asking this question. It seems to me that jmf *might* be moving towards a vindicated position. There is some interest now in duplicating, understanding and (hopefully!) extending his test results, which can only be a Good Thing - whatever the outcome and wherever the facepalm might land. However, as you rightly point out, there is only value in following this through if the functionality is (at least near) 100% correct. I am sure there are some that will disagree but in most cases, functionality is the primary requirement and poor performance can be managed initially and fixed in due time. Steve
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-02 06:42 -0700 |
| Message-ID | <71e7d5fe-c214-4c19-a0bf-8aa34ae5020d@mz7g2000pbb.googlegroups.com> |
| In reply to | #42557 |
On Apr 2, 3:58 pm, Steve Simmons <square.st...@gmail.com> wrote: > On 02/04/2013 10:43, Mark Lawrence wrote: > > > > > > > > > On 02/04/2013 10:24, jmfauth wrote: > >> On 2 avr, 10:35, Steven D'Aprano <steve > >> +comp.lang.pyt...@pearwood.info> wrote: > >>> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: > > >>> So what? Who cares if it takes 0.00002 second to insert a character > >>> instead of 0.00001 second? That's still a hundred times faster than you > >>> can type. > > >> --------- > > >> This not the problem. The interesting point is that they > >> are good and "less good" Unicode implementations. > > >> jmf > > > The interesting point is that the Python 3.3 unicode implementation is > > correct, that of most other languages is buggy. Or have I fallen > > victim to the vicious propaganda of the various Pythonistas who > > frequent this list? > > Mark, > > Thanks for asking this question. > > It seems to me that jmf *might* be moving towards a vindicated > position. There is some interest now in duplicating, understanding and > (hopefully!) extending his test results, which can only be a Good Thing > - whatever the outcome and wherever the facepalm might land. Whew! Very reassuring to hear some sanity in this discussion at long last!
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-04-02 14:03 +0000 |
| Message-ID | <515ae520$0$29967$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #42557 |
On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote: > It seems to me that jmf *might* be moving towards a vindicated position. > There is some interest now in duplicating, understanding and > (hopefully!) extending his test results, which can only be a Good Thing > - whatever the outcome and wherever the facepalm might land. Some interest "now"? Oh please. http://mail.python.org/pipermail/python-list/2012-September/629810.html Mark Lawrence even created a bug report to track this, also back in September. http://bugs.python.org/issue16061 I'm sure you didn't intend to be insulting, but some of us *have* taken JMF seriously, at least at first. His repeated overblown claims of how Python is destroying Unicode, his lack of acknowledgement that other people have seen string handling *speed up* not slow down, and his refusal to assist in diagnosing this performance regression except to repeatedly quote the same artificial micro-benchmarks over and over again have lost him whatever credibility he started with. This feature is a *memory optimization*, not a speed optimization, and yet as a side-effect of saving memory, it also saves time. Real-world benchmarks of actual applications demonstrate this. One or two trivial slowdowns of artificial micro-benchmarks simply are not important, even if they are genuine. I believe they are genuine, but likely operating system and hardware dependent. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steve Simmons <square.steve@gmail.com> |
|---|---|
| Date | 2013-04-02 15:39 +0100 |
| Message-ID | <mailman.0.1364913558.3114.python-list@python.org> |
| In reply to | #42565 |
On 02/04/2013 15:03, Steven D'Aprano wrote: > On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote: > >> It seems to me that jmf *might* be moving towards a vindicated position. >> There is some interest now in duplicating, understanding and >> (hopefully!) extending his test results, which can only be a Good Thing >> - whatever the outcome and wherever the facepalm might land. > Some interest "now"? Oh please. > > http://mail.python.org/pipermail/python-list/2012-September/629810.html > > Mark Lawrence even created a bug report to track this, also back in > September. > > http://bugs.python.org/issue16061 > > I'm sure you didn't intend to be insulting, but some of us *have* taken > JMF seriously, at least at first. His repeated overblown claims of how > Python is destroying Unicode, his lack of acknowledgement that other > people have seen string handling *speed up* not slow down, and his > refusal to assist in diagnosing this performance regression except to > repeatedly quote the same artificial micro-benchmarks over and over again > have lost him whatever credibility he started with. > > This feature is a *memory optimization*, not a speed optimization, and > yet as a side-effect of saving memory, it also saves time. Real-world > benchmarks of actual applications demonstrate this. One or two trivial > slowdowns of artificial micro-benchmarks simply are not important, even > if they are genuine. I believe they are genuine, but likely operating > system and hardware dependent. > > First off, no insult intended and I haven't been part of this list long enough to be fully immersed in the history of this so I'm sure there are events of which I am unaware. However, it seems to me that, for whatever reason, JMF has reached the end of his capacity (time, capability, patience, ...) to extend his benchmarks into a more credible test set - i.e. one that demonstrates an acceptably 'real life' profile with a marked drop in performance. As a community we have choices. We can brand him a Troll - and some of his behaviour may mandate that - or we can put some additional energy into drawing this 'disagreement' to a more amicable and constructive conclusion. My post was primarily aimed at recognising the work that people like Mark, Neil and others have done to move the problem forward and was intended to help shift the focus to a more productive approach. Again, my apologies if it was ill timed or ill-directed. Steve Simmons
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-02 16:02 +0100 |
| Message-ID | <mailman.2.1364914868.3114.python-list@python.org> |
| In reply to | #42565 |
On 02/04/2013 15:39, Steve Simmons wrote: > > My post was primarily aimed at recognising the work that people like > Mark, Neil and others have done to move the problem forward and was > intended to help shift the focus to a more productive approach. Again, > my apologies if it was ill timed or ill-directed. > > Steve Simmons > I must point out that I only raised issue 16061 based on data provided by Steven D'Aprano and Serhiy Storchaka. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | jmfauth <wxjmfauth@gmail.com> |
|---|---|
| Date | 2013-04-02 08:12 -0700 |
| Message-ID | <7f0f6502-6368-4d58-b248-36653e2b3cfa@w21g2000vbp.googlegroups.com> |
| In reply to | #42565 |
On 2 avr, 16:03, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote: > > I'm sure you didn't intend to be insulting, but some of us *have* taken > JMF seriously, at least at first. His repeated overblown claims of how > Python is destroying Unicode ... Sorrry I never claimed this, I'm just seeing on how Python is becoming less Unicode friendly. > > This feature is a *memory optimization*, not a speed optimization, I totaly agree, and utf-8 is doing that with a great art. (see Neil Hodgson comment). (Do not interpret this as if i'm saying "Python should use utf-8, as I'have read). jmf
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-02 16:43 +0100 |
| Message-ID | <mailman.12.1364917390.3114.python-list@python.org> |
| In reply to | #42575 |
On 02/04/2013 16:12, jmfauth wrote: > > Sorrry I never claimed this, I'm just seeing on how Python is becoming > less Unicode friendly. Please explain this. I see no justification for this comment. How can an implementation that fixes bugs be less Unicode friendly than its earlier, buggier equivalents? > > jmf > -- 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-04-02 10:08 -0700 |
| Message-ID | <7a5330a7-f837-4e50-a148-73b5d2010aeb@5g2000pbs.googlegroups.com> |
| In reply to | #42575 |
On Apr 2, 8:12 pm, jmfauth <wxjmfa...@gmail.com> wrote: > > Sorrry I never claimed this, I'm just seeing on how Python is becoming > less Unicode friendly. jmf: I suggest you try to use less emotionally loaded and more precise language if you want people to pay heed to your technical observations/ contributions. In particular, while you say unicode, your examples always (as far as I remember) refer to BMP. Also words like 'friendly' are so emotionally charged that people stop being friendly :-) So may I suggest that you rephrase your complaint as "I am seeing python is becoming poorly performant on BMP-chars at the expense of correct support for the whole (6.0?) charset" (assuming thats what you want to say) In any case PLEASE note that 'performant' and 'correct' are different for most practical purposes. If you dont respect this semantics, people are unlikely to pay heed to your complaints.
[toc] | [prev] | [next] | [standalone]
| From | Terry Jan Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-04-02 17:33 -0400 |
| Message-ID | <mailman.23.1364938450.3114.python-list@python.org> |
| In reply to | #42575 |
On 4/2/2013 11:12 AM, jmfauth wrote:
> On 2 avr, 16:03, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> I'm sure you didn't intend to be insulting, but some of us *have* taken
>> JMF seriously, at least at first. His repeated overblown claims of how
>> Python is destroying Unicode ...
... = 'usability in Python" or some variation on that.
> Sorrry I never claimed this, I'm just seeing on how Python is becoming
> less Unicode friendly.
Let us see what Jim has claimed, starting in 2012 August.
http://mail.python.org/pipermail/python-list/2012-August/628826.html
"Devs are developing sophisticed tools based on a non working basis."
http://mail.python.org/pipermail/python-list/2012-August/629514.html
"This "Flexible String Representation" fails."
http://mail.python.org/pipermail/python-list/2012-August/629554.html
"This flexible representation is working absurdly."
Reader can decide whether 'non-working', 'fails', 'working absurdly' are
closer to 'destroying Unicode usability or just 'less friendly'.
On speed:
http://mail.python.org/pipermail/python-list/2012-August/628781.html
"Python 3.3 is "slower" than Python 3.2."
http://mail.python.org/pipermail/python-list/2012-August/628762.html
"I can open IDLE with Py 3.2 ou Py 3.3 and compare strings
manipulations. Py 3.3 is always slower. Period."
False. Period. Here is my followup at the time.
python.org/pipermail/python-list/2012-August/628779.html
"You have not tried enough tests ;-).
On my Win7-64 system:
from timeit import timeit
print(timeit(" 'a'*10000 "))
3.3.0b2: .5
3.2.3: .8
print(timeit("c in a", "c = '…'; a = 'a'*10000"))
3.3: .05 (independent of len(a)!)
3.2: 5.8 100 times slower! Increase len(a) and the ratio can be made as
high as one wants!
print(timeit("a.encode()", "a = 'a'*1000"))
3.2: 1.5
3.3: .26"
If one runs stringbency.ph with its 40 or so tests, 3.2 is sometimes
faster and 3.3 is sometimes faster.
http://mail.python.org/pipermail/python-list/2012-September/630736.html
On to September:
"http://mail.python.org/pipermail/python-list/2012-September/630736.html"
"Avoid Py3.3"
In other words, ignore all the benefits and reject because a couple of
selected microbenchmarks show a slowdown.
http://mail.python.org/pipermail/python-list/2012-September/631730.html
"Py 3.3 succeeded to somehow kill unicode"
I will stop here and let Jim explain how 'kill unicode' is different
from 'destroy unicode'.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Joshua Landau <joshua.landau.ws@gmail.com> |
|---|---|
| Date | 2013-04-02 23:40 +0100 |
| Message-ID | <mailman.26.1364942450.3114.python-list@python.org> |
| In reply to | #42575 |
[Multipart message — attachments visible in raw view] — view raw
The initial post posited: "The Python 3 merge of int and long has effectively penalized small-number arithmetic by removing an optimization. As we've seen from PEP 393 strings (jmf aside), there can be huge benefits from having a single type with multiple representations internally. Is there value in making the int type have a machine-word optimization in the same way?" Thanks to the fervent response jmf has gotten, the point above has been mostly abandoned May I request that next time such an obvious diversion (aka. jmf) occurs, responses happen in a different thread?
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-04-02 08:09 -0700 |
| Message-ID | <mailman.11.1364917033.3114.python-list@python.org> |
| In reply to | #42565 |
On 04/02/2013 07:39 AM, Steve Simmons wrote: > > On 02/04/2013 15:03, Steven D'Aprano wrote: >> On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote: >> >>> It seems to me that jmf *might* be moving towards a vindicated position. >>> There is some interest now in duplicating, understanding and >>> (hopefully!) extending his test results, which can only be a Good Thing >>> - whatever the outcome and wherever the facepalm might land. >> Some interest "now"? Oh please. >> >> http://mail.python.org/pipermail/python-list/2012-September/629810.html >> >> Mark Lawrence even created a bug report to track this, also back in >> September. >> >> http://bugs.python.org/issue16061 >> >> I'm sure you didn't intend to be insulting, but some of us *have* taken >> JMF seriously, at least at first. His repeated overblown claims of how >> Python is destroying Unicode, his lack of acknowledgement that other >> people have seen string handling *speed up* not slow down, and his >> refusal to assist in diagnosing this performance regression except to >> repeatedly quote the same artificial micro-benchmarks over and over again >> have lost him whatever credibility he started with. >> >> This feature is a *memory optimization*, not a speed optimization, and >> yet as a side-effect of saving memory, it also saves time. Real-world >> benchmarks of actual applications demonstrate this. One or two trivial >> slowdowns of artificial micro-benchmarks simply are not important, even >> if they are genuine. I believe they are genuine, but likely operating >> system and hardware dependent. >> >> > First off, no insult intended and I haven't been part of this list long enough to be fully immersed in the history of > this so I'm sure there are events of which I am unaware. Yes, that would be his months of trollish behavior on this subject. > However, it seems to me that, for whatever reason, JMF has reached the end of his capacity His capacity, maybe; his time? Not by a long shot. I am positive we will continue to see his uncooperative, bratty* behavior continue ad nauseum. -- ~Ethan~ *I was going to say childish, but I know plenty of better behaved children.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-04-02 15:12 +0100 |
| Message-ID | <mailman.41.1364911931.17481.python-list@python.org> |
| In reply to | #42551 |
On 02/04/2013 11:58, Steve Simmons wrote: > > On 02/04/2013 10:43, Mark Lawrence wrote: >> On 02/04/2013 10:24, jmfauth wrote: >>> On 2 avr, 10:35, Steven D'Aprano <steve >>> +comp.lang.pyt...@pearwood.info> wrote: >>>> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote: >>>> >>>> So what? Who cares if it takes 0.00002 second to insert a character >>>> instead of 0.00001 second? That's still a hundred times faster than you >>>> can type. >>>> >>> --------- >>> >>> This not the problem. The interesting point is that they >>> are good and "less good" Unicode implementations. >>> >>> jmf >>> >> >> The interesting point is that the Python 3.3 unicode implementation is >> correct, that of most other languages is buggy. Or have I fallen >> victim to the vicious propaganda of the various Pythonistas who >> frequent this list? >> > Mark, > > Thanks for asking this question. > > It seems to me that jmf *might* be moving towards a vindicated > position. There is some interest now in duplicating, understanding and > (hopefully!) extending his test results, which can only be a Good Thing > - whatever the outcome and wherever the facepalm might land. > The position that is already documented in PEP393, how so? > However, as you rightly point out, there is only value in following this > through if the functionality is (at least near) 100% correct. I am sure > there are some that will disagree but in most cases, functionality is > the primary requirement and poor performance can be managed initially > and fixed in due time. I've already raised an issue about performance and Neil Hodgson has raised a new one. To balance this out perhaps we should have counter issues asking for the amount of memory being used to be increased to old levels and the earlier buggier behaviour of Python to be reintroduced? Swings and roundabouts? > > Steve -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steve Simmons <square.steve@gmail.com> |
|---|---|
| Date | 2013-04-02 16:03 +0100 |
| Message-ID | <mailman.3.1364915021.3114.python-list@python.org> |
| In reply to | #42551 |
On 02/04/2013 15:12, Mark Lawrence wrote: > I've already raised an issue about performance and Neil Hodgson has > raised a new one. Recognised in a separate post > To balance this out perhaps we should have counter issues asking for > the amount of memory being used to be increased to old levels and the > earlier buggier behaviour of Python to be reintroduced? Swings and > roundabouts? I don't think I came anywhere near suggesting that we should regress correct functionality or memory usage improvements. I just don't believe that we can't have good performance alongside it. Steve S
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2013-04-02 08:17 -0700 |
| Message-ID | <mailman.7.1364916159.3114.python-list@python.org> |
| In reply to | #42551 |
On 04/02/2013 08:03 AM, Steve Simmons wrote: > On 02/04/2013 15:12, Mark Lawrence wrote: >> I've already raised an issue about performance and Neil Hodgson has raised a new one. > Recognised in a separate post > >> To balance this out perhaps we should have counter issues asking for the amount of memory being used to be increased >> to old levels and the earlier buggier behaviour of Python to be reintroduced? Swings and roundabouts? > > I don't think I came anywhere near suggesting that we should regress correct functionality or memory usage > improvements. I just don't believe that we can't have good performance alongside it. It's always a trade-off between time and memory. However, as it happens, there are plenty of instances where the new FSR is faster -- and this in real world code, not useless micro-benchmarks. Simmons (too many Steves!), I know you're new so don't have all the history with jmf that many of us do, but consider that the original post was about numbers, had nothing to do with characters or unicode *in any way*, and yet jmf still felt the need to bring unicode up. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-04-02 09:57 -0700 |
| Message-ID | <757f2dad-c073-487f-ac40-310e54083eef@kw7g2000pbb.googlegroups.com> |
| In reply to | #42577 |
On Apr 2, 8:17 pm, Ethan Furman <et...@stoneleaf.us> wrote: > Simmons (too many Steves!), I know you're new so don't have all the history with jmf that many > of us do, but consider that the original post was about numbers, had nothing to do with > characters or unicode *in any way*, and yet jmf still felt the need to bring unicode up. Just for reference, here is the starting para of Chris' original mail that started this thread. > The Python 3 merge of int and long has effectively penalized > small-number arithmetic by removing an optimization. As we've seen > from PEP 393 strings (jmf aside), there can be huge benefits from > having a single type with multiple representations internally. Is > there value in making the int type have a machine-word optimization in > the same way? ie it mentions numbers, strings, PEP 393 *AND jmf.* So while it is true that jmf has been butting in with trollish behavior into completely unrelated threads with his unicode rants, that cannot be said for this thread.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web