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 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-13 00:57 +0200 |
| Message-ID | <87k2l7wbia.fsf@elektro.pacujo.net> |
| In reply to | #104731 |
Chris Angelico <rosuav@gmail.com>: > 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. Just wait and see what will happen. BTW, Java's "final" keyword is additionally used to declare that a method is not overridden. I once worked in a Java company where the policy was to declare *everything* final until you knew that you needed to inherit. Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 23:57 +0000 |
| Message-ID | <nc2a7s$6dv$1@dont-email.me> |
| In reply to | #104729 |
On 12/03/2016 22:10, Marko Rauhamaa 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. I use 'const' everywhere in other languages, most often in the form of sophisticated sets of enums. A single project might have 1000 or even 2000. (Example that defines a set of byte-codes: http://pastebin.com/q1UwjKmK) How does Python manage without them? Is it really necessary to declare hundreds of individual variables and assign a value to each? (And risk someone assigning a new value to them.) That they might lead to more efficient code is secondary, but definitely a bonus (essential though when used in a switch statement). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-13 01:10 +0000 |
| Message-ID | <mailman.48.1457831488.12893.python-list@python.org> |
| In reply to | #104733 |
On 12/03/2016 23:57, BartC wrote: > On 12/03/2016 22:10, Marko Rauhamaa 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. > > I use 'const' everywhere in other languages, most often in the form of > sophisticated sets of enums. A single project might have 1000 or even > 2000. (Example that defines a set of byte-codes: > http://pastebin.com/q1UwjKmK) > > How does Python manage without them? Is it really necessary to declare > hundreds of individual variables and assign a value to each? (And risk > someone assigning a new value to them.) > > That they might lead to more efficient code is secondary, but definitely > a bonus (essential though when used in a switch statement). > It is 2016. Programmer time, and hence money, are far more important than runtime speed in the vast majority of cases. There are plenty of working recipes for switch in Python. I'll leave you to quote a few as you are such an expert in the Python programming language. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-13 19:39 +0000 |
| Message-ID | <nc4ffn$f6s$1@dont-email.me> |
| In reply to | #104734 |
On 13/03/2016 01:10, Mark Lawrence wrote:
> On 12/03/2016 23:57, BartC wrote:
[switch statements]
>> How does Python manage without them? Is it really necessary to declare
>> hundreds of individual variables and assign a value to each? (And risk
>> someone assigning a new value to them.)
>>
>> That they might lead to more efficient code is secondary, but definitely
>> a bonus (essential though when used in a switch statement).
>>
>
> It is 2016. Programmer time, and hence money, are far more important
> than runtime speed in the vast majority of cases.
Exactly why having ready-made solutions is preferable to everyone
hacking their own solutions to switch.
> There are plenty of
> working recipes for switch in Python. I'll leave you to quote a few as
> you are such an expert in the Python programming language.
I've seen a few. Here's one that uses:
class switch(object):
value = None
def __new__(class_, value):
class_.value = value
return True
def case(*args):
return any((arg == switch.value for arg in args))
I used it in my benchmark to replace the if-else chain checking three
lots of ranges:
switch(c)
if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
ord("G"),ord("H"),ord("I"),ord("J"),ord("K"),ord("L"),
ord("M"),ord("N"),ord("O"),ord("P"),ord("Q"),ord("R"),
ord("S"),ord("T"),ord("U"),ord("V"),ord("W"),ord("X"),
ord("Y"),ord("Z")):
upper+=1
elif case(ord("a"),ord("b"),ord("c"),ord("d"),ord("e"),ord("f"),
ord("g"),ord("h"),ord("i"),ord("j"),ord("k"),ord("l"),
ord("m"),ord("n"),ord("o"),ord("p"),ord("q"),ord("r"),
ord("s"),ord("t"),ord("u"),ord("v"),ord("w"),ord("x"),
ord("y"),ord("z")):
lower+=1
elif case(ord("0"),ord("1"),ord("2"),ord("3"),ord("4"),ord("5"),
ord("6"),ord("7"),ord("8"),ord("9")):
digits+=1
else:
other+=1
It worked, but took 110 seconds; 80 seconds without the ord's and
comparing strings (but I still think it's perverse that integer ops are
slower than string ops).
But 110 or 80 seconds, the original Python was 3.6 seconds. (Probably,
someone could tweak it to work with ranges, but this is extra programmer
effort that you say is too valuable to waste on such matters.)
(An actual 62-way if-elif chain took 25 seconds in Python 3.
You might care not about speed, but it's something when the fastest
solution in a language with built-in switch, and /still interpreting a
byte-code at a time/, is 1000 times faster than the 80-second version
above.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-13 22:12 +0200 |
| Message-ID | <87y49muoh6.fsf@elektro.pacujo.net> |
| In reply to | #104779 |
BartC <bc@freeuk.com>: > Exactly why having ready-made solutions is preferable to everyone > hacking their own solutions to switch. A developer friend of mine once said insightfully that the point of OO is getting rid of switch statements. IOW, most use cases for switch statements are handled with virtual functions. The most significant exception in my experience is message decoding, where switches/ifs cannot be avoided. Marko
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-14 17:17 +0000 |
| Message-ID | <mailman.120.1457975931.12893.python-list@python.org> |
| In reply to | #104782 |
On 13/03/2016 20:12, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> Exactly why having ready-made solutions is preferable to everyone >> hacking their own solutions to switch. > > A developer friend of mine once said insightfully that the point of OO > is getting rid of switch statements. IOW, most use cases for switch > statements are handled with virtual functions. > > The most significant exception in my experience is message decoding, > where switches/ifs cannot be avoided. > > > Marko > http://c2.com/cgi/wiki?SwitchStatementsSmell -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-14 17:53 +0000 |
| Message-ID | <nc6tl9$m0m$1@dont-email.me> |
| In reply to | #104844 |
On 14/03/2016 17:17, Mark Lawrence wrote: > On 13/03/2016 20:12, Marko Rauhamaa wrote: >> BartC <bc@freeuk.com>: >> >>> Exactly why having ready-made solutions is preferable to everyone >>> hacking their own solutions to switch. >> >> A developer friend of mine once said insightfully that the point of OO >> is getting rid of switch statements. IOW, most use cases for switch >> statements are handled with virtual functions. >> >> The most significant exception in my experience is message decoding, >> where switches/ifs cannot be avoided. > http://c2.com/cgi/wiki?SwitchStatementsSmell I get it. The author doesn't like switch statements! But they can be a succinct and convenient way of expressing some code patterns. Nobody is obliged to use them, but it would nice for a language to give the /choice/. And since they mainly involve syntax, the cost of providing them is small. Here's one pattern: switch X when A,B then S1 when C then S2 when D,E,F then S3 else S4 end switch The typical characteristics - when A to F are known at compile-time - are: * X is only evaluated once * None of A to F need to be evaluated * Only a single test is needed, no matter how many case expressions * Only one of S1 to S4 is executed (at most one when there is no else) (When A to F are not known at compile time, then it might be implemented differently. X is still evaluated once, but A to F are evaluated and tested in sequence until a match or not is found. However, nothing need change in the source.) Here's another pattern, which can also be implemented with an underlying switch: X = (N |A, B, C, ... |Z) This selects the N'th value from A, B, C (in Python, probably 0-based). Z is the default if N is out of range. A, B, C can be any expressions. The main characteristic is that only *one* of A, B, C or Z evaluated, which is the difference between just using a list. Really, it becomes difficult to see what people have against switch. (Unless perhaps their favourite language doesn't have it and they're trying to justify that.) > http://c2.com/cgi/wiki?SwitchStatementsSmell (Code-smell to me means code dominated by loads of classes, especially for no good reason. But I'm not suggesting a language shouldn't have them.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-14 20:25 +0200 |
| Message-ID | <87k2l4ex24.fsf@elektro.pacujo.net> |
| In reply to | #104849 |
BartC <bc@freeuk.com>: > (Code-smell to me means code dominated by loads of classes, especially > for no good reason. But I'm not suggesting a language shouldn't have > them.) Ok, you don't like OO. Fine. Python is deep in OO. "When in Rome, do as the Romans do." Personally, I think OO is quite a cromulent paradigm. Marko PS Classes are not necessary for OO, but Python has taken that traditional path.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-14 18:39 +0000 |
| Message-ID | <nc70bd$1kc$1@dont-email.me> |
| In reply to | #104852 |
On 14/03/2016 18:25, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> (Code-smell to me means code dominated by loads of classes, especially >> for no good reason. But I'm not suggesting a language shouldn't have >> them.) > > Ok, you don't like OO. Fine. Python is deep in OO. > > "When in Rome, do as the Romans do." > > Personally, I think OO is quite a cromulent paradigm. I've looked up cromulent but I'm still note sure whether you like OO or not! (For myself, I've actually implemented some OO features, partly because you tend to end up there as a natural progression of language design. But I use them sparingly. It's other people's use of it I object to...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-14 20:57 +0000 |
| Message-ID | <mailman.127.1457989105.12893.python-list@python.org> |
| In reply to | #104849 |
On 14/03/2016 17:53, BartC wrote: > On 14/03/2016 17:17, Mark Lawrence wrote: >> On 13/03/2016 20:12, Marko Rauhamaa wrote: >>> BartC <bc@freeuk.com>: >>> >>>> Exactly why having ready-made solutions is preferable to everyone >>>> hacking their own solutions to switch. >>> >>> A developer friend of mine once said insightfully that the point of OO >>> is getting rid of switch statements. IOW, most use cases for switch >>> statements are handled with virtual functions. >>> >>> The most significant exception in my experience is message decoding, >>> where switches/ifs cannot be avoided. > >> http://c2.com/cgi/wiki?SwitchStatementsSmell > > I get it. The author doesn't like switch statements! > You clearly didn't bother reading the document. I suggest you try again, and then attempt, just for once, to come back with some worthwhile comments. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-15 12:55 +1100 |
| Message-ID | <56e76b93$0$1616$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104849 |
On Tue, 15 Mar 2016 04:53 am, BartC wrote:
> On 14/03/2016 17:17, Mark Lawrence wrote:
>> On 13/03/2016 20:12, Marko Rauhamaa wrote:
>>> BartC <bc@freeuk.com>:
>>>
>>>> Exactly why having ready-made solutions is preferable to everyone
>>>> hacking their own solutions to switch.
>>>
>>> A developer friend of mine once said insightfully that the point of OO
>>> is getting rid of switch statements. IOW, most use cases for switch
>>> statements are handled with virtual functions.
>>>
>>> The most significant exception in my experience is message decoding,
>>> where switches/ifs cannot be avoided.
>
>> http://c2.com/cgi/wiki?SwitchStatementsSmell
>
> I get it. The author doesn't like switch statements!
I don't think you do -- there's no "the author". It's a wiki. There's
potentially *thousands* of "authors". The page you (might have) read is a
discussion between many different people, debating the pros and cons of
switches.
Also, the person quoted in the first paragraph is not just any author, but
Martin Fowler, one of the acknowledged authorities on object oriented
programming, refactoring, agile methodology and others:
https://en.wikipedia.org/wiki/Martin_Fowler
So he is worth listening to, even if you end up disagreeing.
> But they can be a succinct and convenient way of expressing some code
> patterns. Nobody is obliged to use them, but it would nice for a
> language to give the /choice/. And since they mainly involve syntax, the
> cost of providing them is small.
One of the problems with switch statements is that they are *anything but*
succinct. Compare this:
> switch X
> when A,B then S1
> when C then S2
> when D,E,F then S3
> else S4
> end switch
to the object-oriented solution, using polymorphism:
X.foo()
where foo returns S1, S2, ... S4 as appropriate, according to the type of X.
Six lines versus one expression. Which did you say was succinct again?
*wink*
In any case (pun intended), there have been two proposals to introduce a
switch/case statement to Python, including one by Guido himself.
https://www.python.org/dev/peps/pep-3103/
https://www.python.org/dev/peps/pep-0275/
> The typical characteristics - when A to F are known at compile-time - are:
>
> * X is only evaluated once
That's easy to emulate with a temporary variable.
> * None of A to F need to be evaluated
> * Only a single test is needed, no matter how many case expressions
How does the compiler know which case matches from a single test?
I think that you might be assuming that the switch statement uses a jump
table. In your case, since you wrote the language, you might be right, but
that's certainly not the case in general. In general, switch statements are
implemented as either a chain of if...else or as a jump table, or possibly
as a hybrid of the two.
http://embeddedgurus.com/stack-overflow/2010/04/efficient-c-tip-12-be-wary-of-switch-statements/
Consider:
switch n:
case 0, 1, 2:
print "Small"
case 705210841296510943:
print "You found the magic number!"
case 18446744073709551610...18446744073709551615:
print "Big"
default:
print "Middling".
I'd like to see the jump table you use for that :-)
But of course, in Python any switch statement would have to support values
of any and every type, not just integers. So any implementation you are
thinking of would have to support cases like this:
switch obj:
case "Hello", None: ...
case [1, 2, 3]: ...
case 23.01, 15+2j, Fraction(10, 11): ...
case 100**100, {}: ...
and more. This is not negotiable: having a switch statement limited to small
ints is simply not an option.
> * Only one of S1 to S4 is executed (at most one when there is no else)
>
> (When A to F are not known at compile time, then it might be implemented
> differently. X is still evaluated once, but A to F are evaluated and
> tested in sequence until a match or not is found. However, nothing need
> change in the source.)
This syntax I find interesting, although it is rather limited in that you
can only switch on integers:
> Here's another pattern, which can also be implemented with an underlying
> switch:
>
> X = (N |A, B, C, ... |Z)
>
> This selects the N'th value from A, B, C (in Python, probably 0-based).
> Z is the default if N is out of range. A, B, C can be any expressions.
>
> The main characteristic is that only *one* of A, B, C or Z evaluated,
> which is the difference between just using a list.
Are there any well-known languages which support this or similar syntax?
Of course, the syntax won't work in Python, because ( ... ) is already used
for tuples, and N|A would be ambiguous with bitwise-or. The closest we have
in Python would be:
x = {A, B, C][n]
or with a default:
x = {0: A, 1: B, 2: C}.get(n, Z)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-15 13:10 +1100 |
| Message-ID | <mailman.150.1458007841.12893.python-list@python.org> |
| In reply to | #104903 |
On Tue, Mar 15, 2016 at 12:55 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> But of course, in Python any switch statement would have to support values
> of any and every type, not just integers. So any implementation you are
> thinking of would have to support cases like this:
>
>
> switch obj:
> case "Hello", None: ...
> case [1, 2, 3]: ...
> case 23.01, 15+2j, Fraction(10, 11): ...
> case 100**100, {}: ...
>
>
> and more. This is not negotiable: having a switch statement limited to small
> ints is simply not an option.
I agree that restricting switch to small ints is not an option;
however, is it truly an "of course" that a switch has to "support
values of *any and every* type"? IMO it would be fine to require that
they be hashable (which would cut out your list and empty dict, but
nothing else; and CPython 3.6 is already capable of seeing {1,2,3} and
using a literal frozenset, so the same could be used here). I've used
Python's dictionaries for umpteen years and only *very* occasionally
run into situations where some object can't be used as a key. I doubt
that I'd be bothered by a switch statement with the same restriction.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-15 11:52 +0000 |
| Message-ID | <nc8srp$2sv$1@dont-email.me> |
| In reply to | #104903 |
On 15/03/2016 01:55, Steven D'Aprano wrote:
> On Tue, 15 Mar 2016 04:53 am, BartC wrote:
>> I get it. The author doesn't like switch statements!
>
> I don't think you do -- there's no "the author". It's a wiki. There's
> potentially *thousands* of "authors". The page you (might have) read is a
> discussion between many different people, debating the pros and cons of
> switches.
I got the impression it was mostly cons, and that everyone was keen to
replace them with OO constructs.
>> But they can be a succinct and convenient way of expressing some code
>> patterns.
> One of the problems with switch statements is that they are *anything but*
> succinct. Compare this:
>
>> switch X
>> when A,B then S1
>> when C then S2
>> when D,E,F then S3
>> else S4
>> end switch
>
> to the object-oriented solution, using polymorphism:
>
> X.foo()
>
> where foo returns S1, S2, ... S4 as appropriate, according to the type of X.
(1) X.foo only looks more succinct because you've conveniently removed
A..F and S1..S4. Presumably they have to be provided somewhere else.
(2) My version switches on the *value* of X not the type. (Except of
course when you use switch type(X) then X.foo() might be better, *if*
you've done the prerequisite work of setting up the classes and methods
needed.)
> there have been two proposals to introduce a
> switch/case statement to Python, including one by Guido himself.
>
> https://www.python.org/dev/peps/pep-3103/
Which starts by saying it's been rejected. But when you read the rest,
you can sort of understand why! So many complications are put forward,
and some half-depend on the introduction of constants, that there is no
clear single solution. It comes across as a mess.
>> The typical characteristics - when A to F are known at compile-time - are:
>>
>> * X is only evaluated once
>
> That's easy to emulate with a temporary variable.
You mean when X is complex? Sure, but Python is such that even with a
local temporary, evaluating LOAD_FAST is needed before each test, with
all the reference counting that goes with it. And a STORE_FAST before
the lot. (And some switch statements may be outside a function.)
(My byte-code uses special switch compare operators that leave the test
value on the stack.)
>> * None of A to F need to be evaluated
>> * Only a single test is needed, no matter how many case expressions
>
> How does the compiler know which case matches from a single test?
>
> I think that you might be assuming that the switch statement uses a jump
> table. In your case, since you wrote the language, you might be right, but
> that's certainly not the case in general.
Not in general, but, in my code at least, testing an integer value
against a set of integer constants (literals, enums, named constants) is
used extensively. And things such as enums tend to have a compact span
of values.
And where a jump-table is not possible, then you just have to locate one
integer value within a list of constant integers (with a label
associated with each), and there are many ways to do that. Via hashing
for example, which would be done in the interpreter and would still
count as a single test.
> But of course, in Python any switch statement would have to support values
> of any and every type, not just integers. So any implementation you are
> thinking of would have to support cases like this:
>
>
> switch obj:
> case "Hello", None: ...
> case [1, 2, 3]: ...
> case 23.01, 15+2j, Fraction(10, 11): ...
> case 100**100, {}: ...
>
>
> and more. This is not negotiable: having a switch statement limited to small
> ints is simply not an option.
Not a problem: http://pastebin.com/qdQintSZ
> This syntax I find interesting, although it is rather limited in that you
> can only switch on integers:
(I use switch-when for integer-only and case-when for anything else, or
when a jumptable is not viable. See above paste.)
>> Here's another pattern, which can also be implemented with an underlying
>> switch:
>>
>> X = (N |A, B, C, ... |Z)
>>
>> This selects the N'th value from A, B, C (in Python, probably 0-based).
>> Z is the default if N is out of range. A, B, C can be any expressions.
>>
>> The main characteristic is that only *one* of A, B, C or Z evaluated,
>> which is the difference between just using a list.
>
> Are there any well-known languages which support this or similar syntax?
I pinched this syntax from Algol-68. (I think 'when' comes from Ada.)
> Of course, the syntax won't work in Python, because ( ... ) is already used
> for tuples, and N|A would be ambiguous with bitwise-or. The closest we have
> in Python would be:
Is ¦ available? Then (N¦A,B,C¦Z) would work, but is more fiddly to type.
But the syntax is not important; you could just use:
select n in a,b,c,d else z
(I think Algol68, when not using the compact form, used case n in a,b,c
out z esac or some such thing.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-15 14:58 +0000 |
| Message-ID | <nc97p5$dok$1@dont-email.me> |
| In reply to | #104936 |
On 15/03/2016 11:52, BartC wrote:
> On 15/03/2016 01:55, Steven D'Aprano wrote:
>> switch obj:
>> case "Hello", None: ...
>> case [1, 2, 3]: ...
>> case 23.01, 15+2j, Fraction(10, 11): ...
>> case 100**100, {}: ...
>>
>>
>> and more. This is not negotiable: having a switch statement limited to
>> small
>> ints is simply not an option.
>
> Not a problem: http://pastebin.com/qdQintSZ
The solution I posted tested the values one after another. I was
interested in whether it was that much faster than if-elif in CPython 3,
so I tried the test similar to that below, except that k, c and f were
literal values in the loop to start with.
Initial timings were 5 seconds for mine, 12.5 seconds for Python. That's
in line with what I expected when dealing with more complex objects.
However, I then took the 100**100 outside the loop in my version (as
that expression was not reduced to a constant). The timing then reduced
to 170ms (I have a slow big num library).
But doing the same with Python made no difference. Taking Complex and
Fraction outside reduced the timing to 8 seconds, still 50 times slower.
(My language doesn't understand Complex and Fraction, so testing against
those is a quick process. Taking those out completely as well as
100**100 made a difference, but there was the same discrepancy)
I know my language isn't that fast, so something is slowing down the
Python in this test (and I don't /think/ I've left a zero out in my
version!)
So maybe it makes the case for a proper Switch in Python stronger where
such comparisons could be streamlined.
from fractions import Fraction
def test():
data=["Hello",None,[1,2,3],23.01,15+2j,Fraction(10,11),100**100,{},12345]
# print (data)
k=100**100
c=15+2j
f=Fraction(10,11)
for n in range(100000):
for obj in data:
if obj=="hello" or obj==None:
pass
elif obj==[1,2,3]:
pass
elif obj==23.01 or obj==c or obj==f:
pass
elif obj==k or obj=={}:
pass
test()
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-15 18:28 +0000 |
| Message-ID | <nc9k22$56v$1@dont-email.me> |
| In reply to | #104943 |
On 15/03/2016 14:58, BartC wrote:
> On 15/03/2016 11:52, BartC wrote:
>> On 15/03/2016 01:55, Steven D'Aprano wrote:
>
>>> switch obj:
>>> case "Hello", None: ...
>>> case [1, 2, 3]: ...
>>> case 23.01, 15+2j, Fraction(10, 11): ...
>>> case 100**100, {}: ...
>>>
>>>
>>> and more. This is not negotiable: having a switch statement limited to
>>> small
>>> ints is simply not an option.
>>
>> Not a problem: http://pastebin.com/qdQintSZ
>
> The solution I posted tested the values one after another. I was
> interested in whether it was that much faster than if-elif in CPython 3,
> data=["Hello",None,[1,2,3],23.01,15+2j,Fraction(10,11),100**100,{},12345]
....
> ... so something is slowing down the Python in this test
The culprit here was Fraction. Whatever Fraction does, it's slow! And
when removed from the test expressions, it was still in the data list.
Replacing Fraction with a dummy class gave a more reasonable timing of
1.5 seconds (compared with 0.17s for the external language using
'general' switch, and 0.28s when it also uses an if-else chain).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-14 07:57 +1100 |
| Message-ID | <mailman.78.1457902659.12893.python-list@python.org> |
| In reply to | #104779 |
On Mon, Mar 14, 2016 at 6:39 AM, BartC <bc@freeuk.com> wrote:
> I used it in my benchmark to replace the if-else chain checking three lots
> of ranges:
>
> switch(c)
> if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
> ord("G"),ord("H"),ord("I"),ord("J"),ord("K"),ord("L"),
> ord("M"),ord("N"),ord("O"),ord("P"),ord("Q"),ord("R"),
> ord("S"),ord("T"),ord("U"),ord("V"),ord("W"),ord("X"),
> ord("Y"),ord("Z")):
> upper+=1
> elif case(ord("a"),ord("b"),ord("c"),ord("d"),ord("e"),ord("f"),
> ord("g"),ord("h"),ord("i"),ord("j"),ord("k"),ord("l"),
> ord("m"),ord("n"),ord("o"),ord("p"),ord("q"),ord("r"),
> ord("s"),ord("t"),ord("u"),ord("v"),ord("w"),ord("x"),
> ord("y"),ord("z")):
> lower+=1
> elif case(ord("0"),ord("1"),ord("2"),ord("3"),ord("4"),ord("5"),
> ord("6"),ord("7"),ord("8"),ord("9")):
> digits+=1
> else:
> other+=1
>
> It worked, but took 110 seconds; 80 seconds without the ord's and comparing
> strings (but I still think it's perverse that integer ops are slower than
> string ops).
>
> But 110 or 80 seconds, the original Python was 3.6 seconds. (Probably,
> someone could tweak it to work with ranges, but this is extra programmer
> effort that you say is too valuable to waste on such matters.)
This is not comparing ranges, though. This is comparing against
individual values. To talk about comparing ranges, I would expect the
code to look something like this:
switch(c)
if case("A", "Z"):
upper += 1
elif case("a", "z"):
lower += 1
elif case("0", "9"):
digits += 1
else:
other += 1
THIS is comparing ranges. The underlying comparisons must be
inequalities, not equalities. I absolutely *do not care* about
performance until the code looks good - at least reasonably good.
(By the way, your switch/case pair is non-reentrant. Plus it uses a
class in a weird way. Why not, if you're working like this, just have
two functions and a module-global? Just as non-reentrant, much cleaner
code.)
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-13 22:03 +0000 |
| Message-ID | <nc4nuk$inc$1@dont-email.me> |
| In reply to | #104784 |
On 13/03/2016 20:57, Chris Angelico wrote:
> On Mon, Mar 14, 2016 at 6:39 AM, BartC <bc@freeuk.com> wrote:
>> I used it in my benchmark to replace the if-else chain checking three lots
>> of ranges:
>>
>> switch(c)
>> if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
>> It worked, but took 110 seconds; 80 seconds without the ord's and comparing
>> strings (but I still think it's perverse that integer ops are slower than
>> string ops).
>>
>> But 110 or 80 seconds, the original Python was 3.6 seconds. (Probably,
>> someone could tweak it to work with ranges, but this is extra programmer
>> effort that you say is too valuable to waste on such matters.)
>
> This is not comparing ranges, though. This is comparing against
> individual values.
That's true. (It's not my code for 'switch' and 'case', and I assume
that the "==" operation it does on the arguments would not work when a
range is passed, whatever form that might be in.)
Nevertheless, a true switch statement would be expected to work just as
well with lots of individual case values, as with a smaller set of ranges.
To talk about comparing ranges, I would expect the
> code to look something like this:
>
> switch(c)
> if case("A", "Z"):
> upper += 1
> elif case("a", "z"):
> lower += 1
> elif case("0", "9"):
> digits += 1
> else:
> other += 1
>
> THIS is comparing ranges.
> The underlying comparisons must be
> inequalities, not equalities. I absolutely *do not care* about
> performance until the code looks good - at least reasonably good.
Yes, that would be faster. I made a much-simplified case() work like
your example, and the timing was 12 seconds.
(But that just worked with one single range, not an arbitrary mix of
single values and ranges as a proper switch. Allowing any number of
ranges per case, it took 25 seconds, and it's still not quite a full
switch.)
> (By the way, your switch/case pair is non-reentrant. Plus it uses a
> class in a weird way. Why not, if you're working like this, just have
> two functions and a module-global? Just as non-reentrant, much cleaner
> code.)
I chose this because it looked odd, and was likely to perform poorly!
My point being that it's difficult to put together something that looks
like, and is as easy to use as a switch in other languages, and is still
efficient. (The 12 seconds still took over 3 times as long as as a
simple if-elif chain, and the tests are still sequential so expect a
slow-down with lots groups to test.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2016-03-13 22:26 +0100 |
| Message-ID | <nc4lo3$9gh$1@dont-email.me> |
| In reply to | #104779 |
Am 13.03.16 um 20:39 schrieb BartC:
> switch(c)
> if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
> ord("G"),ord("H"),ord("I"),ord("J"),ord("K"),ord("L"),
> ord("M"),ord("N"),ord("O"),ord("P"),ord("Q"),ord("R"),
> ord("S"),ord("T"),ord("U"),ord("V"),ord("W"),ord("X"),
> ord("Y"),ord("Z")):
> upper+=1
> elif case(ord("a"),ord("b"),ord("c"),ord("d"),ord("e"),ord("f"),
> ord("g"),ord("h"),ord("i"),ord("j"),ord("k"),ord("l"),
> ord("m"),ord("n"),ord("o"),ord("p"),ord("q"),ord("r"),
> ord("s"),ord("t"),ord("u"),ord("v"),ord("w"),ord("x"),
> ord("y"),ord("z")):
> lower+=1
> elif case(ord("0"),ord("1"),ord("2"),ord("3"),ord("4"),ord("5"),
> ord("6"),ord("7"),ord("8"),ord("9")):
> digits+=1
> else:
> other+=1
>
> It worked, but took 110 seconds; 80 seconds without the ord's and
> comparing strings (but I still think it's perverse that integer ops are
> slower than string ops).
I assume you run this in a big loop. What about a single hash-table lookup?
from collections import Counter
counts=Counter()
for c in whatever:
counts[c]+=1
upper=sum(counts[x] for x in range(ord('A'), ord('Z')+1)
lower=sum(counts[x] for x in range(ord('a'), ord('z')+1)
....
I think this is equally readable as the switch version, and should be
much faster.
Christian
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-14 08:44 +1100 |
| Message-ID | <mailman.79.1457905464.12893.python-list@python.org> |
| In reply to | #104785 |
On Mon, Mar 14, 2016 at 8:26 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> I assume you run this in a big loop. What about a single hash-table lookup?
>
> from collections import Counter
> counts=Counter()
> for c in whatever:
> counts[c]+=1
>
> upper=sum(counts[x] for x in range(ord('A'), ord('Z')+1)
> lower=sum(counts[x] for x in range(ord('a'), ord('z')+1)
> ....
>
>
> I think this is equally readable as the switch version, and should be much
> faster.
At this point, it's completely moved away from being a switch block,
so while it may well be more readable AND faster, it's pretty much
irrelevant to the discussion. The value of a switch block is arbitrary
code, same as an if/elif tree, without having to package stuff up into
functions. Although I could accept a function-based solution if it
looks clean enough...
case = switch(c)
@case("A", "Z")
def _():
do_uppercase_stuff
@case("a", "z")
def _():
do_lowercase_stuff
@case("0", "9")
def _():
do_digit_stuff
@case
def _():
do_default_stuff
It creates an inner scope, which most people won't need or want, and
it's creating a bunch of functions every iteration, but the code's
reasonably clean. And it's fairly implementable:
def switch(template):
def case(testme, *range):
if done is not case: return done # Already hit another case.
match = False
if isinstance(testme, type(case)):
# No parens - this is the default case
match = True
elif range:
match = testme <= template <= range[0]
else:
match = template == testme
if match:
done = testme()
return done
done = case # Sentinel: Not done yet.
return case
Now you can play around with performance questions. But not until the
code (a) does the right thing, and (b) looks good enough to maintain.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-13 16:25 -0700 |
| Message-ID | <87wpp6c64o.fsf@jester.gateway.pace.com> |
| In reply to | #104779 |
BartC <bc@freeuk.com> writes:
> def case(*args):
> return any((arg == switch.value for arg in args))
def case(values):
return switch.value in values
> I used it in my benchmark to replace the if-else chain checking three
> lots of ranges:
>
> switch(c)
> if case(ord("A"),ord("B"),ord("C"),ord("D"),ord("E"),ord("F"),
> ord("G"),ord("H"),ord("I"),ord("J"),ord("K"),ord("L"),
> ord("M"),ord("N"),ord("O"),ord("P"),ord("Q"),ord("R"),
> ord("S"),ord("T"),ord("U"),ord("V"),ord("W"),ord("X"),
> ord("Y"),ord("Z")):
> upper+=1
Use a set instead of a big tuple:
uppers = { ord("A"), ord("B"), ... ord("Z") }
...
if case(uppers):
upper += 1
[toc] | [prev] | [next] | [standalone]
Page 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web