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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 23:21 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f67ee3$0$1583$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105722 |
On Sat, 26 Mar 2016 01:59 pm, Paul Rubin wrote:
> Steven D'Aprano <steve@pearwood.info> writes:
>> Culturally, C compiler writers have a preference for using undefined
>> behaviour to allow optimizations, even if it means changing the semantics
>> of your code.
>
> If your code has UB then by definition it has no semantics to change.
> Code with UB has no meaning.
Ah, a language lawyer, huh? :-P
By the rules of the C standard, you're right, but those rules make use of a
rather specialised definition of "no meaning" or "meaningless". I'm using
the ordinary English sense. For example, would you consider that this
isolated C code is "meaningless"?
int i = n + 1;
I'm not talking about type errors where n is not an int. We can assume that
n is also an int. I bet that you know exactly what that line of code means.
But according to the standard, it's "meaningless", since it might overflow,
and signed int overflow is Undefined Behaviour.
Even the C FAQ (as quoted by John Regehr) implies that code which is defined
as "meaningless" may have meaning in the ordinary English sense:
[quote]
Anything at all can happen; the Standard imposes no requirements.
The program may fail to compile, or it may execute incorrectly
(either crashing or silently generating incorrect results), or it
may fortuitously do EXACTLY WHAT THE PROGRAMMER INTENDED.
[Emphasis added.]
http://blog.regehr.org/archives/213
If the code is "meaningless", how can we say that it does what the
programmer intended?
In plain English, if the programmer had an intention for the code, and it
was valid C syntax, it's not hard to conclude that the code has some
meaning. Even if that meaning isn't quite what the programmer expected.
Compilers are well known for only doing what you tell them to do, not what
you want them to do. But in the case of C and C++ they don't even do what
you tell them to do.
When I talk about changing the semantics of the code you write, I'm using a
plain English sense of "meaning". Start with a simple-minded, non-
optimizing C compiler -- what Raymond Chen refers to as a "classical
compiler". For example:
int table[4];
bool exists_in_table(int v)
{
for (int i = 0; i <= 4; i++) {
if (table[i] == v) return true;
}
return false;
}
There's an out-of-bounds error there, but as Chen puts it, a classical
compiler would mindlessly generate code that reads past the end of the
array. A bug, but a predictable one: you can reason about it, and the
effect will be dependent on whatever arbitrary value happens to be in that
memory location. A better compiler would generate an error and refuse to
compile code for it. Either way, in plain English, the meaning is obvious:
* Create an array of four ints, naming it "table".
* Declare a function named "exists_in_table", which takes an int "v" as
argument and returns a bool.
* This function iterates over i = 0 to 4 inclusive, returning true if the
i-th item of table equals the given v, and false if none of those items
equals the given v.
I don't believe for a second that you can't read that code well enough to
infer the intended meaning of it. Even I can read C well enough to do that.
Yet according to the C standard, that perfectly understandable code snippet
is deemed to be gibberish, and instead of returning true or false, the
compiler is permitted to erase your hard disk, or turn off your life-
support, if it so chooses. And as Raymond Chen describes, a post-classical
compiler will probably optimize that function to one which always returns
true.
As far as I know, there is no other language apart from C and C++ that takes
such a cavalier approach.
I cannot emphasis enough that the treatment of "undefined behaviour" is
intentional by the C standards committee. Given the absolutely catastrophic
effect it has had on the reliability, safety and security of code written
in C, in my opinion the C standard borders on professional negligence.
Programming in C becomes a battle to defeat the compiler and force it to do
what you tell it to do, all because the C standard was written by a bunch
of people whose number one priority was being able to make their benchmarks
look good.
Imagine a bridge builder who discovers a tiny, technical ambiguity or error
in the blueprints for a bridge. On one page, the documentation states that
there should be four rivets per metre in the supporting beams, but on
another page, it is described as five rivets per metre. What should the
builder do?
- ask for clarification and get the blueprints and documentation corrected?
- play it safe and use five rivets?
- declare that therefore the entire blueprints are meaningless, and so he is
free to optimize the bridge and reduce costs by using steel of a cheaper
grade, half the thickness, and one rivet per metre?
When the bridge collapses under the load of normal traffic, killing hundreds
of people, what comfort should we take from the fact that the builder was
able to optimize it so that it was half the weight, a quarter of the cost,
and finished ahead of schedule, compared to a bridge that would have
actually done the job it was designed for?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-27 00:22 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.36.1458998575.28225.python-list@python.org> |
| In reply to | #105754 |
On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> In plain English, if the programmer had an intention for the code, and it
> was valid C syntax, it's not hard to conclude that the code has some
> meaning. Even if that meaning isn't quite what the programmer expected.
> Compilers are well known for only doing what you tell them to do, not what
> you want them to do. But in the case of C and C++ they don't even do what
> you tell them to do.
>
Does this Python code have meaning?
x = 5
while x < 10:
print(x)
++x
It's a fairly direct translation of perfectly valid C code, and it's
syntactically valid. When the C spec talks about accidentally doing
what you intended, that would be to have the last line here increment
x. But that's never a requirement; compilers/interpreters are not
mindreaders.
The main reason the C int has undefined behaviour is that it's
somewhere between "fixed size two's complement signed integer" and
"integer with plenty of room". A C compiler is generally free to use a
larger integer than you're expecting, which will cause numeric
overflow to not happen. That's (part of[1]) why overflow of signed
integers is undefined - it'd be too costly to emulate a smaller
integer. So tell me... what happens in CPython if you incref an object
more times than the native integer will permit? Are you bothered by
this possibility, or do you simply assume that nobody will ever do
that? Does C's definition of undefined behaviour mean that this code
can be optimized away, thus achieving nothing?
typedef struct _object {
_PyObject_HEAD_EXTRA
Py_ssize_t ob_refcnt;
struct _typeobject *ob_type;
} PyObject;
#define Py_INCREF(op) ( \
_Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \
((PyObject *)(op))->ob_refcnt++)
The reftotal and debug comma are both empty in non-debug builds. The
meat of this is simply a double-plus increment of a Py_ssize_t
integer, which is defined in pyport.h as a signed integer.
Of course this won't be optimized away, though. The only part that's
undefined is "what exactly happens if you overflow an integer?". And
you shouldn't be doing that at all; if you do, it's a bug, one way or
another. The compiler cannot be expected to magically know what you
intended to happen, so it's allowed to assume that this isn't what
your code meant to do. If you care about capping refcounts, you need
to do that yourself, somehow - don't depend on the compiler, because
you can't even know exactly how wide that refcount is.
ChrisA
[1] The other part being that C didn't want to mandate two's
complement, although I'm pretty sure that could be changed today
without breaking any modern architectures.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-26 14:09 +0000 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd651e$21g$1@dont-email.me> |
| In reply to | #105755 |
On 26/03/2016 13:22, Chris Angelico wrote: > On Sat, Mar 26, 2016 at 11:21 PM, Steven D'Aprano <steve@pearwood.info> wrote: >> In plain English, if the programmer had an intention for the code, and it >> was valid C syntax, it's not hard to conclude that the code has some >> meaning. Even if that meaning isn't quite what the programmer expected. >> Compilers are well known for only doing what you tell them to do, not what >> you want them to do. But in the case of C and C++ they don't even do what >> you tell them to do. >> > > Does this Python code have meaning? > > x = 5 > while x < 10: > print(x) > ++x > > > It's a fairly direct translation of perfectly valid C code, and it's > syntactically valid. When the C spec talks about accidentally doing > what you intended, that would be to have the last line here increment > x. But that's never a requirement; compilers/interpreters are not > mindreaders. I'm surprised that both C and Python allow statements that apparently do nothing. In both, an example is: x on a line by itself. This expression is evaluated, but then any result discarded. If there was a genuine use for this (for example, reporting any error with the evaluation), then it would be simple enough to require a keyword in front. Not allowing these standalone expressions allows extra errors to be picked up including '++x' and 'next' in Python. (I think simply translating '++x' in Python to 'x+=1' has already been discussed in the past.) > The main reason the C int has undefined behaviour is that it's > somewhere between "fixed size two's complement signed integer" and > "integer with plenty of room". A C compiler is generally free to use a > larger integer than you're expecting, which will cause numeric > overflow to not happen. That's (part of[1]) why overflow of signed > integers is undefined - it'd be too costly to emulate a smaller > integer. So tell me... what happens in CPython if you incref an object > more times than the native integer will permit? Are you bothered by > this possibility, or do you simply assume that nobody will ever do > that? (On a ref-counted scheme I use, with 32-bit counts (I don't think it matters if they are signed or not), each reference implies a 16-byte object elsewhere. For the count to wrap around back to zero, that would mean 64GB of RAM being needed. On a 32-bit system, something else will go wrong first. Even on 64-bits, it's a possibility I suppose although you might notice memory problems sooner.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-27 01:30 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.37.1459002640.28225.python-list@python.org> |
| In reply to | #105758 |
On Sun, Mar 27, 2016 at 1:09 AM, BartC <bc@freeuk.com> wrote:
> I'm surprised that both C and Python allow statements that apparently do
> nothing. In both, an example is:
>
> x
>
> on a line by itself. This expression is evaluated, but then any result
> discarded. If there was a genuine use for this (for example, reporting any
> error with the evaluation), then it would be simple enough to require a
> keyword in front.
Tell me, which of these is a statement that "does nothing"?
foo
foo.bar
foo["bar"]
foo.__call__
foo()
int(foo)
All of them are expressions to be evaluated and the result discarded.
I'm sure you'll recognize "foo()" as useful code, but to the
interpreter, they're all the same. And any one of them could raise an
exception rather than emit a value; for instance, consider these code
blocks:
# Personally, I prefer doing it the other way, but
# if you have a big Py2 codebase, this will help
# port it to Py3.
try: raw_input
except NameError: raw_input = input
try: int(sys.argv[1])
except IndexError:
print("No argument given")
except ValueError:
print("Not an integer")
In each case, the "dummy evaluation" of an expression is used as a way
of asking "Will this throw?". That's why this has to be squarely in
the hands of linters, not the main interpreter; there's nothing that
can't in some way be useful.
>> The main reason the C int has undefined behaviour is that it's
>> somewhere between "fixed size two's complement signed integer" and
>> "integer with plenty of room". A C compiler is generally free to use a
>> larger integer than you're expecting, which will cause numeric
>> overflow to not happen. That's (part of[1]) why overflow of signed
>> integers is undefined - it'd be too costly to emulate a smaller
>> integer. So tell me... what happens in CPython if you incref an object
>> more times than the native integer will permit? Are you bothered by
>> this possibility, or do you simply assume that nobody will ever do
>> that?
>
>
> (On a ref-counted scheme I use, with 32-bit counts (I don't think it matters
> if they are signed or not), each reference implies a 16-byte object
> elsewhere. For the count to wrap around back to zero, that would mean 64GB
> of RAM being needed. On a 32-bit system, something else will go wrong first.
>
> Even on 64-bits, it's a possibility I suppose although you might notice
> memory problems sooner.)
C code can claim references to Python objects without having actual
pointers anywhere. A naive object traversal algorithm could claim
temporary references on all the objects it moves past (to ensure they
don't get garbage collected in the middle), and then get stuck in an
infinite loop traversing a reference loop, thus infinitely increasing
reference counts. Yeah, it can happen... I've had bugs like that in my
code...
Point is, CPython can generally assume that bug-free code will never
get anywhere *near* the limit of a signed integer. Consequently, C's
undefined behaviour isn't a problem; it does NOT mean we need to be
scared of signed integers.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-26 15:24 +0000 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd69eb$hqo$1@dont-email.me> |
| In reply to | #105759 |
On 26/03/2016 14:30, Chris Angelico wrote:
> On Sun, Mar 27, 2016 at 1:09 AM, BartC <bc@freeuk.com> wrote:
>> I'm surprised that both C and Python allow statements that apparently do
>> nothing. In both, an example is:
>>
>> x
>>
>> on a line by itself. This expression is evaluated, but then any result
>> discarded. If there was a genuine use for this (for example, reporting any
>> error with the evaluation), then it would be simple enough to require a
>> keyword in front.
>
> Tell me, which of these is a statement that "does nothing"?
>
> foo
> foo.bar
> foo["bar"]
> foo.__call__
> foo()
> int(foo)
>
> All of them are expressions to be evaluated and the result discarded.
> I'm sure you'll recognize "foo()" as useful code, but to the
> interpreter, they're all the same.
Out of that lot, only foo() is something that is commonly written both
as an expression and standalone statement.
> And any one of them could raise an
> exception rather than emit a value; for instance, consider these code
> blocks:
>
> # Personally, I prefer doing it the other way, but
> # if you have a big Py2 codebase, this will help
> # port it to Py3.
> try: raw_input
> except NameError: raw_input = input
>
> try: int(sys.argv[1])
> except IndexError:
> print("No argument given")
> except ValueError:
> print("Not an integer")
>
> In each case, the "dummy evaluation" of an expression is used as a way
> of asking "Will this throw?". That's why this has to be squarely in
> the hands of linters, not the main interpreter; there's nothing that
> can't in some way be useful.
But notice that to render such an evaluation 'useful', you've put 'try:'
in front, which is also a cue to the reader.
Now you can't just do that anyway (try expects an except block to
follow). But my suggestion was to have required a keyword in front of
such expressions. Then no linter is needed. And stops some
head-scratching from people who have to read the code.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-26 23:34 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87poug5t0c.fsf@nightsong.com> |
| In reply to | #105761 |
BartC <bc@freeuk.com> writes: > But my suggestion was to have required a keyword in front of > such expressions. Should there be a keyword in front of a line containing "sqrt(x)" ? What about "launch(missiles)" ? The compiler can't tell which of those expressions has a side effect. The first might be buggy code but the second is idiomatic.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-27 12:31 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd8g4p$aqk$1@dont-email.me> |
| In reply to | #105821 |
On 27/03/2016 07:34, Paul Rubin wrote: > BartC <bc@freeuk.com> writes: >> But my suggestion was to have required a keyword in front of >> such expressions. > > Should there be a keyword in front of a line containing "sqrt(x)" ? > What about "launch(missiles)" ? They both look like function calls. Function calls are *very* commonly used as standalone expressions. You /could/ stipulate that they be written: call launch(missiles) # like Fortran iirc but that wouldn't be popular and is unnecessary. > The compiler can't tell which of those expressions has a side effect. > The first might be buggy code but the second is idiomatic. Whether there are side-effects is not quite as important as picking up things that are likely to be errors: f() # Probably OK g() # Probably OK f()+g() # Probably not OK Maybe there is some legitimate, obscure reason for writing the latter, but stick some indicator in front to tell the language (and whoever happens to be reading the code) that this is what you intend. In the case of sqrt(), many languages appear to treat maths operators as regular functions, so would be hard to justify special treatment. And in Python, 'sqrt' could be reassigned to do something different. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-27 09:47 -0400 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.78.1459086447.28225.python-list@python.org> |
| In reply to | #105835 |
On Sun, 27 Mar 2016 12:31:26 +0100, BartC <bc@freeuk.com> declaimed the
following:
>On 27/03/2016 07:34, Paul Rubin wrote:
>> BartC <bc@freeuk.com> writes:
>>> But my suggestion was to have required a keyword in front of
>>> such expressions.
>>
>> Should there be a keyword in front of a line containing "sqrt(x)" ?
>> What about "launch(missiles)" ?
>
>They both look like function calls. Function calls are *very* commonly
>used as standalone expressions.
>
>You /could/ stipulate that they be written:
>
> call launch(missiles) # like Fortran iirc
>
Except that FORTRAN also explicitly defines them as
subroutine xxx()
vs
return-type function yyy()
and will generate a compile error if you "call" the latter, or put the
former in-line of an expression
This would be the equivalent of removing "def" from Python, and adding
two new keywords: "sub" and "fun"; modifying the behavior so that "fun"s
must have an explicit return statement (preferably with an explicit return
value), whereas "sub"s have no return and just ... end...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-27 15:43 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd8rcl$gef$1@dont-email.me> |
| In reply to | #105838 |
On 27/03/2016 14:47, Dennis Lee Bieber wrote: > On Sun, 27 Mar 2016 12:31:26 +0100, BartC <bc@freeuk.com> declaimed the > following: > >> On 27/03/2016 07:34, Paul Rubin wrote: >>> BartC <bc@freeuk.com> writes: >>>> But my suggestion was to have required a keyword in front of >>>> such expressions. >>> >>> Should there be a keyword in front of a line containing "sqrt(x)" ? >>> What about "launch(missiles)" ? >> >> They both look like function calls. Function calls are *very* commonly >> used as standalone expressions. >> >> You /could/ stipulate that they be written: >> >> call launch(missiles) # like Fortran iirc >> > Except that FORTRAN also explicitly defines them as > > subroutine xxx() > vs > return-type function yyy() > > and will generate a compile error if you "call" the latter, or put the > former in-line of an expression > > This would be the equivalent of removing "def" from Python, and adding > two new keywords: "sub" and "fun"; modifying the behavior so that "fun"s > must have an explicit return statement (preferably with an explicit return > value), whereas "sub"s have no return and just ... end... Well, that could be done in Python (not so usefully because you can't take account of such info until a call is attempted), but that's not what I'm talking about, which is simply allowing: fn(...) whether fn has an explicit return or not, and not allowing: fn # and other kinds of expression unless some keyword is used. (I've no idea what that might be; all the best ones are taken. But I've already said a keyword can be emulated via a dummy function call.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-03-27 08:48 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <1344e2bf-15d2-412e-9512-b0aba800dada@googlegroups.com> |
| In reply to | #105847 |
On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
> On 27/03/2016 14:47, Dennis Lee Bieber wrote:
> > On Sun, 27 Mar 2016 12:31:26 +0100, BartC <bc@freeuk.com> declaimed the
> > following:
> >
> >> On 27/03/2016 07:34, Paul Rubin wrote:
> >>> BartC <bc@freeuk.com> writes:
> >>>> But my suggestion was to have required a keyword in front of
> >>>> such expressions.
> >>>
> >>> Should there be a keyword in front of a line containing "sqrt(x)" ?
> >>> What about "launch(missiles)" ?
> >>
> >> They both look like function calls. Function calls are *very* commonly
> >> used as standalone expressions.
> >>
> >> You /could/ stipulate that they be written:
> >>
> >> call launch(missiles) # like Fortran iirc
> >>
> > Except that FORTRAN also explicitly defines them as
> >
> > subroutine xxx()
> > vs
> > return-type function yyy()
> >
> > and will generate a compile error if you "call" the latter, or put the
> > former in-line of an expression
> >
> > This would be the equivalent of removing "def" from Python, and adding
> > two new keywords: "sub" and "fun"; modifying the behavior so that "fun"s
> > must have an explicit return statement (preferably with an explicit return
> > value), whereas "sub"s have no return and just ... end...
>
> Well, that could be done in Python (not so usefully because you can't
> take account of such info until a call is attempted), but that's not
> what I'm talking about, which is simply allowing:
>
> fn(...)
>
> whether fn has an explicit return or not, and not allowing:
>
> fn # and other kinds of expression
>
> unless some keyword is used. (I've no idea what that might be; all the
> best ones are taken. But I've already said a keyword can be emulated via
> a dummy function call.)
Python *could* have made it an error to have a useless expression as a
statement. It would prevent certain kinds of errors. But it would also
complicate the language. How do we decide what is a "useless expression"?
As we've seen this might be an expression with a side-effect:
foo.bar
though it would be unusual. Should it be forbidden?
And how do we make docstrings, which are simply string literals as
statements? Or do we allow those? Perhaps we only allow those if they
are the first statement in a module, class, or function? How complicated
do we want these criteria to become?
One of Guido's principles in designing Python was to keep it simple,
even where that might mean people could make errors with it. This part
of the language is no different: any expression can be a statement.
Any real language is designed with a number of competing factors in mind.
It isn't a simple matter. Usually the answer to, "why was it done this
way?" is, "Because the designer had a different set of criteria, ordered
differently, than you do." Python cares about preventing errors. It
also cares about simplicity of design.
--Ned.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-03-27 12:39 -0400 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.90.1459096798.28225.python-list@python.org> |
| In reply to | #105854 |
On 3/27/2016 11:48 AM, Ned Batchelder wrote: > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote: >> whether fn has an explicit return or not, and not allowing: >> >> fn # and other kinds of expression >> >> unless some keyword is used. > > Python *could* have made it an error to have a useless expression as a > statement. In interactive mode, which is an essential part of Python, expression statements print the value of the expression. Thus no expression is useless. So Bart is proposing to either disable an extremely useful feature or split Python into two slightly different dialects. I think both are bad ideas. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-28 12:26 +1100 |
| Subject | Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <56f88839$0$1598$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105860 |
On Mon, 28 Mar 2016 03:39 am, Terry Reedy wrote:
> On 3/27/2016 11:48 AM, Ned Batchelder wrote:
>> On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
>
>>> whether fn has an explicit return or not, and not allowing:
>>>
>>> fn # and other kinds of expression
>>>
>>> unless some keyword is used.
>>
>> Python *could* have made it an error to have a useless expression as a
>> statement.
>
> In interactive mode, which is an essential part of Python, expression
> statements print the value of the expression. Thus no expression is
> useless.
>
> So Bart is proposing
I don't think Bart is intending this as an actual proposal to change Python
so much as just a hypothetical to discuss.
> to either disable an extremely useful feature or
> split Python into two slightly different dialects. I think both are bad
> ideas.
I don't think that's quite fair. The interactive interpreter is already
slightly different from non-interactive use, in that bare expressions print
the result, while in non-interactive use they just get garbage collected.
It wouldn't be that different to change "print versus ignore" into "print
versus raise error". I think it is a bit extreme to call that two different
dialects. If so, then the current interactive interpreter is also a
different dialect.
But that's not what makes this a bad idea.
Consider something like file.write. In Python 2, writing to a file behaves
like a procedure, and you write:
with open(filename) as file:
file.write("something")
In Python 3, the write method has changed to return the number of characters
or bytes actually written. But if you don't need that information, you
aren't *forced* to collect it and ignore it. You can just ignore it:
with open(filename) as file:
file.write("something")
is still perfectly legal. But Bart's suggestion would make that an error.
No, Bart's suggestion is perfectly reasonable for a linter, but not for
Python. Other languages may choose to be more restrictive. Pascal, for
example, requires you to declare subroutines as functions or procedures
depending on whether or not they return a value, and that's got much to
recommend it too. But Python made different choices.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-03-28 15:34 -0400 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <mailman.110.1459193711.28225.python-list@python.org> |
| In reply to | #105888 |
On 3/27/2016 9:26 PM, Steven D'Aprano wrote: > On Mon, 28 Mar 2016 03:39 am, Terry Reedy wrote: >> So Bart is proposing whether 'actually' or 'hypothetically' > I don't think Bart is intending this as an actual proposal to change Python > so much as just a hypothetical to discuss. I don't remember Bart saying anything of the sort. I'll let him clarify hit meaning. >> to either disable an extremely useful feature or >> split Python into two slightly different dialects. I think both are bad >> ideas. > > I don't think that's quite fair. I don't think your strained nitpicking of my statement is quite fair. It is definitely faulty. > The interactive interpreter is already > slightly different from non-interactive use, Yes, the extra behavior of interactive mode is specified in the Reference in the section on Expression statements. https://docs.python.org/3/reference/simple_stmts.html#expression-statements But as far as I can remember, both run the *SAME PYTHON LANGUAGE*. Dialects are a property of languages, not of interpreter modes. > in that bare expressions print the result, Expressions evaluate to objects. Having the interpreter also display the object is at most an added semantic. It is not a syntax difference and in that sense is not a *language* difference*. > while in non-interactive use they just get garbage collected. Garbage collection is not relevant to this proposal or discussion. AFAIK, Objects become eligible for garbage collection at the same time in either mode. > It wouldn't be that different to change "print versus ignore" into "print > versus raise error". Are you serious? Having the *same code* execute in one mode and raise in another, and thereby abort execution of all following code, is quite different. It makes the set of legal statements different and that is the basic definition of a language. It suite fair to call the different sets of legal statements 'slightly different dialects'. > I think it is a bit extreme to call that two different > dialects. Your nitpicking is what is extreme. > If so, then the current interactive interpreter is also a > different dialect. To repeat, the current interactive interpreter runs the same sequence of statements, which is to say, the same language. It just outputs extra information about what is going on. CPython debug builds display even more extra information (about references). >>> 0 0 [44187 refs] >>> a=0 [44189 refs] >>> 0 0 [44189 refs] This in itself does not mean that the debug interactive interpreter is yet a third dialect of Python. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-27 17:58 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd938u$das$1@dont-email.me> |
| In reply to | #105854 |
On 27/03/2016 16:48, Ned Batchelder wrote: > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote: >> On 27/03/2016 14:47, Dennis Lee Bieber wrote: >> Well, that could be done in Python (not so usefully because you can't >> take account of such info until a call is attempted), but that's not >> what I'm talking about, which is simply allowing: >> >> fn(...) >> >> whether fn has an explicit return or not, and not allowing: >> >> fn # and other kinds of expression >> >> unless some keyword is used. (I've no idea what that might be; all the >> best ones are taken. But I've already said a keyword can be emulated via >> a dummy function call.) > > Python *could* have made it an error to have a useless expression as a > statement. It would prevent certain kinds of errors. But it would also > complicate the language. How do we decide what is a "useless expression"? Probably one that would raise eyebrows when used as an expression. Such as 'f()+1', even though f() might have useful side-effects. > As we've seen this might be an expression with a side-effect: > > foo.bar > > though it would be unusual. Should it be forbidden? No. The language can require a prefix, or the coder can put it into a legal form (pass it to a dummy function for example). > And how do we make docstrings, which are simply string literals as > statements? Or do we allow those? Perhaps we only allow those if they > are the first statement in a module, class, or function? How complicated > do we want these criteria to become? There would be a list of expression terms that can also form independent statements. Not knowing Python, the list would comprise function calls (ie. the function call is top node in the AST of the expression), and docstrings. (In other languages it might also include assignments and increments.) The suggestion has also been made only bare names should be disallowed, which would probably trap most of the errors it causes, early on. > One of Guido's principles in designing Python was to keep it simple, > even where that might mean people could make errors with it. This part > of the language is no different: any expression can be a statement. Yeah, but even simpler would be that any statement can also be an expression! He didn't go that far though. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-03-27 10:19 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <38a7607d-cbd5-4f70-bfd2-49b2bb3ecc1e@googlegroups.com> |
| In reply to | #105862 |
On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote: > On 27/03/2016 16:48, Ned Batchelder wrote: > > On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote: > >> On 27/03/2016 14:47, Dennis Lee Bieber wrote: > > >> Well, that could be done in Python (not so usefully because you can't > >> take account of such info until a call is attempted), but that's not > >> what I'm talking about, which is simply allowing: > >> > >> fn(...) > >> > >> whether fn has an explicit return or not, and not allowing: > >> > >> fn # and other kinds of expression > >> > >> unless some keyword is used. (I've no idea what that might be; all the > >> best ones are taken. But I've already said a keyword can be emulated via > >> a dummy function call.) > > > > Python *could* have made it an error to have a useless expression as a > > statement. It would prevent certain kinds of errors. But it would also > > complicate the language. How do we decide what is a "useless expression"? > > Probably one that would raise eyebrows when used as an expression. Such > as 'f()+1', even though f() might have useful side-effects. > > > As we've seen this might be an expression with a side-effect: > > > > foo.bar > > > > though it would be unusual. Should it be forbidden? > > No. The language can require a prefix, or the coder can put it into a > legal form (pass it to a dummy function for example). Yes, I misspoke, by "forbidden" of course I meant, "forbidden as statement on its own," which is what we are talking about. > > > And how do we make docstrings, which are simply string literals as > > statements? Or do we allow those? Perhaps we only allow those if they > > are the first statement in a module, class, or function? How complicated > > do we want these criteria to become? > > There would be a list of expression terms that can also form independent > statements. Not knowing Python, the list would comprise function calls > (ie. the function call is top node in the AST of the expression), and > docstrings. It's a little frustrating to discuss language design when you claim not to know Python. Perhaps you could devote some off-list time to learning it? :) > The suggestion has also been made only bare names should be disallowed, > which would probably trap most of the errors it causes, early on. As Terry pointed out, the interactive interpreter would then need different rules, since of course using bare names there is essential. The interactive interpreter is already a bit different, but you can see this is starting to snowball. > > > One of Guido's principles in designing Python was to keep it simple, > > even where that might mean people could make errors with it. This part > > of the language is no different: any expression can be a statement. > > Yeah, but even simpler would be that any statement can also be an > expression! He didn't go that far though. Nope, he didn't. As I said, it's a complex set of design considerations. No single factor is going to be pushed to the maximum. I'm not sure what point you are making. --Ned.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-27 21:18 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd9f1i$q1e$1@dont-email.me> |
| In reply to | #105864 |
On 27/03/2016 18:19, Ned Batchelder wrote: > On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote: >> There would be a list of expression terms that can also form independent >> statements. Not knowing Python, the list would comprise function calls >> (ie. the function call is top node in the AST of the expression), and >> docstrings. > > It's a little frustrating to discuss language design when you claim not to > know Python. Perhaps you could devote some off-list time to learning it? :) Since the language is presumably available to anyone including non-experts, why shouldn't someone who is only going to use a subset, have an opinion on a troublesome part of the language? >>> One of Guido's principles in designing Python was to keep it simple, For a simple language, there appear to be quite a few esoteric uses being thought up for that feature! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-03-27 14:55 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <7461be36-370e-4ccb-8fea-433f03097ca9@googlegroups.com> |
| In reply to | #105871 |
On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote: > On 27/03/2016 18:19, Ned Batchelder wrote: > > On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote: > > >> There would be a list of expression terms that can also form independent > >> statements. Not knowing Python, the list would comprise function calls > >> (ie. the function call is top node in the AST of the expression), and > >> docstrings. > > > > It's a little frustrating to discuss language design when you claim not to > > know Python. Perhaps you could devote some off-list time to learning it? :) > > Since the language is presumably available to anyone including > non-experts, why shouldn't someone who is only going to use a subset, > have an opinion on a troublesome part of the language? It will be a partly-informed opinion. If you are OK with that, I guess I will have to be also. > >>> One of Guido's principles in designing Python was to keep it simple, > > For a simple language, there appear to be quite a few esoteric uses > being thought up for that feature! Yes, it's impressive the things a simple design can accomplish. In the end, I'm not sure what the goal of this discussion is. We've discussed something you don't like about Python. We've explained as best we can why the language is the way it is. You still think it's a deficiency. What now? --Ned.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-27 23:11 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <nd9ljq$l4c$1@dont-email.me> |
| In reply to | #105876 |
On 27/03/2016 22:55, Ned Batchelder wrote: > On Sunday, March 27, 2016 at 4:19:12 PM UTC-4, BartC wrote: >> On 27/03/2016 18:19, Ned Batchelder wrote: >>> On Sunday, March 27, 2016 at 12:58:23 PM UTC-4, BartC wrote: >> >>>> There would be a list of expression terms that can also form independent >>>> statements. Not knowing Python, the list would comprise function calls >>>> (ie. the function call is top node in the AST of the expression), and >>>> docstrings. >>> >>> It's a little frustrating to discuss language design when you claim not to >>> know Python. Perhaps you could devote some off-list time to learning it? :) >> >> Since the language is presumably available to anyone including >> non-experts, why shouldn't someone who is only going to use a subset, >> have an opinion on a troublesome part of the language? > > It will be a partly-informed opinion. If you are OK with that, I guess > I will have to be also. > >>>>> One of Guido's principles in designing Python was to keep it simple, >> >> For a simple language, there appear to be quite a few esoteric uses >> being thought up for that feature! > > Yes, it's impressive the things a simple design can accomplish. > > In the end, I'm not sure what the goal of this discussion is. We've > discussed something you don't like about Python. We've explained as best > we can why the language is the way it is. You still think it's a > deficiency. What now? Stalemate I guess. Actually I'm not that bothered by this, but as someone else brought it up, I just wondered why Python was doing the same as C in allowing arbitrary expressions to be evaluated for no apparent reason. Now I know. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-28 11:54 +1100 |
| Subject | Statements as expressions [was Re: Undefined behaviour in C] |
| Message-ID | <56f880ba$0$1617$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105862 |
On Mon, 28 Mar 2016 03:58 am, BartC wrote:
>> One of Guido's principles in designing Python was to keep it simple,
>> even where that might mean people could make errors with it. This part
>> of the language is no different: any expression can be a statement.
>
> Yeah, but even simpler would be that any statement can also be an
> expression! He didn't go that far though.
People say that, but I don't believe it. What does it mean to say that any
statement could also be an expression? If this statement is an expression:
if condition:
print(1)
print(2)
else:
print(3)
print(4)
what value should it return? Justify your choice.
What should be the return value of this statement?
while True:
x += 1
if condition: break
I don't think that "every statement is an expression" is conceptually
simpler at all. I think it is more difficult to understand. Nearly all
human languages make a distinction between things and actions:
* expressions return a value, which makes them a thing (noun);
* statements do something, which makes them an action (verb).
It's easy to understand the concept of an expression where the result is
dropped. "Hand me that hammer" and then you just drop the hammer on the
floor.
It's harder to understand the concept of functions (doing words, verbs) as
values. "First class functions" take a bit of mental effort to understand,
but the payoff it worth it.
But it is even harder to understand what it might mean for a while loop to
be a value, and the benefit of doing so seems significantly less than
compelling. Maybe it is easier for non-English speakers with quite
different linguistic models, but the benefit of adding statements as
expressions seems to me to be well less than the extra difficulty it would
produce.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-27 18:40 -0700 |
| Subject | Re: Statements as expressions [was Re: Undefined behaviour in C] |
| Message-ID | <87h9fr5qig.fsf@nightsong.com> |
| In reply to | #105884 |
Steven D'Aprano <steve@pearwood.info> writes: > if condition: > print(1) > print(2) > else: > print(3) > print(4) > what value should it return? Justify your choice. It could whatever value that the last call to print() returns. Lisp has worked like that since the 1950's. > What should be the return value of this statement? > > while True: > x += 1 > if condition: break It could return None, or break(val) could return val. > I don't think that "every statement is an expression" is conceptually > simpler at all. I think it is more difficult to understand. It hasn't been a problem in Lisp or its descendants, Erlang, Haskell, etc. I don't know about Ruby or Javascript. > But it is even harder to understand what it might mean for a while > loop to be a value, and the benefit of doing so seems significantly > less than compelling. It means that you get to use an incredibly simple and beautiful evaluation model. Have you ever used Lisp or Scheme? Give it a try sometime. Excellent free book: https://mitpress.mit.edu/sicp/full-text/book/book.html
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web