Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #104645 > unrolled thread
| Started by | Chris Angelico <rosuav@gmail.com> |
|---|---|
| First post | 2016-03-12 08:36 +1100 |
| Last post | 2016-03-12 15:29 +0000 |
| Articles | 20 on this page of 314 — 29 participants |
Back to article view | Back to comp.lang.python
The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 08:36 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 01:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-11 21:02 -0800
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 11:50 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 14:13 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 13:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 15:40 +0200
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:24 +0100
Re: The Cost of Dynamism Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:18 +1100
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 21:05 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 00:40 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:26 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 22:14 +0000
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-13 21:08 +0100
Re: The Cost of Dynamism Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-12 20:20 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 23:52 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 03:22 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 08:45 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 00:10 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 09:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 00:57 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 23:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-13 01:10 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 19:39 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-13 22:12 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 17:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 17:53 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-14 20:25 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 18:39 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 20:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-15 13:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 11:52 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 14:58 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 18:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-14 07:57 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 22:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Christian Gollwitzer <auriocus@gmx.de> - 2016-03-13 22:26 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-14 08:44 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Paul Rubin <no.email@nospam.invalid> - 2016-03-13 16:25 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 10:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 00:25 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 00:50 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 01:15 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 01:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 12:35 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 02:04 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 13:07 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-21 13:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-21 17:41 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 00:07 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-21 18:47 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 03:30 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 16:51 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-23 17:09 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-23 10:34 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 21:48 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-23 13:41 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-24 14:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-23 20:38 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 13:01 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 09:33 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-24 16:16 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-24 07:37 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 05:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 19:54 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 21:02 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-25 11:06 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-26 03:22 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-25 22:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-26 13:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-26 13:45 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-24 20:49 -0600
Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 02:50 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Marko Rauhamaa <marko@pacujo.net> - 2016-03-25 18:57 +0200
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 13:46 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Random832 <random832@fastmail.com> - 2016-03-25 22:56 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-25 19:59 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 23:21 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 00:22 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-26 14:09 +0000
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 01:30 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-26 15:24 +0000
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:34 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 12:31 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-27 09:47 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 15:43 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 08:48 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Terry Reedy <tjreedy@udel.edu> - 2016-03-27 12:39 -0400
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:26 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Terry Reedy <tjreedy@udel.edu> - 2016-03-28 15:34 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 17:58 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 10:19 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 21:18 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ned Batchelder <ned@nedbatchelder.com> - 2016-03-27 14:55 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] BartC <bc@freeuk.com> - 2016-03-27 23:11 +0100
Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 11:54 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-27 18:40 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-29 19:26 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-29 01:54 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-29 20:09 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Marko Rauhamaa <marko@pacujo.net> - 2016-03-29 12:23 +0300
Re: Statements as expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-29 12:31 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-30 11:05 +1100
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-29 08:15 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-28 12:11 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-28 13:55 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Paul Rubin <no.email@nospam.invalid> - 2016-03-28 11:27 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-29 20:14 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-29 23:49 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-30 15:26 +0100
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-30 09:59 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Random832 <random832@fastmail.com> - 2016-03-30 13:07 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Rustom Mody <rustompmody@gmail.com> - 2016-03-30 10:28 -0700
Re: Statements as expressions [was Re: Undefined behaviour in C] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-30 19:01 -0400
Re: Statements as expressions [was Re: Undefined behaviour in C] Random832 <random832@fastmail.com> - 2016-03-30 20:15 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-27 18:31 -0400
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:45 +1100
Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve@pearwood.info> - 2016-03-28 12:24 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-28 12:38 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] Tim Chase <python.list@tim.thechases.com> - 2016-03-27 21:59 -0500
Re: Useless expressions [was Re: Undefined behaviour in C] Chris Angelico <rosuav@gmail.com> - 2016-03-28 14:29 +1100
Re: Useless expressions [was Re: Undefined behaviour in C] BartC <bc@freeuk.com> - 2016-03-28 13:18 +0100
Re: Useless expressions [was Re: Undefined behaviour in C] Marko Rauhamaa <marko@pacujo.net> - 2016-03-28 16:29 +0300
Re: Useless expressions [was Re: Undefined behaviour in C] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-29 18:12 +1100
Re: Useless expressions Ben Finney <ben+python@benfinney.id.au> - 2016-03-29 18:35 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:50 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-27 10:51 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:13 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:40 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-27 00:52 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-27 21:06 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2016-03-27 22:16 +0100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Marko Rauhamaa <marko@pacujo.net> - 2016-03-26 10:37 +0200
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-26 08:23 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 18:13 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-25 22:30 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-26 21:39 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-26 23:03 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 10:43 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Terry Reedy <tjreedy@udel.edu> - 2016-03-26 16:44 -0400
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 22:02 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-26 22:54 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 08:58 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Steven D'Aprano <steve@pearwood.info> - 2016-03-27 13:44 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Chris Angelico <rosuav@gmail.com> - 2016-03-27 13:52 +1100
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Paul Rubin <no.email@nospam.invalid> - 2016-03-26 23:34 -0700
Re: Undefined behaviour in C [was Re: The Cost of Dynamism] Rustom Mody <rustompmody@gmail.com> - 2016-03-27 00:13 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-25 21:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 00:50 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-25 01:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:28 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-24 18:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:04 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 14:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-24 16:34 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 14:49 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-24 10:53 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 15:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 15:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 15:25 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-24 11:30 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:56 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-24 19:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:44 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Matt Wheeler <m@funkyhat.org> - 2016-03-24 14:22 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 14:51 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-25 04:27 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-24 21:24 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-24 18:14 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 08:30 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 16:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 10:13 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-24 18:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-24 17:30 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Tim Golden <mail@timgolden.me.uk> - 2016-03-23 10:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 22:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-23 08:40 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 16:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-23 12:24 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-24 10:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-23 20:12 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-24 11:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 01:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 23:21 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-23 20:26 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-23 16:09 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 03:59 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-21 17:38 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 18:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-21 09:20 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 02:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 19:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 19:57 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 13:18 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-21 18:59 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 12:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 11:05 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 22:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 12:59 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:13 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-22 13:46 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 01:02 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-03-22 15:07 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 02:18 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 14:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-22 07:15 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 01:31 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-23 12:14 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 12:21 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-22 13:43 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 09:23 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-23 17:07 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 17:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-22 04:23 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ian Foote <ian@feete.org> - 2016-03-22 11:27 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-22 07:45 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 22:55 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 23:15 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 23:03 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 14:52 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:00 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:15 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:24 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:32 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-23 00:38 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-22 15:49 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Larry Hudson <orgnut@yahoo.com> - 2016-03-22 22:17 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-20 22:21 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 12:34 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-21 23:59 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 00:48 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Random832 <random832@fastmail.com> - 2016-03-21 10:04 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 02:09 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 08:39 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-22 02:45 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 17:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 20:20 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-21 06:02 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 13:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) MRAB <python@mrabarnett.plus.com> - 2016-03-21 13:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-22 02:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 17:31 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-21 18:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-21 19:20 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 00:49 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 02:01 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rustom Mody <rustompmody@gmail.com> - 2016-03-22 04:15 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-22 17:53 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-22 09:24 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 07:44 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 20:13 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 05:08 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-21 12:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ned Batchelder <ned@nedbatchelder.com> - 2016-03-21 06:12 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-21 19:50 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 00:18 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-22 00:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-22 01:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-24 13:49 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 13:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 02:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-24 22:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 08:48 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 11:08 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 11:27 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 13:51 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 13:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 16:38 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 03:56 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 17:54 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-12 20:07 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 18:30 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 20:39 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-13 13:16 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-14 14:01 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 13:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 14:43 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 16:21 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Michael Torrie <torriem@gmail.com> - 2016-03-14 11:55 -0600
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-14 19:45 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 20:31 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Christian Gollwitzer <auriocus@gmx.de> - 2016-03-14 22:00 +0100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-14 21:17 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-14 21:00 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:27 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 01:35 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 13:12 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 08:25 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-15 09:20 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-15 12:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-15 23:20 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-15 11:17 -0700
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Marko Rauhamaa <marko@pacujo.net> - 2016-03-15 12:14 +0200
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:19 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-15 12:11 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-12 23:10 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-12 23:28 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 00:06 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 15:12 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 02:30 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) BartC <bc@freeuk.com> - 2016-03-12 16:42 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-12 17:02 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Steven D'Aprano <steve@pearwood.info> - 2016-03-13 12:20 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-13 01:32 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Chris Angelico <rosuav@gmail.com> - 2016-03-13 13:03 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Ben Finney <ben+python@benfinney.id.au> - 2016-03-13 13:33 +1100
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Terry Reedy <tjreedy@udel.edu> - 2016-03-13 01:43 -0500
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) Gene Heskett <gheskett@wdtv.com> - 2016-03-13 09:14 -0400
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-12 19:03 +0000
Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) alister <alister.ware@ntlworld.com> - 2016-03-12 15:29 +0000
Page 1 of 16 [1] 2 3 … 16 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-12 08:36 +1100 |
| Subject | The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?) |
| Message-ID | <mailman.8.1457732171.12893.python-list@python.org> |
On Sat, Mar 12, 2016 at 5:57 AM, BartC <bc@freeuk.com> wrote:
> Anyway, I've listed some of the stumbling blocks I think that Python has in
> making it bit faster: http://pastebin.com/WfUfK3bc
>
Much easier to discuss text that's inline, so I'm taking this out of pastebin.
> Functions are dynamic. That is, you don't know the F in F() is actually a function, even if it was defined a few lines previously, because it could have been rebound to something else. That means a runtime check to ensure that it is one.
>
> * Dynamic functions mean the compiler doesn't know how many parameters a function takes. This needs checking at runtime, and something done about too many or too few arguments.
>
> * The compiler doesn't know the names of the parameters in the function it's calling. So keyword arguments need to be dealt with at runtime.
>
> * The compiler doesn't know about parameter default values, so again this needs to be checked and dealt with at runtime
>
All of these are really one thing: When you compile some code, you
don't know whether F() is still going to be the same object when you
run it. FAT Python is intended to pick this up; it recognizes
constants, and can then perform all the other optimizations you
describe (since functions are themselves immutable, all you need is an
identity check on the function object itself, and everything else you
describe can be done safely).
> * Top-level names (eg. the 'A' in A.B.C), which generally refer to a defined function, class or module, or to a variable, can additionally be deleted or added at runtime. This means a look-up for such names (LOAD_GLOBAL), if they are not local to a function.
>
> * Module names are dynamic. So for a call such as M.F(), M needs to be looked up (M could be a number of things), and then an attribute lookup for F needs to be done before a call can be made. Then you have those other matters above.
>
> (Static modules and functions would mean that M.F() can be resolved at compile-time. No name or attribute lookup needed, and in fact the function can be an operand of a Call byte-code with no need to load to the stack first.)
>
> * Dynamic modules mean it is not possible to optimise expressions using math.sqrt() for example, as both math and sqrt could have been changed.
>
Not sure what the significance of this is. Since they can be rebound
at run-time, you need a lookup anyway. The only way to avoid that
lookup is to constant-fold them, which would break anything that
*ever* rebinds globals. But again, FAT Python is looking into this
(since the rebinding of globals is unusual). The same thing applies to
module attributes, since your globals are simply the attributes of
your module, and "math.sqrt()" is just a special case of M.F().
> * Variables are dynamic. So you can't for example declare (with a new const feature) 'const rows=50', which would allow you to code 'LOAD_CONST' instead of 'LOAD_GLOBAL', or even to eliminate it completely as some expressions could be folded.
>
> * Enum names are dynamic. There are a number of ways of having enumerations, but they are all going to suffer from the same problem of names possibly being rebound to something else. That means executing LOAD_GLOBAL or doing attribute lookups, instead of LOAD_CONST.
>
Definitely agree with this. Having a way to declare that a name is
"truly constant" would be extremely handy; there currently isn't a
way, and I'm not sure whether FAT Python is looking into this or not.
I think it's more focusing on the situation where something simply has
never been rebound, which is probably the better optimization; but
sometimes it'd be nice to be able to assert that something *will not*
be rebound, to help with self-documenting code. (Note that "constant"
implies both "never rebound" and "immutable". I actually don't care
about the latter; you could, for instance, declare that "sys.path" is
a constant list, which means you're not allowed to replace it with a
different list, but are allowed to append to it or remove from it.)
> * Without a way of defining compile-time constants, very useful language features such as 'switch' are not practical.
Maybe, but I honestly don't miss 'switch' all that often - and when I
do, it's usually because I want a range. Consider this
semi-hypothetical Pike code:
switch (key)
{
case 'A'..'Z': case 'a'..'z': return "Letter";
case 0xFF00..0xFFFF: return "Special key";
case '.': case ',': case '!': return "Punctuation";
default: return "Other";
}
With a small number of cases, this wouldn't be too bad in if/elif
form; but as it gets bigger, the value of a switch block becomes
evident. The normal advice in Python is "use a dispatch dictionary",
but that would be impractical here. So this would end up being a
massive if/elif tree, because there's just no better way to do this.
> * Python 3 has decided to have a single 'long' type for integers, instead of separate int (32 or 64-bit) and long types. This gives a noticeable slow-down in programs executing lots of integer code, compared with Python 2.
>
Actually no, this isn't a language problem - the unified type isn't
the problem here. (How can I say this for certain? Because Pike has a
single 'int' type which is a machine word if it can be, and a GMP
arbitrary-precision integer otherwise.) If someone wanted to put in
the work, CPython could have its integer type have, *in itself*, this
optimization; it'd have no externally-visible effect other than
performance.
That said, though: I suspect the reason nobody's gone and done this is
not that it wouldn't be any benefit, but that applications doing a lot
of integer code are usually going to see more benefit from Numpy,
Cython, or PyPy, and it'll be worth making that switch. So the "real
benefit" to general CPython execution wouldn't be as much as you might
think, and nobody's picked up one of those circular tuits.
> * Attribute names are completely arbitrary. Any attribute of any name can be added to a class or class instance at any time, and probably removed too (I don't know much about Python classes). This requires a name lookup. (Other languages may pre-define a fixed set of field and method names, which simplifies the resolving required at runtime.
>
See above regarding modules. This is the same issue again.
> * CPython seems to use a reference-counting scheme for all kinds of objects, including simple value types (int and float for example, although Python 3 appears to have eliminated int as I said above).
Py3 hasn't eliminated int; and yes, all "simple value types" in Python
are still boxed values. This means that there is literally NO value
that you can pass to this function that it won't be able to handle:
def display(obj):
print("Type:", obj.__class__.__name__)
print("Attributes available:", len(dir(obj)))
descr = repr(obj)
if len(descr) > 80:
descr = descr[:60] + " ... " + descr[-15:]
print("Description:")
print(descr)
Being able to depend on "everything is an object" is a huge benefit in
Python. (BTW, "reference counting" is a red herring here. Not all
Python implementations use refcounting, and it has nothing to do with
this issue; the significance is that even ints and floats are
objects.)
> * The use of conditional imports, conditional def and class statements, using eval() and exec(), even writing source code out at runtime before loading that via an import, and conditional rebinding of names to other things, mean that static analysis of source code, to get around some of the issues, is much harder.
>
Again, new attributes can be created dynamically, even of modules,
which makes new globals. FAT Python deals with this by not caring
about the specifics you're talking about, but only asking one
question: "Has this been rebound?".
> * I may be mistaken, but numeric constants such as 'A' (ie. 65 in ASCII) cannot be written in Python. 'A' is a string. Using ord('A') will work, but that's a runtime operation (as 'ord' might have been reassigned as something else. It can't generate LOAD_CONST (65)).
>
You're not mistaken. There are no "character constants" in Python.
(Note that the definition would be Unicode codepoints, rather than
ASCII values.) I don't often miss them, though.
> * I think that being unable to do proper in-place modifying of strings (in the form of s+="a") also has an effect on optimising. In any case, it has a big effect on the benchmark shown below.
>
Hmm, I would agree, but the other way around: the immutability of
strings is a significant _benefit_ to optimization. Without it,
strings would have to be copied at all sorts of places, lest it be
changed out from under you.
> * Even what appear to be names that are a fixed part of the language, such as 'range', 'int', and the 'ord' mentioned above, are actually identifiers that the user can change. So int(s) might convert a string to a number, or it could be any function call at all.
>
Yet another case of the same problem that FAT Python is trying to
solve - that anything can be rebound, but usually nothing will be.
> * math.sqrt has been mentioned; such basic operations would benefit from being an inherent part of the language that cannot be changed.:
Not sure how fundamental square-rooting really is, but whatever. Yes,
stuff can get rebound, so you can't assume. FAT Python takes the
option of check-then-assume.
> The String Append Benchmark
>
> This is a microbenchmark, but makes use of a technique I use extensively (creating a file for example by growing a string a character at a time).
>
> def test():
> s=""
> for i in range(10000000):
> s+="*"
> print (len(s))
>
> test()
>
> Both Python 2 and 3 take around 14 seconds to complete this.
Not sure what your computer is, but mine takes half a second. I added
another zero to it, and also "try: range = xrange; except NameError:
pass" so Python 2 wouldn't be penalized by having to construct a
massive list (which doubled the Py2 time, after the length increase).
This is a benchmark that will generally perform TERRIBLY on any
language with an immutable string type. But try, instead, this
version:
try: range = xrange
except NameError: pass
def test():
s=[]
for i in range(100000000):
s.append("*")
s = "".join(s)
print (len(s))
test()
For anything other than individual characters, this is likely to
perform better. However, I was unable to see this, because *CPython
does optimize string appends*. It's not a language flaw if an
invisible optimization can eliminate it.
ChrisA
[toc] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 01:16 +0000 |
| Message-ID | <nbvqg5$3cm$1@dont-email.me> |
| In reply to | #104645 |
On 11/03/2016 21:36, Chris Angelico wrote:
> On Sat, Mar 12, 2016 at 5:57 AM, BartC <bc@freeuk.com> wrote:
>> Functions are dynamic. That is, you don't know the F in F() is actually a function, even if it was defined a few lines previously, because it could have been rebound to something else. That means a runtime check to ensure that it is one.
> All of these are really one thing: When you compile some code, you
> don't know whether F() is still going to be the same object when you
> run it. FAT Python is intended to pick this up;
That's an interesting project. And they seem to understand the problems.
it recognizes
> constants, and can then perform all the other optimizations you
> describe (since functions are themselves immutable, all you need is an
> identity check on the function object itself, and everything else you
> describe can be done safely).
You mean the compiler assumes it's a particular function, but adds a
runtime check? (Perhaps by generating two call sequences, one fast, and
selecting the path at runtime.)
>> * Variables are dynamic. So you can't for example declare (with a new const feature)
'const rows=50'
> Definitely agree with this. Having a way to declare that a name is
> "truly constant" would be extremely handy; there currently isn't a
> way, and I'm not sure whether FAT Python is looking into this or not.
> I think it's more focusing on the situation where something simply has
> never been rebound, which is probably the better optimization; but
> sometimes it'd be nice to be able to assert that something *will not*
> be rebound, to help with self-documenting code. (Note that "constant"
> implies both "never rebound" and "immutable".
The 'const' prefix here is intended to define a named constant (a
numeric literal with a convenient alias) rather than some 'read-only
attribute for a conventional variable.
But introducing that into Python would be a can of worms. (A named
constant needs a compile-time expression on the right-hand-side. The
compiler needs to be able to see named constants which are in an
imported module, and which are accessed via attributes, and so on.)
>> * Without a way of defining compile-time constants, very useful language features such as 'switch' are not practical.
>
> Maybe, but I honestly don't miss 'switch' all that often - and when I
> do, it's usually because I want a range. Consider this
> semi-hypothetical Pike code:
>
> switch (key)
> {
> case 'A'..'Z': case 'a'..'z': return "Letter";
> case 0xFF00..0xFFFF: return "Special key";
> case '.': case ',': case '!': return "Punctuation";
> default: return "Other";
> }
>
> With a small number of cases, this wouldn't be too bad in if/elif
> form; but as it gets bigger, the value of a switch block becomes
> evident. The normal advice in Python is "use a dispatch dictionary",
> but that would be impractical here. So this would end up being a
> massive if/elif tree, because there's just no better way to do this.
Your example doesn't really need a switch: a range check and a
predefined list or tuple which maps 0 to 255 to a certain string.
Otherwise a list of functions indexed by the switch key would generally
do, and might be faster than an if-elsif chain. But there's some untidy
setup code and the rest would be spread out across various functions.
A proper 'switch' statement takes care of all that setup code, and keeps
the blocks of code localised. And selection of the correct bit of code
is very fast, as it's done inside the interpreter with a single
byte-code (well, load and switch).
(See yet another microbenchmark below.)
>> * Python 3 has decided to have a single 'long' type for integers, instead of separate int (32 or 64-bit) and long types. This gives a noticeable slow-down in programs executing lots of integer code, compared with Python 2.
> That said, though: I suspect the reason nobody's gone and done this is
> not that it wouldn't be any benefit, but that applications doing a lot
> of integer code are usually going to see more benefit from Numpy,
> Cython, or PyPy,
You'd be surprised how much any kind of program relies on adhoc integer
operations. It doesn't need to work with large int arrays for them to be
important. (Look at the benchmark below: the inner loop is nearly all
integer ops.)
> For anything other than individual characters, this is likely to
> perform better. However, I was unable to see this, because *CPython
> does optimize string appends*.
I guess mine doesn't! (I don't think my PC is 30 times slower than yours.)
----------------------------
'Switch' testing benchmark. The little program show below reads a text
file (I used the entire CPython C sources, 6MB), and counts the number
of characters of each category in upper, lower, digit and other.
(Note there are other ways to approach this task, but a proper 'lexer'
usually does more than count. 'Switch' then becomes invaluable.)
On my machine, I got 2.8 - 3.6 seconds (PyPy 0.4 seconds).
I tried my bytecode language, with the same if-else chain, and it was
0.6 seconds. Then I used 'switch', and it halved to 0.3 seconds.
And the switch here looks at only 3 different groups; typical switch
statements might have dozens. Switch can make a big difference! However,
because of the problem with consts, it would be awkward to add to Python
(it would be unlikely anyway).
(I then tried something else, and got 0.08 seconds ...
http://pastebin.com/whSbieiW for the (non-Python) code.)
upper=0
lower=0
digits=0
other=0
def lex(data):
global upper,lower,digits,other
AA=ord('A')
ZZ=ord('Z')
aa=ord('a')
zz=ord('z')
ZERO=ord('0')
NINE=ord('9')
for c in data:
k=ord(c)
if AA<=k<=ZZ:
upper+=1
elif aa<=k<=zz:
lower+=1
elif ZERO<=k<=NINE:
digits+=1
else:
other+=1
print ("READING")
with open ("big", "r") as myfile:
data=myfile.read()
print ("LEXING")
lex(data)
print ("Upper",upper)
print ("Lower",lower)
print ("Digits",digits)
print ("Other",other)
print ("Total",upper+lower+digits+other)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-03-11 21:02 -0800 |
| Message-ID | <9bfa08ea-2ae4-482c-85a4-1fa45944dfb4@googlegroups.com> |
| In reply to | #104666 |
On Saturday, March 12, 2016 at 7:50:43 AM UTC+5:30, Chris Angelico wrote: > On Sat, Mar 12, 2016 at 12:16 PM, BartC wrote: > > You'd be surprised how much any kind of program relies on adhoc integer > > operations. It doesn't need to work with large int arrays for them to be > > important. (Look at the benchmark below: the inner loop is nearly all > > integer ops.) > > Sure, but in real-world code, there are other considerations than just > integer performance. If someone waves a magic wand and improves > machine-word integer performance, great, but there are other calls on > core dev time. I guess that BartC (or is it Bartc?) is describing something that is a commonplace in compiler world but not so well known elsewhere, viz. a simple operation like an array/attribute-access etc, which from a HLL pov may have no 'operations' at all may emit a slew of integer operations when compiled. Which is not so surprising if you consider that apart from control-flow there is nothing going on in a CPU beside arithmetic; there is no datatype beside integers of various sizes and (un)signed combos.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 11:50 +0000 |
| Message-ID | <nc0vka$c5b$1@dont-email.me> |
| In reply to | #104666 |
On 12/03/2016 02:20, Chris Angelico wrote: > On Sat, Mar 12, 2016 at 12:16 PM, BartC <bc@freeuk.com> wrote: >> 'Switch' testing benchmark. The little program show below reads a text file >> (I used the entire CPython C sources, 6MB), and counts the number of >> characters of each category in upper, lower, digit and other. >> >> (Note there are other ways to approach this task, but a proper 'lexer' >> usually does more than count. 'Switch' then becomes invaluable.) > > Are you assuming that the files are entirely ASCII? (They're not.) Or > are you simply declaring that all non-ASCII characters count as > "other"? > Once again, you cannot ignore Unicode and pretend that everything's > ASCII, or eight-bit characters, or something. Asking if a character is > upper/lower/digit/other is best done with the unicodedata module. If you're looking at fast processing of language source code (in a thread partly about efficiency), then you cannot ignore the fact that the vast majority of characters being processed are going to have ASCII codes. Language syntax could anyway stipulate that certain tokens can only consist of characters within the ASCII range. So I'm not ignoring Unicode, but being realistic. (My benchmark was anyway just demonstrating a possible use for 'switch' that more or less matched your own example!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 14:13 +0200 |
| Message-ID | <87oaajgahd.fsf@elektro.pacujo.net> |
| In reply to | #104692 |
BartC <bc@freeuk.com>:
> If you're looking at fast processing of language source code (in a
> thread partly about efficiency), then you cannot ignore the fact that
> the vast majority of characters being processed are going to have
> ASCII codes.
I don't know why you would optimize for inputting program source code.
Text in general has left ASCII behind a long time ago. Just go to
Wikipedia and click on any of the other languages.
Why, look at the *English* page on Hillary Clinton:
Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born
October 26, 1947) is an American politician.
<URL: https://en.wikipedia.org/wiki/Hillary_Clinton>
You couldn't get past the first sentence in ASCII.
> Language syntax could anyway stipulate that certain tokens can only
> consist of characters within the ASCII range.
Many programming languages do stipulate that. Nowadays, the main reason
for the limitation is that all keyboards can produce ASCII and no
keyboard can produce all of Unicode.
Actually, when I was in college, not all keyboards could produce ASCII.
That's why the Pascal programming language offers digraphs:
(* here is a comment *)
for:
{ here is a comment }
and:
someArray(.7,3.)
for:
someArray[7,3]
(The weird American symbols {}[]\|#$^~ were abandoned and replaced with
something more relevant on European keyboards. Even the Brits would have
£ instead of #.)
In fact, the current C standard supports trigraphs for the same reason:
??= #
??/ \
??' ^
??( [
??) ]
??! |
??< {
??> }
??- ~
[...]
To safely place two consecutive question marks within a string
literal, the programmer can use string concatenation "...?""?..."
<URL: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C>
So be careful out there...
Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 13:18 +0000 |
| Message-ID | <nc14on$u9c$1@dont-email.me> |
| In reply to | #104695 |
On 12/03/2016 12:13, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> If you're looking at fast processing of language source code (in a >> thread partly about efficiency), then you cannot ignore the fact that >> the vast majority of characters being processed are going to have >> ASCII codes. > > I don't know why you would optimize for inputting program source code. > Text in general has left ASCII behind a long time ago. Just go to > Wikipedia and click on any of the other languages. > > Why, look at the *English* page on Hillary Clinton: > > Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born > October 26, 1947) is an American politician. > <URL: https://en.wikipedia.org/wiki/Hillary_Clinton> > > You couldn't get past the first sentence in ASCII. I saved that page locally as a .htm file in UTF-8 encoding. I ran a modified version of my benchmark, and it appeared that 99.7% of the bytes had ASCII codes. The other 0.3% presumably were multi-byte sequences, so that the actual proportion of Unicode characters would be even less. I then saved the Arabic version of the page, which visually, when rendered, consists of 99% Arabic script. But the .htm file was still 80% ASCII! So what were you saying about ASCII being practically obsolete ... ? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 15:40 +0200 |
| Message-ID | <877fh7g6h0.fsf@elektro.pacujo.net> |
| In reply to | #104701 |
BartC <bc@freeuk.com>: > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> BartC <bc@freeuk.com>: >> >>> If you're looking at fast processing of language source code (in a >>> thread partly about efficiency), then you cannot ignore the fact >>> that the vast majority of characters being processed are going to >>> have ASCII codes. >> >> I don't know why you would optimize for inputting program source >> code. Text in general has left ASCII behind a long time ago. Just go >> to Wikipedia and click on any of the other languages. >> >> Why, look at the *English* page on Hillary Clinton: >> >> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ >> (born October 26, 1947) is an American politician. <URL: >> https://en.wikipedia.org/wiki/Hillary_Clinton> >> >> You couldn't get past the first sentence in ASCII. > > I saved that page locally as a .htm file in UTF-8 encoding. I ran a > modified version of my benchmark, and it appeared that 99.7% of the > bytes had ASCII codes. The other 0.3% presumably were multi-byte > sequences, so that the actual proportion of Unicode characters would > be even less. > > I then saved the Arabic version of the page, which visually, when > rendered, consists of 99% Arabic script. But the .htm file was still > 80% ASCII! > > So what were you saying about ASCII being practically obsolete ... ? Yes, HTML markup is all ASCII. However, as you say, the text content is often anything but. What I'm saying is that if you are designing a new programming language and associated ecosystem, you are well advised to take Unicode into account from the start. Take advantage of the hindsight; Python, Linux, C, Java and Windows were not so lucky. Marko
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-03-12 20:24 +0100 |
| Subject | Re: The Cost of Dynamism |
| Message-ID | <2760288.I9OYO65Gag@PointedEars.de> |
| In reply to | #104702 |
Marko Rauhamaa wrote: > […] HTML markup is all ASCII. Wrong. I am creating HTML documents whose source code contains Unicode characters every day. Also, the two of you fail to differentiate between US-ASCII, a 7-bit character encoding, and 8-bit or longer encodings which can *also* encode characters that can be *encoded with* US-ASCII. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-13 08:18 +1100 |
| Subject | Re: The Cost of Dynamism |
| Message-ID | <mailman.45.1457817527.12893.python-list@python.org> |
| In reply to | #104724 |
On Sun, Mar 13, 2016 at 6:24 AM, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote: > Marko Rauhamaa wrote: > >> […] HTML markup is all ASCII. > > Wrong. I am creating HTML documents whose source code contains Unicode > characters every day. > > Also, the two of you fail to differentiate between US-ASCII, a 7-bit > character encoding, and 8-bit or longer encodings which can *also* encode > characters that can be *encoded with* US-ASCII. Where are the non-ASCII characters in your HTML documents? Are they in the *markup* of HTML, or in the *text*? This is the difference. And I'm not conflating those two. When I say ASCII, I am referring to the 128 characters that have Unicode codepoints U+0000 through U+007F. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-03-13 21:05 +0100 |
| Subject | Re: The Cost of Dynamism |
| Message-ID | <1507486.7rPGBhKPvK@PointedEars.de> |
| In reply to | #104727 |
Chris Angelico wrote:
> On Sun, Mar 13, 2016 at 6:24 AM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> Marko Rauhamaa wrote:
>>> […] HTML markup is all ASCII.
>>
>> Wrong. I am creating HTML documents whose source code contains Unicode
>> characters every day.
>>
>> Also, the two of you fail to differentiate between US-ASCII, a 7-bit
>> character encoding, and 8-bit or longer encodings which can *also* encode
>> characters that can be *encoded with* US-ASCII.
>
> Where are the non-ASCII characters in your HTML documents? Are they in
> the *markup* of HTML, or in the *text*? This is the difference.
There is a misconception on your part instead. The text content of an
HTML/Web document (the part between the [HTML] tags) is *part* of the (HTML)
markup as it is (at least) *a part* of the content of (HTML) elements. [1a]
[1b]
Besides, even if one would unwisely adopt your private definition of
“markup”, Unicode characters that cannot be encoded with US-ASCII are of
course allowed verbatim in attribute values, and to a lesser degree (not in
HTML 4.01 and below) in element type names and attribute names, as well –
therefore, according to even your *wrong* private definition of “markup”,
“*in* the markup of HTML”. [2][3]
Bottom line:
If one declares the character encoding that one uses in an SGML-based (HTML
up to including version 4.01, XML and all XML-based document types) or SGML-
related (HTML5) markup document (there are several possibilities for that)¹,
there is no need to use character entity references instead of plain Unicode
characters. And if you avoid spaghetti code, the probability of the need
for numeric character references in HTML is also quite low. (The same
applies to lightweight markup languages like Markdown, but let us not get
there now.)
[In fact, the possibility to use characters verbatim other than those that
can be encoded with US-ASCII applies to all Internet messages, including
e-mail and Usenet postings, and to a lesser degree (because there are fewer
declaration mechanisms available) to all forms of electronically
stored/readable text. As of RFC 5536, standards-compliant Network News
client software is even required to support MIME. [4]]
[This was a professional Web author/developer with more than a decade of
continuing work experience clarifying your misconception. I recommend
to you that you subscribe to the newsgroups in the
comp.infosystems.www.authoring.* hierarchy, where this discussion would
have been on-topic, and to <news:comp.lang.javascript>, to clarify some
of the other misconceptions that you may have acquired about
Web(-related) authoring/development.]
________
¹ This is only to be reasonably safe from surprises; several of those
markup languages require the assumption of a default character encoding
and/or the implementation of character encoding detection for their
parsers, but not all parsers are conforming, and it stands to reason
that parser efficiency can be increased if the encoding does not have
to be detected/inferred at first.
[1a] <https://en.wikipedia.org/wiki/Markup_language#Etymology_and_origin>
[1b] <https://www.w3.org/TR/1999/REC-html401-19991224
/intro/sgmltut.html#h-3.2.1>
<http://www.w3.org/TR/2014/REC-html5-20141028/dom.html#elements>
[2] <http://www.w3.org/TR/2014/REC-html5-20141028
/infrastructure.html#encoding-terminology>
[3] <https://www.w3.org/TR/1999/REC-html401-19991224
/charset.html#doc-char-set>
<http://www.w3.org/TR/2014/REC-html5-20141028/syntax.html#parsing>
[4] <http://tools.ietf.org/html/rfc5536#section-2.3>
> And I'm not conflating those two. When I say ASCII, I am referring to
> the 128 characters that have Unicode codepoints U+0000 through U+007F.
That is only your private definition of ASCII. The commonly accepted
definition is along those lines instead:
<https://en.wikipedia.org/wiki/ASCII> pp.
(See also the Specification references above.)
HTH
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-13 00:40 +1100 |
| Message-ID | <mailman.39.1457790065.12893.python-list@python.org> |
| In reply to | #104701 |
On Sun, Mar 13, 2016 at 12:18 AM, BartC <bc@freeuk.com> wrote: > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> >> BartC <bc@freeuk.com>: >> >>> If you're looking at fast processing of language source code (in a >>> thread partly about efficiency), then you cannot ignore the fact that >>> the vast majority of characters being processed are going to have >>> ASCII codes. >> >> >> I don't know why you would optimize for inputting program source code. >> Text in general has left ASCII behind a long time ago. Just go to >> Wikipedia and click on any of the other languages. >> >> Why, look at the *English* page on Hillary Clinton: >> >> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born >> October 26, 1947) is an American politician. >> <URL: https://en.wikipedia.org/wiki/Hillary_Clinton> >> >> You couldn't get past the first sentence in ASCII. > > > I saved that page locally as a .htm file in UTF-8 encoding. I ran a modified > version of my benchmark, and it appeared that 99.7% of the bytes had ASCII > codes. The other 0.3% presumably were multi-byte sequences, so that the > actual proportion of Unicode characters would be even less. > > I then saved the Arabic version of the page, which visually, when rendered, > consists of 99% Arabic script. But the .htm file was still 80% ASCII! > > So what were you saying about ASCII being practically obsolete ... ? Now take the same file and save it as plain text. See how much smaller it is. If you then take that text and embed it in a 10GB file consisting of nothing but byte value 246, it will be plainly obvious that ASCII is almost completely obsolete, and that we should optimize our code for byte 246. Or maybe, all you've proven is that *the framing around the text* is entirely ASCII, which makes sense, since HTML is trying to be compatible with a wide range of messy encodings (many of them eight-bit ASCII-compatible ones). The text itself may also consist primarily of ASCII characters, but that's a separate point. In the Arabic version, that is far less likely to be true (there'll still be a good number of ASCII characters in it, as U+0020 SPACE is heavily used in Arabic text, but a far smaller percentage). But neither of those says that ASCII is "practically obsolete", any more than you could say that the numbers from 1 to 10 become obsolete once a child learns to count further than that. The ASCII characters are an important part of the Unicode set; you can't ignore the rest of Unicode, but you certainly can't ignore ASCII, and there'll be very few pieces of human-language text which include no ASCII characters whatsoever. That's why UTF-8 is so successful; even Chinese text is often more compact in UTF-8 than in UTF-16 (despite many characters fitting into a single UTF-16 code unit, but requiring three bytes in UTF-8), when framed in HTML. However, once again, we have a sharp distinction: semantically, you support all Unicode characters equally, but then you optimize for the common ones. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-03-12 20:26 +0100 |
| Message-ID | <41656237.r9LeVsat90@PointedEars.de> |
| In reply to | #104701 |
BartC wrote: > On 12/03/2016 12:13, Marko Rauhamaa wrote: >> Why, look at the *English* page on Hillary Clinton: >> >> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born >> October 26, 1947) is an American politician. >> <URL: https://en.wikipedia.org/wiki/Hillary_Clinton> >> >> You couldn't get past the first sentence in ASCII. > > I saved that page locally as a .htm file in UTF-8 encoding. I ran a > modified version of my benchmark, and it appeared that 99.7% of the > bytes had ASCII codes. That is a contradiction in terms. Obviously you do not know what ASCII is. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 22:14 +0000 |
| Message-ID | <nc246r$vsh$1@dont-email.me> |
| In reply to | #104725 |
On 12/03/2016 19:26, Thomas 'PointedEars' Lahn wrote: > BartC wrote: > >> On 12/03/2016 12:13, Marko Rauhamaa wrote: >>> Why, look at the *English* page on Hillary Clinton: >>> >>> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/ (born >>> October 26, 1947) is an American politician. >>> <URL: https://en.wikipedia.org/wiki/Hillary_Clinton> >>> >>> You couldn't get past the first sentence in ASCII. >> >> I saved that page locally as a .htm file in UTF-8 encoding. I ran a >> modified version of my benchmark, and it appeared that 99.7% of the >> bytes had ASCII codes. > > That is a contradiction in terms. Obviously you do not know what ASCII is. What does your own analysis show of that page? If you had it in memory as fully expanded 32-bit Unicode values, what proportion of those would have values below 128? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-03-13 21:08 +0100 |
| Subject | Re: The Cost of Dynamism |
| Message-ID | <10724352.BI8eYDRtO4@PointedEars.de> |
| In reply to | #104730 |
BartC wrote:
> On 12/03/2016 19:26, Thomas 'PointedEars' Lahn wrote:
>> BartC wrote:
>>> On 12/03/2016 12:13, Marko Rauhamaa wrote:
>>>> Why, look at the *English* page on Hillary Clinton:
>>>>
>>>> Hillary Diane Rodham Clinton /ˈhɪləri daɪˈæn ˈrɒdəm ˈklɪntən/
>>>> (born October 26, 1947) is an American politician.
>>>> <URL: https://en.wikipedia.org/wiki/Hillary_Clinton>
>>>>
>>>> You couldn't get past the first sentence in ASCII.
>>>
>>> I saved that page locally as a .htm file in UTF-8 encoding. I ran a
^^^^^^^^^^^^^^^^^^^^^^
>>> modified version of my benchmark, and it appeared that 99.7% of the
>>> bytes had ASCII codes.
^^^^^^^^^^^^^^^^^^^^^
>> That is a contradiction in terms. Obviously you do not know what ASCII
>> is.
>
> What does your own analysis show of that page?
>
> If you had it in memory as fully expanded 32-bit Unicode values, what
> proportion of those would have values below 128?
You are missing the point.
--
PointedEars
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2016-03-12 20:20 +0100 |
| Subject | Re: The Cost of Dynamism |
| Message-ID | <2096053.QjpYRpHg5h@PointedEars.de> |
| In reply to | #104695 |
Marko Rauhamaa wrote: > […] all keyboards can produce ASCII and no keyboard can produce all of > Unicode. Both claims are wrong. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-12 23:52 +1100 |
| Message-ID | <mailman.37.1457787137.12893.python-list@python.org> |
| In reply to | #104692 |
On Sat, Mar 12, 2016 at 10:50 PM, BartC <bc@freeuk.com> wrote: > On 12/03/2016 02:20, Chris Angelico wrote: >> >> On Sat, Mar 12, 2016 at 12:16 PM, BartC <bc@freeuk.com> wrote: > > >>> 'Switch' testing benchmark. The little program show below reads a text >>> file >>> (I used the entire CPython C sources, 6MB), and counts the number of >>> characters of each category in upper, lower, digit and other. >>> >>> (Note there are other ways to approach this task, but a proper 'lexer' >>> usually does more than count. 'Switch' then becomes invaluable.) >> >> >> Are you assuming that the files are entirely ASCII? (They're not.) Or >> are you simply declaring that all non-ASCII characters count as >> "other"? > > >> Once again, you cannot ignore Unicode and pretend that everything's >> ASCII, or eight-bit characters, or something. Asking if a character is >> upper/lower/digit/other is best done with the unicodedata module. > > > If you're looking at fast processing of language source code (in a thread > partly about efficiency), then you cannot ignore the fact that the vast > majority of characters being processed are going to have ASCII codes. > > Language syntax could anyway stipulate that certain tokens can only consist > of characters within the ASCII range. > > So I'm not ignoring Unicode, but being realistic. > > (My benchmark was anyway just demonstrating a possible use for 'switch' that > more or less matched your own example!) Generally languages these days are built using ASCII tokens, because they can be dependably typed on all keyboards. But there's no requirement for that, and I understand there's a Chinese Python that has all the language keywords translated. And identifiers can - and most definitely SHOULD - be defined in terms of Unicode characters and their types. So ultimately, the lexer needs to be Unicode-aware. But in terms of efficiency, yes, you can't ignore that most files will be all-ASCII. And since 3.3, Python has had an optimization for such strings. So the performance question isn't ignored - but it's an invisible optimization within a clearly-defined semantic, namely that Python source code is a sequence of Unicode characters. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-13 03:22 +1100 |
| Message-ID | <56e44258$0$1598$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104666 |
On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote: >>> Definitely agree with this. Having a way to declare that a name is >>> "truly constant" would be extremely handy; there currently isn't a >>> way, and I'm not sure whether FAT Python is looking into this or not. "Constants" would be a new language feature, not an optimization. Unless CPython adds a constant feature, FAT Python isn't going to do it. >>> I think it's more focusing on the situation where something simply has >>> never been rebound, which is probably the better optimization; but >>> sometimes it'd be nice to be able to assert that something *will not* >>> be rebound, to help with self-documenting code. (Note that "constant" >>> implies both "never rebound" and "immutable". I disagree that constant necessarily implies immutable, at least in the context of Python. At least, what *I* want from a const keyword is a way to make a certain name "write-once": you can bind to it the first time, and then never again for the life of the scope. It shouldn't matter whether it is a list or a float. >> The 'const' prefix here is intended to define a named constant (a numeric >> literal with a convenient alias) rather than some 'read-only attribute >> for a conventional variable. >> >> But introducing that into Python would be a can of worms. (A named >> constant needs a compile-time expression on the right-hand-side. The >> compiler needs to be able to see named constants which are in an imported >> module, and which are accessed via attributes, and so on.) I disagree with that too. It is a limitation of older languages like Pascal and C that they can only define "consts" at compile time. But we can dynamically create constants at runtime too. Here's a proof-of-concept. Let's put efficiency aside and consider a naive "bind-once" const for a language like Python. Every namespace has a mapping of name:value, as we have now, plus a list of "constant names". Then every binding operation: x = value import x from module import x del x def x(): ... class x: ... for x in seq: ... with expr as x: ... except error as x: ... first checks the list of constant names for the name (e.g. "x"). If the name is not found, then the binding operation is allowed, just like it is today. If it is found, then the namespace is checked to see if the name already exists. If it does, the operation raises a TypeError (or perhaps ConstError?). If not, then the operation continues as normal. > Not sure about that. Consider: > > MAX_SIZE = 1<<16 > def some_func(blah): > data = some_file.read(MAX_SIZE) > > Currently, this disassembles to show that MAX_SIZE is being fetched > with LOAD_GLOBAL. If, instead, it were LOAD_CONST, this would mean > that rebinding MAX_SIZE after function definition would fail; I don't think it would fail in the sense of raising an explicit exception. I think it would just be hard to understand, giving you strange and mysterious behaviour: there's a name which I can successfully rebind, but some functions accessing it still see the old value, while others see the new value. But then, that's not far from the current behaviour of "early binding" of default values. > but it > would run faster. That's the advantage of a "declared constant", even > without it being any sort of compile-time constant. As long as it can > be finalized before the function is defined, it can be called > constant. Constants should be treated as constant even outside of functions. Maybe the secret is to make modules more like functions in their internal details? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-13 08:45 +1100 |
| Message-ID | <mailman.46.1457819135.12893.python-list@python.org> |
| In reply to | #104712 |
On Sun, Mar 13, 2016 at 3:22 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 12 Mar 2016 01:20 pm, Chris Angelico wrote:
>
>
>>>> Definitely agree with this. Having a way to declare that a name is
>>>> "truly constant" would be extremely handy; there currently isn't a
>>>> way, and I'm not sure whether FAT Python is looking into this or not.
>
> "Constants" would be a new language feature, not an optimization. Unless
> CPython adds a constant feature, FAT Python isn't going to do it.
Yes, they would. Having a way to *declare*, in your source code, is
what I'm talking about. Although FAT Python does have facilities for
noticing that something hasn't changed, this is talking about
demanding that it _never_ change.
>>>> I think it's more focusing on the situation where something simply has
>>>> never been rebound, which is probably the better optimization; but
>>>> sometimes it'd be nice to be able to assert that something *will not*
>>>> be rebound, to help with self-documenting code. (Note that "constant"
>>>> implies both "never rebound" and "immutable".
>
> I disagree that constant necessarily implies immutable, at least in the
> context of Python. At least, what *I* want from a const keyword is a way to
> make a certain name "write-once": you can bind to it the first time, and
> then never again for the life of the scope. It shouldn't matter whether it
> is a list or a float.
I mean that the word generally implies that. It's perfectly possible
to have a Python keyword "constant" that means "this will never be
rebound" (ie "constant by identity"), without having "constant value";
but there will be people who are confused by it, just as (and for the
same reason as) they're confused by mutable default arguments.
There'll be posts all over the place, "never use mutable constant
values, or they stop being constant".
I completely agree with you that the keyword should mean "write-once"
or "never rebind".
> Let's put efficiency aside and consider a naive "bind-once" const for a
> language like Python. Every namespace has a mapping of name:value, as we
> have now, plus a list of "constant names". Then every binding operation:
>
> x = value
> import x
> from module import x
> del x
> def x(): ...
> class x: ...
> for x in seq: ...
> with expr as x: ...
> except error as x: ...
>
> first checks the list of constant names for the name (e.g. "x"). If the name
> is not found, then the binding operation is allowed, just like it is today.
> If it is found, then the namespace is checked to see if the name already
> exists. If it does, the operation raises a TypeError (or perhaps
> ConstError?). If not, then the operation continues as normal.
IMO, ConstError should probably be its own thing. The nearest
equivalent I can find is attempting to assign to a read-only property,
which raises AttributeError; this is broader than that.
I'd make this much, much simpler. This statement:
constant x
declares that 'x' will never, from this point on, be assigned to. And
this statement:
constant x = y
(re)binds x to the value of y, and then declares that x will never be
assigned to. All assignments simply check this list; if the name is on
the list, raise error.
So if you're doing a "constant import", or something else that does a
special form of bind, you would spell it differently:
from module import x
constant x
As a convenience, I would like to see a few common constructs, such as
"constant def" and "constant class", but we don't need "constant for"
or "constant with" (and definitely not "constant except", since that
has an implicit rebind and unbind at the end).
>> Not sure about that. Consider:
>>
>> MAX_SIZE = 1<<16
>> def some_func(blah):
>> data = some_file.read(MAX_SIZE)
>>
>> Currently, this disassembles to show that MAX_SIZE is being fetched
>> with LOAD_GLOBAL. If, instead, it were LOAD_CONST, this would mean
>> that rebinding MAX_SIZE after function definition would fail;
>
> I don't think it would fail in the sense of raising an explicit exception. I
> think it would just be hard to understand, giving you strange and
> mysterious behaviour: there's a name which I can successfully rebind, but
> some functions accessing it still see the old value, while others see the
> new value.
Yeah, it would fail in the sense that it would do the wrong thing. If
you're expecting "module.MAX_SIZE = 1<<10" to reduce the maximum, that
would silently fail to do what you expect.
Basically, what I'm talking about here is the difference between
"import x" and "from x import y". Normally, globals are effectively
"my_module.MAX_SIZE", but the LOAD_CONST transformation turns them
into "from my_module import MAX_SIZE". Rebinding the module name has
no effect on something that already imported it by value.
> But then, that's not far from the current behaviour of "early binding" of
> default values.
Exactly; the only difference is that you can't rebind it in any way
(including inside the function; when you use the "MAX_SIZE=MAX_SIZE"
trick, the compiler has to assume that you might rebind MAX_SIZE
inside the function, so it still can't use LOAD_CONST).
>> but it
>> would run faster. That's the advantage of a "declared constant", even
>> without it being any sort of compile-time constant. As long as it can
>> be finalized before the function is defined, it can be called
>> constant.
>
> Constants should be treated as constant even outside of functions.
Yes; my point was just that it doesn't have to be like a C/Pascal
style of constant. For instance:
try: from _foo import bar
except ImportError: from foo import bar
constant bar
def have_drink():
champagne = bar.pop()
Since 'bar' was declared 'constant', the compiler could take the value
as at function definition time and stash it into co_consts, because
it'll never be rebound. The actual source of that object depends on a
runtime check, and the exact value of it will vary as drinks get
popped off it, but it's a perfectly legit constant. The only
significance of function definitions is that it's a point at which a
constant will be captured, but a regular global can't be; it's the
point at which its constantness becomes an optimization, rather than
an assertion.
> Maybe the secret is to make modules more like functions in their internal
> details?
I'd be more inclined to make them more like classes, actually. Then
they could use descriptor protocol and properties and stuff. :)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-13 00:10 +0200 |
| Message-ID | <8737rvxs89.fsf@elektro.pacujo.net> |
| In reply to | #104728 |
Chris Angelico <rosuav@gmail.com>: > I completely agree with you that the keyword should mean "write-once" > or "never rebind". That would be possible. I'm afraid that would result in people sprinkling these "constant" keywords everywhere to make the program supposedly run faster. -- Something like that has happened with the "final" keyword in some Java houses. That would prevent the ad hoc installation of wrappers, debugging tools etc. Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-13 09:19 +1100 |
| Message-ID | <mailman.47.1457821167.12893.python-list@python.org> |
| In reply to | #104729 |
On Sun, Mar 13, 2016 at 9:10 AM, Marko Rauhamaa <marko@pacujo.net> wrote: > Chris Angelico <rosuav@gmail.com>: > >> I completely agree with you that the keyword should mean "write-once" >> or "never rebind". > > That would be possible. I'm afraid that would result in people > sprinkling these "constant" keywords everywhere to make the program > supposedly run faster. -- Something like that has happened with the > "final" keyword in some Java houses. > > That would prevent the ad hoc installation of wrappers, debugging tools > etc. Hmm. I wonder if it should be like "assert" - nobody ever should depend 100% on it, but it's a hint back to the interpreter that you should never be rebinding this. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web