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 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-22 00:42 +0000 |
| Message-ID | <mailman.476.1458607393.12893.python-list@python.org> |
| In reply to | #105420 |
On 22/03/2016 00:18, BartC wrote: > On 21/03/2016 23:50, Terry Reedy wrote: >> On 3/21/2016 8:43 AM, BartC wrote: >> >>> This tests highlights the benefits of an O(1) switch statement. >> >> So why are you not taking advantage of Python's O(1) dict lookup? >> > I've already reported using a list lookup which is also O(1), and it > didn't really help. I doubt a dict lookup is going to be faster (but > Python has surprised me before). Please explain how you managed to make the list lookup O(1). > > One problem is how to attach the handling code to the entry in the list > or as the value in the dict. With the list, I stored a function reference. It has repeatedly been stated that a dict is used as a switch replacement, so there is no problem attaching a handler to a dict. > > I suspect that a switch implemented Python-style wouldn't be > dramatically faster either. But the handling code can be expressed in-line. > There are umpteen recipes of all shapes and sizes that implement switch/case statements, even pattern matching, online. Why don't you time some of them, as relying on gut instinct is almost always wrong in Python. -- 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-22 01:00 +0000 |
| Message-ID | <ncq59a$91f$1@dont-email.me> |
| In reply to | #105426 |
On 22/03/2016 00:42, Mark Lawrence wrote: > On 22/03/2016 00:18, BartC wrote: >> On 21/03/2016 23:50, Terry Reedy wrote: >>> On 3/21/2016 8:43 AM, BartC wrote: >>> >>>> This tests highlights the benefits of an O(1) switch statement. >>> >>> So why are you not taking advantage of Python's O(1) dict lookup? >>> >> I've already reported using a list lookup which is also O(1), and it >> didn't really help. I doubt a dict lookup is going to be faster (but >> Python has surprised me before). > > Please explain how you managed to make the list lookup O(1). It's not a 'lookup' in the sense of searching. It's just normal indexing. The 'key' will be an ASCII code 0 to 127. -- Bartv
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-03-24 13:49 -0600 |
| Message-ID | <mailman.105.1458848996.2244.python-list@python.org> |
| In reply to | #105353 |
On 03/21/2016 06:43 AM, BartC wrote: > On 21/03/2016 12:08, Ned Batchelder wrote: >> On Sunday, March 20, 2016 at 9:15:32 PM UTC-4, BartC wrote: >>> >>> A tokeniser along those lines in Python, with most of the bits filled >>> in, is here: >>> >>> http://pastebin.com/dtM8WnFZ >>> >> >> Bart, we get it: you don't like the trade-offs that Python has made. > ... >> You don't like Python. Can we leave it at that? > > On the contrary, I do like it. It's just a shame it's made those > trade-offs as a bit more speed would have made it more useful to me. Have you looked at compiled, python-inspired languages like Num (http://nim-lang.org/). If it's syntax you like and some other Python things like for the for loop works, maybe something like this would be useful to you.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-13 13:01 +1100 |
| Message-ID | <56e4ca11$0$1609$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104733 |
On Sun, 13 Mar 2016 10:57 am, BartC wrote:
> 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.)
Copying from your code, you define a bunch of constants in a table (many of
which apparently have the same value?):
global tabledata() cmdnames, cmdfmt =
(kzero=0, $, (0,0,0,0)),
(knop, $, (0,0,0,0)),
(klabel, $, (l,0,0,0)),
(kcodestart, $, (p,h,0,0)),
(kcodeend, $, (0,0,0,0)),
(kendmodule, $, (0,0,0,0)),
(kendprogram, $, (0,0,0,0)),
...
end
I don't understand the syntax. You seem to have three columns in the table,
a name, a $ whatever that is for, and some data (four values in a
comma-separated parenthesised list), but the table appears to only define
two columns (cmdnames, cmdfmt). Mysterious.
In Python, we might similarly define a table, using a dict:
tabledata = dict(
kzero=(0,0,0,0),
knop=(0,0,0,0)),
klabel=(l,0,0,0)),
kcodestart=(p,h,0,0)),
kcodeend=(0,0,0,0)),
kendmodule=(0,0,0,0)),
kendprogram=(0,0,0,0)),
...
)
So the amount of typing is comparable. If you have 200 symbolic names with
associated data, one way or the other you have to enter 200 symbolic names
and their associated data into your source code, regardless of whether they
are called "constants", "enums", "variables" or "symbols".
The dict solution does have the rather sad consequence that we then have to
use quoted names for the symbols:
x = tabledata['klabel']
although one can make a simple wrapper around the dict to fix this:
class table:
pass
table.__dict__ = tabledata
x = table.klabel
And if you want to make these "constants" available as top-level names as
well as via the table:
globals.update(tabledata)
What about the risk that somebody might modify them? The Pythonic answer
is "well don't do that". The names are clearly marked with a leading "k"
for "konstant", so unless documented otherwise they're not variables. We
don't need the compiler to enforce that rule.
Some of us might like a more traditional rule.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-13 02:30 +0000 |
| Message-ID | <nc2j6t$2vk$1@dont-email.me> |
| In reply to | #104737 |
On 13/03/2016 02:01, Steven D'Aprano wrote:
> On Sun, 13 Mar 2016 10:57 am, BartC wrote:
>
>> 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.)
>
> Copying from your code, you define a bunch of constants in a table (many of
> which apparently have the same value?):
>
> global tabledata() cmdnames, cmdfmt =
> (kzero=0, $, (0,0,0,0)),
> (knop, $, (0,0,0,0)),
> (klabel, $, (l,0,0,0)),
> (kcodestart, $, (p,h,0,0)),
> (kcodeend, $, (0,0,0,0)),
> (kendmodule, $, (0,0,0,0)),
> (kendprogram, $, (0,0,0,0)),
> ...
> end
>
> I don't understand the syntax. You seem to have three columns in the table,
> a name, a $ whatever that is for, and some data (four values in a
> comma-separated parenthesised list), but the table appears to only define
> two columns (cmdnames, cmdfmt). Mysterious.
(Obviously my comments didn't work.. The table above is roughly
equivalent to the following Python:
kzero = 0 # define a bunch of enums (with auto-increment)
knop = 1
klabel = 2
kcodestart = 3
kcodeend = 4
kendmodule = 5
kendprogram = 6
...
#define a list of matching names (the $ is a cheap gimmick to avoid
#duplicating each name. The language ought to take care of accessing
#the names, but it doesn't):
cmdnames = ("kzero",
"knop",
"klabel",
"kcodestart",
"kcodeend",
"kendmodule",
"kendprogram",...)
#define matching format codes (the single letter codes are constants
#defined previously):
cmfmt = ( (0,0,0,0),
(0,0,0,0),
etc.
Clearly it is possible to write the above, but it's harder to maintain
and read (inserting or deleting enum names, keeping the parallel lists
aligned, and trying to read off which fmt corresponds to which enum).)
> In Python, we might similarly define a table, using a dict:
>
> tabledata = dict(
> kzero=(0,0,0,0),
> knop=(0,0,0,0)),
> klabel=(l,0,0,0)),
> kcodestart=(p,h,0,0)),
> kcodeend=(0,0,0,0)),
> kendmodule=(0,0,0,0)),
> kendprogram=(0,0,0,0)),
> ...
> )
> So the amount of typing is comparable. If you have 200 symbolic names with
> associated data, one way or the other you have to enter 200 symbolic names
> and their associated data into your source code, regardless of whether they
> are called "constants", "enums", "variables" or "symbols".
There are all sorts of ways to do it in any language. But I found my
method invaluable. And you do end up with actual compile-time constants
for the codes on the left.
A simpler example:
enum (red,green,blue)
which is equivalent to:
const red=1
const green=2
const blue=3
I've seen half a dozen ways of doing enums in Python, but some look
really complicated for something so simple. And you still end up with a
LOAD_GLOBAL for that 'red' value!
Worse if red, green, blue are defined in a class as then you need a
lookup too. My example above defined 'open' enums, but they can be
assigned to their own type:
type lights = (red, amber, green)
Now it's necessary to say lights.green, but this is just the constant 3!
See, get rid of some of the dynamics, and lots of things become very
easy. (But I don't think that's going to happen.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-24 22:43 +0000 |
| Message-ID | <mailman.114.1458859507.2244.python-list@python.org> |
| In reply to | #104666 |
On 12/03/2016 01:16, BartC wrote: Please go and play with this. https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en -- 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 | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 08:48 +0200 |
| Message-ID | <87h9gcxkd3.fsf@elektro.pacujo.net> |
| In reply to | #104645 |
Chris Angelico <rosuav@gmail.com>:
> Definitely agree with this. Having a way to declare that a name is
> "truly constant" would be extremely handy;
I don't think it would be all that handy. I'm afraid all this type
hinting will turn Python into a poor man's Java.
> Maybe, but I honestly don't miss 'switch' all that often - and when I
> do, it's usually because I want a range.
I don't consider the switch statement an optimization technique but
rather, a readability technique.
Note that Scheme has a "switch statement" (a "case form") despite being
a highly dynamic language. Incidentally, Scheme allows for more
performance optimization than Python as well because
* Scheme has atoms ("symbols") and literals for them.
* Scheme has macros ("syntax") that are expanded at compile time.
Compile-time macros are actually a conceptual compromise that violate
full-fledged dynamism: once the compiler has expanded the macro, its
definition can't change.
> Py3 hasn't eliminated int; and yes, all "simple value types" in Python
> are still boxed values.
Conceptually, yes, but that doesn't have to be the implementation. The
redundant bits in memory addresses allow for unboxing of almost all
practical integers, for example.
BTW, even CPython puts limits to complete dynamism:
>>> (4).__str__ = "four"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'int' object attribute '__str__' is read-only
> 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.
Yes, a complete non-issue.
Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 11:08 +0000 |
| Message-ID | <nc0t5o$441$1@dont-email.me> |
| In reply to | #104678 |
On 12/03/2016 06:48, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Definitely agree with this. Having a way to declare that a name is
>> "truly constant" would be extremely handy;
>
> I don't think it would be all that handy. I'm afraid all this type
> hinting will turn Python into a poor man's Java.
It's not type hinting. Otherwise you can say that using 'def' or 'class'
is a form of type hinting. Think of 'const' as operating like the latter
and declaring something a little different.
Although the volatility of the names so defined is still the problem.
>> Maybe, but I honestly don't miss 'switch' all that often - and when I
>> do, it's usually because I want a range.
>
> I don't consider the switch statement an optimization technique but
> rather, a readability technique.
>
> Note that Scheme has a "switch statement" (a "case form") despite being
> a highly dynamic language.
Yes, you can have simpler forms of switch, that have the same overall
structure, but do a series of sequential tests rather than using any
form of table indexed by the value being tested.
The advantage here is that that test-value need only be evaluated once.
It stays on the stack until some match is found, or the statement comes
to an end.
It won't have as dramatic an impact on performance, but enhances
readability as you say.
> Compile-time macros are actually a conceptual compromise that violate
> full-fledged dynamism: once the compiler has expanded the macro, its
> definition can't change.
What's big deal with dynamism anyway? I could never understand Python's
obsession with it.
For me, 'dynamic' means that a variable has a dynamic type; that's all.
But you know at compile-time (or when looking at source code) whether a
name is a variable, or a function, class, module, named constant and so on.
If you need a variable-function, then you just have a variable contain
the name of a function (ie a reference to it). You can bolt on dynamism
/when you need it/.
OK, mini-rant over...
>> 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.
> Yes, a complete non-issue.
Really? The issue as I see it is this:
Writing: a=65 generates this byte-code for the right-hand-side:
LOAD_CONST 1 (65) An integer
But writing instead: a=ord('A') generates this:
LOAD_GLOBAL 0 (ord)
LOAD_CONST 1 ('A') A string
CALL_FUNCTION 1
You might be right: doing an unnecessary global name lookup and
executing a function call are unlikely to have any impact on performance...
The problem here is that 'ord' is dynamic, so this operation cannot
simply be done at compile-time. Even when you try and optimise by
assuming that ord is immutable, you don't really want to be doing any
runtime checks. It might be faster than calling LOAD_GLOBAL and
CALL_FUNCTION, but not quite as fast as just doing LOAD_CONST.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2016-03-12 11:27 +0000 |
| Message-ID | <mailman.34.1457782092.12893.python-list@python.org> |
| In reply to | #104690 |
On 12/03/2016 11:08, BartC wrote:
> On 12/03/2016 06:48, Marko Rauhamaa wrote:
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> Definitely agree with this. Having a way to declare that a name is
>>> "truly constant" would be extremely handy;
>>
>> I don't think it would be all that handy. I'm afraid all this type
>> hinting will turn Python into a poor man's Java.
>
> It's not type hinting. Otherwise you can say that using 'def' or 'class'
> is a form of type hinting. Think of 'const' as operating like the latter
> and declaring something a little different.
>
> Although the volatility of the names so defined is still the problem.
>
>>> Maybe, but I honestly don't miss 'switch' all that often - and when I
>>> do, it's usually because I want a range.
>>
>> I don't consider the switch statement an optimization technique but
>> rather, a readability technique.
>>
>> Note that Scheme has a "switch statement" (a "case form") despite being
>> a highly dynamic language.
>
> Yes, you can have simpler forms of switch, that have the same overall
> structure, but do a series of sequential tests rather than using any
> form of table indexed by the value being tested.
>
> The advantage here is that that test-value need only be evaluated once.
> It stays on the stack until some match is found, or the statement comes
> to an end.
>
> It won't have as dramatic an impact on performance, but enhances
> readability as you say.
>
>> Compile-time macros are actually a conceptual compromise that violate
>> full-fledged dynamism: once the compiler has expanded the macro, its
>> definition can't change.
>
> What's big deal with dynamism anyway? I could never understand Python's
> obsession with it.
>
> For me, 'dynamic' means that a variable has a dynamic type; that's all.
> But you know at compile-time (or when looking at source code) whether a
> name is a variable, or a function, class, module, named constant and so on.
>
> If you need a variable-function, then you just have a variable contain
> the name of a function (ie a reference to it). You can bolt on dynamism
> /when you need it/.
>
> OK, mini-rant over...
>
> >> 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.
>
>> Yes, a complete non-issue.
>
> Really? The issue as I see it is this:
>
> Writing: a=65 generates this byte-code for the right-hand-side:
>
> LOAD_CONST 1 (65) An integer
>
> But writing instead: a=ord('A') generates this:
>
> LOAD_GLOBAL 0 (ord)
> LOAD_CONST 1 ('A') A string
> CALL_FUNCTION 1
>
> You might be right: doing an unnecessary global name lookup and
> executing a function call are unlikely to have any impact on performance...
>
Function calls are hugely expensive in Python.
--
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 | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 13:51 +0200 |
| Message-ID | <87shzvgbhq.fsf@elektro.pacujo.net> |
| In reply to | #104690 |
BartC <bc@freeuk.com>:
> What's big deal with dynamism anyway? I could never understand
> Python's obsession with it.
>
> For me, 'dynamic' means that a variable has a dynamic type; that's
> all. But you know at compile-time (or when looking at source code)
> whether a name is a variable, or a function, class, module, named
> constant and so on.
*I* am obsessed with dynamism. It means I don't have to declare object
data members but can write ad hoc:
def some_method(self):
self.update_state()
self.state_specific_info = "Kilroy was here"
The "state_specific_info" attribute didn't exist before I wished it into
existence. No bureaucracy, just add it where it belongs.
I also have a high level of method/attribute transparency. It doesn't
matter if I declare:
def this_or_that(self):
if self.that:
self.that()
else:
self.this()
[...]
self.that = True
or:
self.this_or_that = self.that
Somewhat related, every method is an automatic delegate. Defining
callbacks is a breeze:
def clickety_click(self, x, y):
[...]
[...]
window.register_mouse_click_callback(self.clickety_click)
> On 12/03/2016 06:48, Marko Rauhamaa wrote:
>> Chris Angelico <rosuav@gmail.com>:
>>> 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.
>
>> Yes, a complete non-issue.
>
> Really? The issue as I see it is this:
>
> Writing: a=65 generates this byte-code for the right-hand-side:
>
> LOAD_CONST 1 (65) An integer
>
> But writing instead: a=ord('A') generates this:
>
> LOAD_GLOBAL 0 (ord)
> LOAD_CONST 1 ('A') A string
> CALL_FUNCTION 1
>
> You might be right: doing an unnecessary global name lookup and
> executing a function call are unlikely to have any impact on
> performance...
Simply put: I don't use "ord()" almost at all. I couldn't find any
example in any of my code.
> The problem here is that 'ord' is dynamic, so this operation cannot
> simply be done at compile-time. Even when you try and optimise by
> assuming that ord is immutable, you don't really want to be doing any
> runtime checks. It might be faster than calling LOAD_GLOBAL and
> CALL_FUNCTION, but not quite as fast as just doing LOAD_CONST.
That optimization wouldn't have any effect on any of my code.
More generally, every method call in Python is such an elaborate
exercise that dabbling with character constants is going to be a drop in
the ocean.
Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 13:42 +0000 |
| Message-ID | <nc1660$3e2$1@dont-email.me> |
| In reply to | #104693 |
On 12/03/2016 11:51, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> What's big deal with dynamism anyway? I could never understand >> Python's obsession with it. >> >> For me, 'dynamic' means that a variable has a dynamic type; that's >> all. But you know at compile-time (or when looking at source code) >> whether a name is a variable, or a function, class, module, named >> constant and so on. > > *I* am obsessed with dynamism. It means I don't have to declare object > data members but can write ad hoc: > > def some_method(self): > self.update_state() > self.state_specific_info = "Kilroy was here" > > The "state_specific_info" attribute didn't exist before I wished it into > existence. No bureaucracy, just add it where it belongs. I was talking about 'top-level' names more than attributes (names that follow a dot). Ad-hoc attributes I don't have as much of a problem with, as they can be handy. But predefined ones also have their points. (For one thing, I know how to implement those efficiently.) However, when you have a function call like this: M.F(), where M is an imported module, then it is very unlikely that the functions in M are going to be created, modified, deleted or replaced while the program runs. [I mean, after the usual process of executing each 'def' statement.] Why then should it have to suffer the same overheads as looking up arbitrary attributes? And on every single call? > I also have a high level of method/attribute transparency. It doesn't > matter if I declare: > > def this_or_that(self): > if self.that: > self.that() > else: > self.this() > > [...] > > self.that = True > > or: > > self.this_or_that = self.that This example, I don't understand. Do you mean that when your write X.Y, that Y can be an attribute of X one minute, and a method the next? (In which case I wouldn't want to have to maintain your code!) > Somewhat related, every method is an automatic delegate. Defining > callbacks is a breeze: > > def clickety_click(self, x, y): > [...] > > [...] > window.register_mouse_click_callback(self.clickety_click) I don't follow this either. What's the advantage of dynamism here? > That optimization wouldn't have any effect on any of my code. > > More generally, every method call in Python is such an elaborate > exercise that dabbling with character constants is going to be a drop in > the ocean. When you dabble with lots of little things, then they can add up. To the point where an insignificant optimisation can become significant. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 16:38 +0200 |
| Message-ID | <871t7fg3rl.fsf@elektro.pacujo.net> |
| In reply to | #104704 |
BartC <bc@freeuk.com>:
> Ad-hoc attributes I don't have as much of a problem with, as they can
> be handy. But predefined ones also have their points. (For one thing,
> I know how to implement those efficiently.)
I wonder how large a proportion of all references are top-level. My
hunch is that it is well below 10% in a normal Python program.
> However, when you have a function call like this: M.F(), where M is an
> imported module, then it is very unlikely that the functions in M are
> going to be created, modified, deleted or replaced while the program
> runs. [I mean, after the usual process of executing each 'def'
> statement.]
There M is top-level, M.F is a level below. Even adjusting for the
meaning of "top-level," most accesses in a typical Python program are
attribute references due to object orientation.
> Why then should it have to suffer the same overheads as looking up
> arbitrary attributes? And on every single call?
It doesn't much matter because the "top level" probably plays an
insignificant role in the performance.
>> I also have a high level of method/attribute transparency. It doesn't
>> matter if I declare:
>>
>> def this_or_that(self):
>> if self.that:
>> self.that()
>> else:
>> self.this()
>>
>> [...]
>>
>> self.that = True
>>
>> or:
>>
>> self.this_or_that = self.that
>
> This example, I don't understand. Do you mean that when your write X.Y,
> that Y can be an attribute of X one minute, and a method the next? (In
> which case I wouldn't want to have to maintain your code!)
What I wanted to say above is that I have a choice of implementing a
dynamic method using attribute assignment or a method definition. For
all practical purposes, an object method is an attribute. You can write
it using the handy "def" syntax or you can use an assignment.
Python has defined it in a slightly more convoluted manner, but you
would almost never sense the difference. Here's a whiff of the
convolution:
>>> four = 4
>>> four.__str__ is four.__str__
What happens here is that Python first sees if the builtin object 4 has
an attribute named "__str__". It doesn't. Python then proceeds to 4's
class, int, and finds int.__str__, which is the underlying method in the
class. Python then constructs a delegate function like this:
lambda *x, **y: int.__str__(4, *x, **y)
and returns it.
>> Somewhat related, every method is an automatic delegate. Defining
>> callbacks is a breeze:
>>
>> def clickety_click(self, x, y):
>> [...]
>>
>> [...]
>> window.register_mouse_click_callback(self.clickety_click)
>
> I don't follow this either. What's the advantage of dynamism here?
Dynamism doesn't play a direct role here, but the convolution I describe
above makes the magic possible.
(There would be a less convoluted way to come up with almost identical
semantics, but that would cost memory and object instantiation time.)
Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-13 03:56 +1100 |
| Message-ID | <56e44a4e$0$1614$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104704 |
On Sun, 13 Mar 2016 12:42 am, BartC wrote:
> Ad-hoc attributes I don't have as much of a problem with, as they can be
> handy. But predefined ones also have their points. (For one thing, I
> know how to implement those efficiently.)
>
> However, when you have a function call like this: M.F(), where M is an
> imported module, then it is very unlikely that the functions in M are
> going to be created, modified, deleted or replaced while the program
> runs. [I mean, after the usual process of executing each 'def' statement.]
What do you consider "very unlikely"? And how do you know what people will
choose to do?
> Why then should it have to suffer the same overheads as looking up
> arbitrary attributes? And on every single call?
Because they *are* arbitrary attributes of the module. There's only one sort
of attribute in Python. Python doesn't invent multiple lookup rules for
attributes-that-are-functions, attributes-that-are-classes,
attributes-that-are-ints, attributes-that-are-strings, and so on. They are
all the same.
You gain a simpler implementation, a simpler execution model, simpler rules
for users to learn, and the ability to perform some pretty useful dynamic
tricks on those occasions where it is useful. For example, monkey-patching
a module for testing or debugging purposes.
In languages where functions are different from other values, you have to
recognise ahead of time "some day, I may need to dynamically replace this
function with another" and write your code specially to take that into
account, probably using some sort of "Design Pattern". In Python, you just
write your code in the normal fashion.
>> I also have a high level of method/attribute transparency. It doesn't
>> matter if I declare:
>>
>> def this_or_that(self):
>> if self.that:
>> self.that()
>> else:
>> self.this()
>>
>> [...]
>>
>> self.that = True
>>
>> or:
>>
>> self.this_or_that = self.that
>
> This example, I don't understand. Do you mean that when your write X.Y,
> that Y can be an attribute of X one minute, and a method the next? (In
> which case I wouldn't want to have to maintain your code!)
Again, methods *are* attributes. Notice that Python doesn't have two
complete sets of functions:
getattr, setattr, delattr
getmethod, setmethod, delmethod
Again, as above, there is *one* look-up rule, that applies equally to
attributes-that-are-methods and attributes-that-are-floats (say). What
distinguishes the two cases is whether or not the attribute is a method
object or a float object, not how you access it or define it.
In practice, people rarely do something like:
x.y = method
# later
x.y = 999
# later still
x.y = method # again
because that would be a strange thing to do, not because it would be
impossible. They don't do it because there's no reason to do so, not
because they can't: the same reason we don't walk around with pots of honey
carefully nestled in our hair.
>> Somewhat related, every method is an automatic delegate. Defining
>> callbacks is a breeze:
>>
>> def clickety_click(self, x, y):
>> [...]
>>
>> [...]
>> window.register_mouse_click_callback(self.clickety_click)
>
> I don't follow this either. What's the advantage of dynamism here?
I think that Marko's point is that because obj.clickety_click is just a
regular attribute that returns a method object, you don't have to invent
special syntax for referring to method *without* calling them. You just use
the same attribute access syntax, but don't call the result.
>> That optimization wouldn't have any effect on any of my code.
>>
>> More generally, every method call in Python is such an elaborate
>> exercise that dabbling with character constants is going to be a drop in
>> the ocean.
>
> When you dabble with lots of little things, then they can add up. To the
> point where an insignificant optimisation can become significant.
Of course. Reduced runtime efficiency is the cost you pay for the
flexibility gained by significant dynamism. It's a trade-off between
efficiency, convenience, simplicity, etc. It's quite legitimate for
language designers to choose to put that trade-off in different places, or
indeed for the trade-off to change over time.
For example, Java's strictness was found to be too limiting and static, and
so reflection was added to the language to add some dynamism. Here's the
description from a Stackoverflow answer:
http://stackoverflow.com/questions/37628/what-is-reflection-and-why-is-it-useful
For example, say you have an object of an unknown type in Java,
and you would like to call a 'doSomething' method on it if one
exists. Java's static typing system isn't really designed to
support this unless the object conforms to a known interface,
but using reflection, your code can look at the object and find
out if it has a method called 'doSomething' and then call it if
you want to.
In Java, you have to write something like:
Method method = foo.getClass().getMethod("doSomething", null);
method.invoke(foo, null);
In Python, you never talk about reflection, because you don't need any
special syntax to make it work. You just write:
foo.doSomething()
exactly the same as the "ordinary" case of calling foo.doSomething(). From
the perspective of a Python programmer, the idea that Java programmers need
to talk about "reflection" to get it to work is quite weird.
(Python does have something like getMethod, namely getattr, but you wouldn't
use that with a string literal. You would only use it when the name of the
method wasn't known until runtime.)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 17:54 +0000 |
| Message-ID | <nc1l01$rq8$1@dont-email.me> |
| In reply to | #104716 |
On 12/03/2016 16:56, Steven D'Aprano wrote: > On Sun, 13 Mar 2016 12:42 am, BartC wrote: > >> Ad-hoc attributes I don't have as much of a problem with, as they can be >> handy. But predefined ones also have their points. (For one thing, I >> know how to implement those efficiently.) >> >> However, when you have a function call like this: M.F(), where M is an >> imported module, then it is very unlikely that the functions in M are >> going to be created, modified, deleted or replaced while the program >> runs. [I mean, after the usual process of executing each 'def' statement.] > > What do you consider "very unlikely"? And how do you know what people will > choose to do? Common sense tells you it is unlikely. > >> Why then should it have to suffer the same overheads as looking up >> arbitrary attributes? And on every single call? > > Because they *are* arbitrary attributes of the module. There's only one sort > of attribute in Python. Python doesn't invent multiple lookup rules for > attributes-that-are-functions, attributes-that-are-classes, > attributes-that-are-ints, attributes-that-are-strings, and so on. They are > all the same. > > You gain a simpler implementation, (Have you tried looking at the CPython sources? I tried last year and couldn't head or tail of them. What was the layout of the pyObject struct? I couldn't figure it out, the source being such a mess of conditional code and macros within macros. So I wouldn't like to see a complex implementation!) a simpler execution model, simpler rules > for users to learn, and the ability to perform some pretty useful dynamic > tricks on those occasions where it is useful. For example, monkey-patching > a module for testing or debugging purposes. > In languages where functions are different from other values, you have to > recognise ahead of time "some day, I may need to dynamically replace this > function with another" and write your code specially to take that into > account, probably using some sort of "Design Pattern". No it's very easy. In Python terms: def f(): return "One" def g(): return "Two" h=f h() returns "One". Later you do h=g, and h() returns "Two". No need for f and g themselves to be dynamic. h just needs to be a variable. The same with modules: import A import B M=A Now M.F() calls A.F(). Do M=B, and M.B now calls B.F(). No need for module names to be dynamic either! Just variables. >> When you dabble with lots of little things, then they can add up. To the >> point where an insignificant optimisation can become significant. > > Of course. Reduced runtime efficiency is the cost you pay for the > flexibility gained by significant dynamism. It's a trade-off between > efficiency, convenience, simplicity, etc. It's quite legitimate for > language designers to choose to put that trade-off in different places, or > indeed for the trade-off to change over time. Maybe the designer(s) of Python didn't know how popular it would get. Do you think some of the design decisions would be different now? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-12 20:07 +0200 |
| Message-ID | <87vb4refik.fsf@elektro.pacujo.net> |
| In reply to | #104719 |
BartC <bc@freeuk.com>: > No it's very easy. In Python terms: > > def f(): return "One" > def g(): return "Two" > > h=f > > h() returns "One". Later you do h=g, and h() returns "Two". No need > for f and g themselves to be dynamic. h just needs to be a variable. Well, what do you make of this: >>> def f(): return 1 ... >>> g = f >>> def f(): return 2 ... >>> g() 1 >>> f() 2 Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-12 18:30 +0000 |
| Message-ID | <nc1n2o$5nt$1@dont-email.me> |
| In reply to | #104720 |
On 12/03/2016 18:07, Marko Rauhamaa wrote: > BartC <bc@freeuk.com>: > >> No it's very easy. In Python terms: >> >> def f(): return "One" >> def g(): return "Two" >> >> h=f >> >> h() returns "One". Later you do h=g, and h() returns "Two". No need >> for f and g themselves to be dynamic. h just needs to be a variable. > > Well, what do you make of this: > > >>> def f(): return 1 > ... > >>> g = f > >>> def f(): return 2 > ... > >>> g() > 1 > >>> f() > 2 def f001(): return 1 f = f001 g = f def f002(): return 2 f=f002; print(g()) print(f()) Same results, but now we've agains removed the need for the function names (f001 and f002) to be mutable. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-13 20:39 +1100 |
| Message-ID | <56e5354c$0$1593$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104719 |
On Sun, 13 Mar 2016 04:54 am, BartC wrote:
> On 12/03/2016 16:56, Steven D'Aprano wrote:
>> On Sun, 13 Mar 2016 12:42 am, BartC wrote:
>>
>>> Ad-hoc attributes I don't have as much of a problem with, as they can be
>>> handy. But predefined ones also have their points. (For one thing, I
>>> know how to implement those efficiently.)
>>>
>>> However, when you have a function call like this: M.F(), where M is an
>>> imported module, then it is very unlikely that the functions in M are
>>> going to be created, modified, deleted or replaced while the program
>>> runs. [I mean, after the usual process of executing each 'def'
>>> statement.]
>>
>> What do you consider "very unlikely"? And how do you know what people
>> will choose to do?
>
> Common sense tells you it is unlikely.
Perhaps your common sense is different from other people's common sense. To
me, and many other Python programmers, it's common sense that being able to
replace functions or methods on the fly is a useful feature worth having.
More on this below.
Perhaps this is an example of the "Blub Paradox":
http://www.paulgraham.com/avg.html
Wherever we sit in the continuum of language power, we look *down* at
languages with less power as "crippled" because they miss features we use
all the time, and *up* at languages with more power as adding a lot of
hairy and weird features that nobody would ever need.
>>> Why then should it have to suffer the same overheads as looking up
>>> arbitrary attributes? And on every single call?
>>
>> Because they *are* arbitrary attributes of the module. There's only one
>> sort of attribute in Python. Python doesn't invent multiple lookup rules
>> for attributes-that-are-functions, attributes-that-are-classes,
>> attributes-that-are-ints, attributes-that-are-strings, and so on. They
>> are all the same.
>>
>> You gain a simpler implementation,
>
> (Have you tried looking at the CPython sources? I tried last year and
> couldn't head or tail of them. What was the layout of the pyObject
> struct? I couldn't figure it out, the source being such a mess of
> conditional code and macros within macros.
Right. Now add *on top of that complexity* the extra complexity needed to
manage not one, but *two* namespaces for every scope: one for "variables"
and one for "functions and methods".
I'm not defending the CPython source. I can't even judge the CPython source.
My ability to read C code is a bit better than "See Spot run. Run, Spot,
Run!" but not that much better. But CPython is a 20+ year language, and the
implementation has no doubt built up some cruft over the years, especially
since many of the implementation details are part of the public C
interface.
[...]
>> In languages where functions are different from other values, you have to
>> recognise ahead of time "some day, I may need to dynamically replace this
>> function with another" and write your code specially to take that into
>> account, probably using some sort of "Design Pattern".
>
> No it's very easy. In Python terms:
>
> def f(): return "One"
> def g(): return "Two"
>
> h=f
>
> h() returns "One". Later you do h=g, and h() returns "Two". No need for
> f and g themselves to be dynamic. h just needs to be a variable.
You're still not getting the big picture. I didn't say that it was
necessarily difficult create such a "dynamic function". I said that you had
to realise *ahead of time* that you needed to do so.
Let me see if I can draw you a more complete picture. Suppose I have a
function that relies on (let's say) something random or unpredictable:
def get_data():
return time.strftime("%S:%H")
Obviously this is a toy function, consider it as a stand-in for something
more substantial. I don't know, maybe it connects to a database, or gathers
data from a distant web site, or interacts with the user.
Now I use `get_data` in another function:
def spam():
value = get_stuff().replace(":", "")
num = int(value)
return "Spam to the %d" % num
How do I test the `spam` function? I cannot easily predict what the
`get_data` function will return.
In Python, I can easily monkey-patch this for the purposes of testing, or
debugging, by introducing a test double (think of "stunt double") to
replace the real `get_data` function:
import mymodule
mymodule.get_data = lambda: "1:1"
assert spam() == "Spam to the 11"
This "test double" is sometimes called a stub, or a mock, or a fake.
Whatever you call it, it is *trivially* easy in Python.
How would you do it, when functions are constant? You would have to re-write
the module to allow it:
def real_get_data():
return time.strftime("%S:%H")
replaceable_get_data = real_get_data
def spam():
value = replaceable_get_data().replace(":", "")
num = int(value)
return "spam"*num
Now you have two classes of functions: those that can be replaced by test
doubles and those that can't. Those that can be replaced exist in two
almost identical versions: the real, crippled, function, and the special,
mockable, function. Your users have to learn which to use, and why.
If you want to patch or mock something which the module author didn't think
of in advance, you are all out of luck.
Now multiple by your entire library, potentially hundreds or thousands of
functions.
I once monkey-patched the `len` built-in so I could monitor the progress of
a long-running piece of code that wasn't written to give any feedback. I
wouldn't do that in production, of course, but I was debugging and that was
a nice, simple, clean way to get the result I needed: each time through the
loop, my function called `len` and the patched version printed status so I
could see where it was up to. Why I was done, I deleted the monkey-patch,
and never once needed to edit the main function being called inside the
loop.
>>> When you dabble with lots of little things, then they can add up. To the
>>> point where an insignificant optimisation can become significant.
>>
>> Of course. Reduced runtime efficiency is the cost you pay for the
>> flexibility gained by significant dynamism. It's a trade-off between
>> efficiency, convenience, simplicity, etc. It's quite legitimate for
>> language designers to choose to put that trade-off in different places,
>> or indeed for the trade-off to change over time.
>
> Maybe the designer(s) of Python didn't know how popular it would get.
>
> Do you think some of the design decisions would be different now?
I think that there are certainly people in the Python community that would
have done things differently if they had been around back in the beginning.
But I don't think Guido is one of them. He's not adverse to people speeding
Python up, but I don't think he would be willing to give the advantages for
testing and debugging when he could just wait another year for CPU speeds
to increase.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-13 13:16 +0000 |
| Message-ID | <nc3p27$lor$1@dont-email.me> |
| In reply to | #104751 |
On 13/03/2016 09:39, Steven D'Aprano wrote:
> On Sun, 13 Mar 2016 04:54 am, BartC wrote:
>> Common sense tells you it is unlikely.
>
> Perhaps your common sense is different from other people's common sense. To
> me, and many other Python programmers, it's common sense that being able to
> replace functions or methods on the fly is a useful feature worth having.
Worth having but at significant cost. But look at my jpeg test (look at
any other similar programs); how many function names are used
dynamically? How many functions *really* need to be dynamic?
>> (Have you tried looking at the CPython sources?
> Right. Now add *on top of that complexity* the extra complexity needed to
> manage not one, but *two* namespaces for every scope: one for "variables"
> and one for "functions and methods".
No, there's one namespace per scope. (Otherwise you could have a
function 'f' and a variable 'f' in each scope.)
Perhaps what you mean is the number of different kinds of identifiers
there can be. At the minute, apart from obvious, fixed, reserved words
(I assume there are some!), there seems to be just one kind. The
different categories (function, variable, class, built-in, module etc)
are sorted out at *run-time*.
Some of this will just move to *compile-time*. Same amount of
complexity, but now you do it just once at compile-time, instead of a
billion times at run-time.
>> def f(): return "One"
>> def g(): return "Two"
>>
>> h=f
> Let me see if I can draw you a more complete picture. Suppose I have a
> function that relies on (let's say) something random or unpredictable:
>
> def get_data():
> return time.strftime("%S:%H")
> Now I use `get_data` in another function:
>
> def spam():
> value = get_stuff().replace(":", "")
(I assume you mean get_data here.)
> How do I test the `spam` function? I cannot easily predict what the
> `get_data` function will return.
>
> In Python, I can easily monkey-patch this for the purposes of testing, or
> debugging, by introducing a test double (think of "stunt double") to
> replace the real `get_data` function:
>
> import mymodule
> mymodule.get_data = lambda: "1:1"
> assert spam() == "Spam to the 11"
(How do you get back the original get_data?) But this looks a very
dangerous technique. Suppose, during the test, that another function in
mymodule, or one that imports it, needs access to the original get_data
function to work properly? Now it will get back nonsense.
> How would you do it, when functions are constant? You would have to re-write
> the module to allow it:
There are a dozen ways of doing it. It may involve temporary renaming or
hiding. But what you don't want is for production code to be lumbered
with all these lookups (and having to sort out arguments, keywords and
defaults) at runtime, just to make it a bit easier for debug code to run.
I think anyway that any Python program using dynamic functions, can be
trivially transformed to one that uses static functions. It won't be
pretty, but any function:
def f(): whatever
could be rewritten as:
def __f(): whatever
f = __f()
But now the static name __f is available for direct use, and can be
depended on not to change.
(Perhaps such a convention can be used anyway. A functions that starts
with "__" or uses some other device, the compiler and runtime will know
it will always be that function, and could allow some optimisations.)
(It's not quite so trivial for import module names, as you can't really
just rename all modules! But in theory it could be done.)
> I once monkey-patched the `len` built-in so I could monitor the progress of
> a long-running piece of code that wasn't written to give any feedback.
These ought to be tricks that you do with source code. It shouldn't be
necessary for an implementation to allow that.
(But doesn't len() already have a mechanism where you can override it
anyway?)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-14 14:01 +1100 |
| Message-ID | <56e62980$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #104763 |
On Mon, 14 Mar 2016 12:16 am, BartC wrote:
> On 13/03/2016 09:39, Steven D'Aprano wrote:
>> On Sun, 13 Mar 2016 04:54 am, BartC wrote:
>
>>> Common sense tells you it is unlikely.
>>
>> Perhaps your common sense is different from other people's common sense.
>> To me, and many other Python programmers, it's common sense that being
>> able to replace functions or methods on the fly is a useful feature worth
>> having.
>
> Worth having but at significant cost. But look at my jpeg test (look at
> any other similar programs); how many function names are used
> dynamically? How many functions *really* need to be dynamic?
As difficult as it may seem sometimes, Python is not a specialist
programming language designed to be optimal for your jpeg test, it is a
general purpose programming language designed for many different uses :-)
"Really need" is a funny thing. We don't *really need* anything beyond
machine language, or maybe assembly code mnemonics that correspond directly
to machine codes. Everything beyond that is either, depending on your
perspective, a waste of time that leads to inefficient code, or the best
thing for programming ever that saves programmer time and effort and
increases productivity.
You may not have noticed yet *wink* but Python's emphasis is more on the
programmer productivity side than the machine efficiency side. And from
that perspective, it can be argued that, yes, absolutely, all those
functions *need* to be dynamic, or at least have the possibility to be
dynamic if and when needed.
>>> (Have you tried looking at the CPython sources?
>
>> Right. Now add *on top of that complexity* the extra complexity needed to
>> manage not one, but *two* namespaces for every scope: one for "variables"
>> and one for "functions and methods".
>
> No, there's one namespace per scope. (Otherwise you could have a
> function 'f' and a variable 'f' in each scope.)
I was going to ask you about that.
> Perhaps what you mean is the number of different kinds of identifiers
> there can be. At the minute, apart from obvious, fixed, reserved words
> (I assume there are some!),
There are reserved words -- "for", "if", "else", "def", etc. The compiler
deals with reserved words at compile time: you get a syntax error if you
try to use them as a variable name, not a runtime error.
> there seems to be just one kind. The
> different categories (function, variable, class, built-in, module etc)
> are sorted out at *run-time*.
What do you mean by "sorted out"? You have names in a namespace which are
bound to objects. Once you have bound a name, you can rebind it:
x = 23
x = 'abc'
is just a rebinding where the value of x changes from 23 to 'abc'.
> Some of this will just move to *compile-time*.
How? It's easy to say "just move it to compile time", but *how* do you move
it (don't say "by editing the Python interpreter's source code"), and what
*precisely* is "it"?
At compile time, you don't in general know what value things will have. You
don't even know what type they will have (since the type of an object is
part of its value).
Here is an extreme example to demonstrate the difficulty:
import random
if random.random() < 0.5:
def f():
return 1
else:
f = "hello"
f = "goodbye"
So tell me: *at compile time*, how do you know whether the final binding
(assignment of "goodbye" to variable f) should be allowed or not?
> Same amount of
> complexity, but now you do it just once at compile-time, instead of a
> billion times at run-time.
I don't think you are, but let's suppose you're right and that the compiler
can reliably detect and prevent code like this:
def f(): return 1
g = f
g = something_else # allowed
f = something_else # not allowed
How do you intend to prevent this?
def f(): return 1
exec "f = something_else"
Suppose we removed the ability to rebind names that were bound to a
function, as you suggest. There's a very important and commonplace use for
rebinding functions that we would lose: decorators.
"Good riddance," you might say, "I never use them." Okay, but if so, that is
certainly the Blub paradox talking. Decorators have completely transformed
Python since decorator syntax was introduced in (by memory) version 2.3.
Decorators are a hugely important part of Python, and having to give them
up in order to get compile-time-constant functions would gut the language
and cripple almost all major libraries and code bases.
Decorators themselves were possible before 2.3(?), but they were
inconvenient to use and didn't have a well-known name and so nobody really
used them:
# Before decorator syntax
def func():
...
func = decorate(func)
# After decorator syntax
@decorate
def func():
...
where decorate itself is a function which usually pre- or post-processes the
original function. (Decorators can do much, much more, but that's probably
the most common use-case.)
Decorator syntax is just syntactic sugar for a wrapper around a function,
assigned to the same name as the function. Now, maybe a smart enough
interpreter will somehow deal with this. But there are times where you
cannot use decorator syntax, and have to write it the old-school way:
func = decorate(func)
(Even if it is only for backwards-compatibility.) In 2016, Python will no
more give that up than give up strings or ints.
>>> def f(): return "One"
>>> def g(): return "Two"
>>>
>>> h=f
>
>> Let me see if I can draw you a more complete picture. Suppose I have a
>> function that relies on (let's say) something random or unpredictable:
>>
>> def get_data():
>> return time.strftime("%S:%H")
>
>> Now I use `get_data` in another function:
>>
>> def spam():
>> value = get_stuff().replace(":", "")
>
> (I assume you mean get_data here.)
Yes, thank you.
>> How do I test the `spam` function? I cannot easily predict what the
>> `get_data` function will return.
>>
>> In Python, I can easily monkey-patch this for the purposes of testing, or
>> debugging, by introducing a test double (think of "stunt double") to
>> replace the real `get_data` function:
>>
>> import mymodule
>> mymodule.get_data = lambda: "1:1"
>> assert spam() == "Spam to the 11"
>
> (How do you get back the original get_data?)
It's a test module. You let the test finish, the interpreter shuts down, and
everything goes back to normal. You haven't modified the "mymodule" code on
disk.
What if you have more tests to run? That's hardly more complicated:
import mymodule
save = mymodule.get_data
try:
mymodule.get_data = lambda: "1:1"
assert spam() == "Spam to the 11"
finally:
mymodule.get_data = save
# more tests go here...
Of course, proper test frameworks will provide this as a feature of the
framework. For example, unittest will run setup and cleanup code before and
after each test, so you put your patch in the setup code and the restore in
the cleanup.
> But this looks a very
> dangerous technique. Suppose, during the test, that another function in
> mymodule, or one that imports it, needs access to the original get_data
> function to work properly? Now it will get back nonsense.
I suppose that's a theoretical possibility. But in practice, it doesn't come
up, or at least not often. Unit tests, in particular, are small and
focused. If you are testing `spam`, you're not going to call a bunch of
other functions or other modules. That goes against the idea of unit
testing.
I suppose that your concern is more realistic when it comes to integration
testing. But integration tests are, by their nature, much bigger and more
complex. You can't replace components in an integration test, because then
you aren't testing the integration between all your components.
Trust me, runtime mocking is a standard part of Python. This is not some
weird and wacky corner done by desperadoes hacking on the extremes of the
language, it is an official language feature with standard library support:
https://docs.python.org/3/library/unittest.mock.html
>> How would you do it, when functions are constant? You would have to
>> re-write the module to allow it:
>
> There are a dozen ways of doing it. It may involve temporary renaming or
> hiding. But what you don't want is for production code to be lumbered
> with all these lookups (and having to sort out arguments, keywords and
> defaults) at runtime, just to make it a bit easier for debug code to run.
>
> I think anyway that any Python program using dynamic functions, can be
> trivially transformed to one that uses static functions. It won't be
> pretty, but any function:
>
> def f(): whatever
>
> could be rewritten as:
>
> def __f(): whatever
> f = __f()
>
> But now the static name __f is available for direct use, and can be
> depended on not to change.
No it can't. You haven't thought it through.
(1) Are you expecting to write "__f()" inside your code when you mean to
call f()? If so, then what's the purpose of f()? If not, then you
write "f()" and nothing has changed: the interpreter has to do a runtime
lookup because f might have changed.
(2) What is stopping people from changing __f in all the many different ways
that it could be changed?
__f = something_else
globals()['__f'] = something_else
exec '__f = something_else'
> (Perhaps such a convention can be used anyway. A functions that starts
> with "__" or uses some other device, the compiler and runtime will know
> it will always be that function, and could allow some optimisations.)
Now that I've shown you all the ways that code can be changed on the fly,
and probably convinced you that it is impossible to optimize Python without
changing the language, I'm going to tell you that in fact all is not lost.
There is considerable discussion going on among the core devs about
providing official support for both AST and byte code transformation tools:
https://www.python.org/dev/peps/pep-0511/
which will allow the sorts of optimizations you want, only *safely* and
without compromising on Python's dynamism.
I really recommend you read PEP 511 and see what Victor Stinner has in mind
for Python 3.6. (I believe that his work on this is being funded by Red
Hat.)
> (It's not quite so trivial for import module names, as you can't really
> just rename all modules! But in theory it could be done.)
>
>> I once monkey-patched the `len` built-in so I could monitor the progress
>> of a long-running piece of code that wasn't written to give any feedback.
>
> These ought to be tricks that you do with source code. It shouldn't be
> necessary for an implementation to allow that.
No, absolutely not! There is no "ought to do this by editing the source
code" here -- I reject completely your primitive and crippled language that
forces me to edit the source code and recompile/reload like some sort of
savage *wink*
> (But doesn't len() already have a mechanism where you can override it
> anyway?)
You're thinking of the __len__ magic method, for implementing len() of your
own classes. That's completely different.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-14 13:00 +0000 |
| Message-ID | <nc6cf4$ftc$1@dont-email.me> |
| In reply to | #104798 |
On 14/03/2016 03:01, Steven D'Aprano wrote:
> On Mon, 14 Mar 2016 12:16 am, BartC wrote:
>> Worth having but at significant cost. But look at my jpeg test (look at
>> any other similar programs); how many function names are used
>> dynamically? How many functions *really* need to be dynamic?
>
> As difficult as it may seem sometimes, Python is not a specialist
> programming language designed to be optimal for your jpeg test, it is a
> general purpose programming language designed for many different uses :-)
jpeg is an example of the sort of program that many, many people are
writing. The sort where you write a bunch of functions, and you write
code that calls them.
Sometimes, you need to call a function indirectly, or need a table of
functions, or need to pass a function as an argument, but that's
possible /without having to rename functions/. Even C can do all this.
>> there seems to be just one kind. The
>> different categories (function, variable, class, built-in, module etc)
>> are sorted out at *run-time*.
>
> What do you mean by "sorted out"?
Well, in the case of executing f(a,b,x=c), then runtime will do the
lookup of f, check the number of arguments, sort out that keyword
argument, all that stuff.
That could be done at compile-time (ie. the byte-code compiler) if the
compiler had sight of the definition of f, and it knew for sure the f in
f() referred to that definition.
> You have names in a namespace which are
> bound to objects. Once you have bound a name, you can rebind it:
> At compile time, you don't in general know what value things will have. You
> don't even know what type they will have (since the type of an object is
> part of its value).
That's true of *variables*. It needn't be true of *functions* and
*modules* and *classes* because you've told the compiler exactly what
they are!
If you want to do this with functions, I've already shown a few times a
technique where you split the function name used with 'def' into two: a
fixed static name and a dynamic name, a 'pointer' initially referring to
this function, that can later be assigned something else. If you have to.
> Here is an extreme example to demonstrate the difficulty:
>
>
> import random
> if random.random() < 0.5:
> def f():
> return 1
> else:
> f = "hello"
>
> f = "goodbye"
>
>
> So tell me: *at compile time*, how do you know whether the final binding
> (assignment of "goodbye" to variable f) should be allowed or not?
First, let me try and emulate that exact behaviour in a 'crippled'
language that doesn't allow function rebinding:
function f1= {return 1}
if random(1)<0.5 then
f:=f1
else
f:="hello
fi
f:="goodbye"
So the question doesn't come up; we're simply dealing with variables.
The actual function (the name that permanently refers to the code
'return 1', or 'f1' in my example) doesn't change.
> I don't think you are, but let's suppose you're right and that the compiler
> can reliably detect and prevent code like this:
>
> def f(): return 1
> g = f
> g = something_else # allowed
> f = something_else # not allowed
Are we talking about some imaginary version of Python where the ability
to re-bind function, module and class names hadn't been allowed?
Then you would simply tweak the code so that 'f' the variable and 'f'
the actual function are different names.
Or how you change Python now to have both fixed function names yet allow
all these manipulations?
I don't know. People don't seem to like adding annotations such as:
static def f(): return 1
which would force you to create an alias for f as I said above:
static def _f(): return 1
f = _f
> How do you intend to prevent this?
>
> def f(): return 1
> exec "f = something_else"
(I don't use exec or eval, and have never seriously implemented them. In
fact I wrote these comments once in comp.programming a few years back:
>> Perhaps an "Eval Index" can be created which measures how much Eval
>> slows down a language: the bigger the slow-down, then the more
>> efficient would be the language. And it could be measured by putting
>> Eval "...." around every line or statement (or smallest unit of
>> which Eval can make sense) of a benchmark program and seeing how
>> much it slows down.
>>
>> (And something like Lisp I'd imagine would have an Eval Index of 1.0
>> :-) )
But to get back to your question: same answer as above.
> Suppose we removed the ability to rebind names that were bound to a
> function, as you suggest. There's a very important and commonplace use for
> rebinding functions that we would lose: decorators.
>But there are times where you
> cannot use decorator syntax, and have to write it the old-school way:
>
> func = decorate(func)
I can't see a problem here. Just a minor bit of renaming needed.
(Although I don't understand whatever else decorators too.)
Yes, there's a bit of inconvenience when you're importing a library
where you're not allowed to re-bind the functions inside it, so that you
can use the same name to mean something different.
But how many programs need that functionality? It might be a case of the
tail wagging the dog...
And there will generally be a way around it.
>> I think anyway that any Python program using dynamic functions, can be
>> trivially transformed to one that uses static functions. It won't be
>> pretty, but any function:
>>
>> def f(): whatever
>>
>> could be rewritten as:
>>
>> def __f(): whatever
>> f = __f()
> No it can't. You haven't thought it through.
> (1) Are you expecting to write "__f()" inside your code when you mean to
> call f()? If so, then what's the purpose of f()? If not, then you
> write "f()" and nothing has changed: the interpreter has to do a runtime
> lookup because f might have changed.
> (2) What is stopping people from changing __f in all the many different ways
> that it could be changed?
The above is simply to demonstrate that a program that relies on writing
to function names (ie. the names that follow 'def') can be transformed
into an equivalent program where such a name doesn't need writing to.
Ergo, Python doesn't /need/ mutable function names. (Disclaimer: this is
conjecture on my part...)
I'm not suggesting that people now have to start writing these aliases
everywhere (that would be needed in more languages that foolishly
separate the concept of a function, from a reference to a function).
It just opens up the possibility of such static functions which can lead
to more streamlined or more easily optimisable code.
> Now that I've shown you all the ways that code can be changed on the fly,
> and probably convinced you that it is impossible to optimize Python without
> changing the language,
I'm sure it can. Projects such as PyPy have shown that, and on certain
programs that can give dramatic increases in performance far beyond what
is possibly by tinkering with CPython.
But because I do language design, I can see many possibilities from
changing the language too!
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 14 of 16 — ← Prev page 1 … 12 13 [14] 15 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web