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 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-28 12:24 +1100 |
| Subject | Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <56f887c1$0$1598$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105835 |
On Sun, 27 Mar 2016 10:31 pm, BartC wrote: > 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 You don't and can't know what's "probably not" okay unless you know what type of object both f and g return. Don't think about floats and ints and strings. Think of complex objects with operator overloading. You're probably thinking of `x + y`. Instead, think of things like: graph + node database + table in a procedural style instead of a functional style. With operator overloading, we have the ability to write domain-specific little languages. It's not the compiler's job to cast value judgements on what is good or likely style, it must accept anything legal. If you want something to make value judgements about style, or get warnings about what looks like legal code but might be an error, then you should use a linter like PyChecker, Pylint, Jedi or similar. That's not the compiler's job. > 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 your language, you can make operator overloading illegal if you like, or discourage it by requiring special syntax, but in Python it is a first-class (pun not intended) programming style of equal standing to arithmetic, strings, method calls and modules. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-28 12:38 +1100 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <mailman.99.1459129574.28225.python-list@python.org> |
| In reply to | #105886 |
On Mon, Mar 28, 2016 at 12:24 PM, Steven D'Aprano <steve@pearwood.info> wrote: >> >> f() # Probably OK >> g() # Probably OK >> f()+g() # Probably not OK > > You don't and can't know what's "probably not" okay unless you know what > type of object both f and g return. > > Don't think about floats and ints and strings. Think of complex objects with > operator overloading. You're probably thinking of `x + y`. Instead, think > of things like: > > graph + node > database + table > > in a procedural style instead of a functional style. With operator > overloading, we have the ability to write domain-specific little languages. I would still look askance at code that adds two things and drops the result, though. The compiler can't discard it, but if a linter complains, I'd support that. A DSL that requires you to do this is, imo, poorly designed. It'll make every subsequent maintainer wonder if the code is buggy or not. But it's still... > ... not the compiler's job to cast value judgements on what is good or > likely style, it must accept anything legal. If you want something to make > value judgements about style, or get warnings about what looks like legal > code but might be an error, then you should use a linter like PyChecker, > Pylint, Jedi or similar. That's not the compiler's job. Exactly. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Tim Chase <python.list@tim.thechases.com> |
|---|---|
| Date | 2016-03-27 21:59 -0500 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <mailman.100.1459135120.28225.python-list@python.org> |
| In reply to | #105886 |
On 2016-03-28 12:38, Chris Angelico wrote:
> I would still look askance at code that adds two things and drops
> the result, though. The compiler can't discard it, but if a linter
> complains, I'd support that. A DSL that requires you to do this is,
> imo, poorly designed.
Is it only the "*add* two things" or are you decrying any generic
operator that gets evaluated and then drops the result?
Steven recently opened a thread ["Bash-like pipes in Python"] where
this exact sort of thing would be done:
get_values() | filter("smith") | sort("income") | send_to_printer()
Several different solutions were posited with varying degrees of
conciseness-vs-pythonicity-vs-pipe'ness.
That said, I'm in the "let the compiler accept valid syntax; leave it
to the linter" camp.
-tkc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-28 14:29 +1100 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <mailman.101.1459139574.28225.python-list@python.org> |
| In reply to | #105886 |
On Mon, Mar 28, 2016 at 1:59 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2016-03-28 12:38, Chris Angelico wrote:
>> I would still look askance at code that adds two things and drops
>> the result, though. The compiler can't discard it, but if a linter
>> complains, I'd support that. A DSL that requires you to do this is,
>> imo, poorly designed.
>
> Is it only the "*add* two things" or are you decrying any generic
> operator that gets evaluated and then drops the result?
>
> Steven recently opened a thread ["Bash-like pipes in Python"] where
> this exact sort of thing would be done:
>
> get_values() | filter("smith") | sort("income") | send_to_printer()
>
> Several different solutions were posited with varying degrees of
> conciseness-vs-pythonicity-vs-pipe'ness.
I was talking about any operator that, for built-in types, does no
mutation and has no effect aside from its return value. So yes, the
use of the pipe is a perfect counter-example - or rather, proof that
my concern is a code smell rather than fundamentally bad. C++ started
it with the iostream << and >> overloads; personally, I think that's
more cute than useful, but there are times when it can be extremely
useful.
So I revise my stance: A DSL that requires you to do this *may be*
poorly designed, and needs a very solid justification.
> That said, I'm in the "let the compiler accept valid syntax; leave it
> to the linter" camp.
Yeah definitely.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-28 13:18 +0100 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <ndb78d$qst$1@dont-email.me> |
| In reply to | #105886 |
On 28/03/2016 02:24, Steven D'Aprano wrote: > On Sun, 27 Mar 2016 10:31 pm, BartC wrote: >> 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 > > You don't and can't know what's "probably not" okay unless you know what > type of object both f and g return. > > Don't think about floats and ints and strings. Think of complex objects with > operator overloading. You're probably thinking of `x + y`. Instead, think > of things like: > > graph + node > database + table There's theory, and there's practice. Most types of statements start with a keyword. The ones that don't need a keyword are assignments (including augmented assignment), and standalone expressions (I'm sure someone will correct me if I'm wrong). And of standalone expressions, the vast majority that I can see are function calls (that is, an expression, of any complexity, ending with (...)). So no matter how many potentially useful counter-examples you can dig up, non-function-call expressions are still going to be highly unusual. And suspect. That's why it's not going to be much loss to disallow them /in that form/. (There are also docstrings, but until yesterday I didn't even know they were also expressions. Wikipedia says this: "Python docstrings appear as a string literal (not an expression) as the first statement following the definition of functions..." so their status is a little unclear. Whatever it is, they don't lead to the same head-scratching when they appear as arbitrary expressions that are not function calls.) > in a procedural style instead of a functional style. With operator > overloading, we have the ability to write domain-specific little languages. Sure. But give the reader a warning! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-28 16:29 +0300 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <87y492n32m.fsf@elektro.pacujo.net> |
| In reply to | #105910 |
BartC <bc@freeuk.com>: > So no matter how many potentially useful counter-examples you can dig > up, non-function-call expressions are still going to be highly > unusual. And suspect. > > That's why it's not going to be much loss to disallow them /in that > form/. Note that operators are front ends for dunder methods, which can have side effects. I'm not aware of such an example in Python, but C++ notoriously uses operator overloading in its common I/O idioms: cout << "Hello world!" << endl; It turns out that I am currently creating something exciting in Python that "abuses" operators similarly, although without side effects -- I hope to be able to present my results here soonish. So I would be careful not to throw the baby away with the bathwater. There was a time when recursion was viewed with great suspicion, and nested if/else constructs were considered playing with fire. You are clearly getting similar allergic reactions from Python's elegant degrees of freedom. And all the while Java, C# and even C++ are painfully trying to get what Python has had since the beginning. Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-03-29 18:12 +1100 |
| Subject | Re: Useless expressions [was Re: Undefined behaviour in C] |
| Message-ID | <56fa2ae1$0$1502$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105910 |
On Monday 28 March 2016 23:18, BartC wrote: > On 28/03/2016 02:24, Steven D'Aprano wrote: >> Don't think about floats and ints and strings. Think of complex objects >> with operator overloading. You're probably thinking of `x + y`. Instead, >> think of things like: >> >> graph + node >> database + table > > There's theory, and there's practice. [...] > So no matter how many potentially useful counter-examples you can dig > up, non-function-call expressions are still going to be highly unusual. > And suspect. Sure. If you want to call it a "code smell", no problem. It's not necessarily bad, but it's worth a second look. > That's why it's not going to be much loss to disallow them /in that form/. When you design your own language :-) feel free to design it that way. Python is designed differently. You don't have to agree with the decision, but that is the decision. The Python interpreter will accept any legal expression, and not try to guess which ones do and don't have side-effects, or which ones might be in error. Expressions include single names, so even they are allowed. If you want stricter rules, use a linter. > (There are also docstrings, but until yesterday I didn't even know they > were also expressions. Wikipedia says this: > > "Python docstrings appear as a string literal (not an expression) as the > first statement following the definition of functions..." > > so their status is a little unclear. I think what Wikipedia means is that you cannot use an expression that evaluates to a string as a docstring: py> def f(): ... "A string %s" % 23 ... py> f.__doc__ is None True It must be a string literal. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-03-29 18:35 +1100 |
| Subject | Re: Useless expressions |
| Message-ID | <mailman.132.1459236945.28225.python-list@python.org> |
| In reply to | #105956 |
Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> On Monday 28 March 2016 23:18, BartC wrote:
>
> > (There are also docstrings, but until yesterday I didn't even know
> > they were also expressions. Wikipedia says this:
> >
> > "Python docstrings appear as a string literal (not an expression) as
> > the first statement following the definition of functions..."
> >
> > so their status is a little unclear.
Thanks for raising this, Bart.
> I think what Wikipedia means is that you cannot use an expression that
> evaluates to a string as a docstring
I agree. I have edited that section of the article, hopefully it is now
clearer:
Python
The common practice, of documenting a code object at the head of its
definition, is captured by the addition of docstring syntax in the
Python language.
The docstring for a Python code object (a module, class, or
function) is the first statement of that code object, immediately
following the definition (the 'def' or 'class' statement). The
statement must be a bare string literal, not any other kind of
expression. The docstring for the code object is available on that
code object's '__doc__' attribute.
[…]
<URL:https://en.wikipedia.org/wiki/Docstring#Python>
--
\ “True greatness is measured by how much freedom you give to |
`\ others, not by how much you can coerce others to do what you |
_o__) want.” —Larry Wall |
Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-27 18:50 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f790e5$0$1603$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105759 |
On Sun, 27 Mar 2016 01:30 am, 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.
Right. And with the exception of the first, all of them could call arbitrary
code (a property, __getattr__, __getitem__, etc.) and hence could have
side-effects.
But the first one is special. It can only do two things: evaluate a name,
then silently throw the result away, or raise NameError.
Bart's point is that Python *could* (and arguably should) define the first
one, a bare name, as a SyntaxError. If you want to test for the existence
of a name, you would have to write something like (let's say):
ifundef raw_input:
raw_input = input
One might argue that according to the Zen, this is more Pythonic than the
status quo of a try...except. It's an explicit test of whether a name is
undefined, and it avoids at least some silent errors (where an expression
with no side-effects is evaluated, and the result silently thrown away).
We could argue the pros and cons of the two approaches, or even a more
radical approach like Javascripts where names evaluate as undef if they
haven't been defined yet. But one thing is certain: there is a class of
error which only occurs because it is legal to evaluate a bare name and do
nothing with the result.
> 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.
I think you have badly misunderstood the nature of the problem.
My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
function:
void foo(int n) {
int i = n + 1;
bar(i);
}
There's a possible overflow of a signed int in there. This is undefined
behaviour. Now, you might think to yourself:
"Well, that's okay. So long as n is not equal to MAXINT, the overflow will
never occur, which means the undefined behaviour will never occur, which
means that bar will be called with (n+1) as argument. So foo is safe, so
long as n is smaller than MAXINT in practice."
And then go on to write something like:
# my C is getting rustier by the second, sorry
int n = read_from_instrument();
foo(n);
secure in the knowledge that your external hardware instrument generates
values 0 to 1000 and will never go near MAXINT. But the C compiler doesn't
know that, so it has to assume that n can be any int, including MAXINT.
Consequently your foo is "meaningless" and your code can legally be
replaced by:
int n = read_from_instrument();
erase_hard_drive();
regardless of the actual value of n. Taken in isolation, of course this is
absurd, and no compiler would actually do that. But in the context of an
entire application, it is very difficult to predict what optimizations the
compiler will take, what code will be eliminated, what code will be
reordered, and the nett result is that hard drives may be erased, life
support systems could be turned off, safety systems can be disabled,
passwords may be exposed, arbitrary code may be run.
I'm sure that there are ways of guarding against this. There are compiler
directives that you can use to tell the compiler not to optimize the call
to foo, or command line switches to give warnings, or you might be able to
guard against this:
int n = read_from_instrument();
if n < MAXINT {
foo(n);
}
But even the Linux kernel devs have been bitten by this sort of thing. With
all the warnings and linters and code checkers and multiple reviews by
experts, people get bitten by undefined behaviour.
What you can't do is say "foo is safe unless n actually equals MAXINT".
That's wrong. foo is unsafe if the C compiler is unable to determine at
compile-time whether or not n could ever, under any circumstances, be
MAXINT. If n might conceivably ever be MAXINT, then the behaviour of foo is
undefined. Not implementation-specific, or undocumented. Undefined, in the
special C meaning of the term.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2016-03-27 10:51 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.75.1459072282.28225.python-list@python.org> |
| In reply to | #105826 |
On 27 Mar 2016 10:56, "Steven D'Aprano" <steve@pearwood.info> wrote:
>
>
> My C is a bit rusty, so excuse me if I get the syntax wrong. I have a
> function:
>
> void foo(int n) {
> int i = n + 1;
> bar(i);
> }
>
> There's a possible overflow of a signed int in there. This is undefined
> behaviour. Now, you might think to yourself:
>
> "Well, that's okay. So long as n is not equal to MAXINT, the overflow will
> never occur, which means the undefined behaviour will never occur, which
> means that bar will be called with (n+1) as argument. So foo is safe, so
> long as n is smaller than MAXINT in practice."
>
> And then go on to write something like:
>
> # my C is getting rustier by the second, sorry
> int n = read_from_instrument();
> foo(n);
>
>
> secure in the knowledge that your external hardware instrument generates
> values 0 to 1000 and will never go near MAXINT. But the C compiler doesn't
> know that, so it has to assume that n can be any int, including MAXINT.
> Consequently your foo is "meaningless" and your code can legally be
> replaced by:
>
> int n = read_from_instrument();
> erase_hard_drive();
This is incorrect. Provided n does not take the value INT_MAX the code is
conforming and the standard mandates how it should behave. The compiler is
allowed to make optimisations that assume n never takes that value such
that in the circumstances where n *would* take that value any behaviour is
acceptable. The compiler is not free to say "I don't know if it would take
that value so I'm unconstrained even if it does not".
>
> regardless of the actual value of n. Taken in isolation, of course this is
> absurd, and no compiler would actually do that. But in the context of an
> entire application, it is very difficult to predict what optimizations the
> compiler will take, what code will be eliminated, what code will be
> reordered, and the nett result is that hard drives may be erased, life
> support systems could be turned off, safety systems can be disabled,
> passwords may be exposed, arbitrary code may be run.
>
> I'm sure that there are ways of guarding against this. There are compiler
> directives that you can use to tell the compiler not to optimize the call
> to foo, or command line switches to give warnings, or you might be able to
> guard against this:
>
> int n = read_from_instrument();
> if n < MAXINT {
> foo(n);
> }
This is correct. It is now impossible for the addition n+1 to overflow
since we cannot hit that code if n is INT_MAX.
> But even the Linux kernel devs have been bitten by this sort of thing.
With
> all the warnings and linters and code checkers and multiple reviews by
> experts, people get bitten by undefined behaviour.
I think you're overegging this a bit. Many experienced programmers get
bitten by bugs while working in many languages. C is more troublesome than
many and there is room for improvement but it's not as dramatic as you
suggest.
> What you can't do is say "foo is safe unless n actually equals MAXINT".
> That's wrong. foo is unsafe if the C compiler is unable to determine at
> compile-time whether or not n could ever, under any circumstances, be
> MAXINT. If n might conceivably ever be MAXINT, then the behaviour of foo
is
> undefined. Not implementation-specific, or undocumented. Undefined, in the
> special C meaning of the term.
I think you've misunderstood this: signed addition that would not overflow
is well defined so the optimiser cannot alter the semantics in that case.
It is free to assume that values that would overflow will not occur and
alter execution in surprising ways but that's not the same as rewriting
valid code on the assumption that an invalid value cannot be proven not to
occur. Rather the onus is on the optimiser to prove that the optimised code
is equivalent for all inputs where behaviour is defined.
--
Oscar
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-03-26 23:13 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87twjs5tz2.fsf@nightsong.com> |
| In reply to | #105754 |
Steven D'Aprano <steve@pearwood.info> writes: > For example, would you consider that this isolated C code is > "meaningless"? > int i = n + 1; It's meaningful as long as n is in a certain range of values so there's no overflow. > But according to the standard, it's "meaningless", since it might > overflow, and signed int overflow is Undefined Behaviour. No it's not meaningless if it "might" overflow, it's meaningless if it -does- overflow, so the compiler can do whatever it wants in that case. The compiler is only obliged to do anything specific in the case where there is no overflow, so if it can get some speedups by only generating code for the non-overflow case, it does so: http://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html > 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. They do what you tell them, not what you meant to tell them or what you thought you were telling them. That goes way back before compilers and computers. Think of all the stories about a guy rubbing lamps and getting three wishes. Srsly though, the conclusion is that C and C++ are terrible languages if you want to code anything really solid, not that the compilers are doing anything bad. Unfortunately there's a mountain of legacy code full of such errors, and still a lot of C programmers out there who don't understand the issue.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-27 18:40 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f78e74$0$1616$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105818 |
On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote: > Steven D'Aprano <steve@pearwood.info> writes: >> For example, would you consider that this isolated C code is >> "meaningless"? >> int i = n + 1; > > It's meaningful as long as n is in a certain range of values so there's > no overflow. > >> But according to the standard, it's "meaningless", since it might >> overflow, and signed int overflow is Undefined Behaviour. > > No it's not meaningless if it "might" overflow, it's meaningless if it > -does- overflow, No! That's exactly wrong! Paul, thank you for inadvertently proving the point I am trying to get across. People, even experienced C coders, simply don't understand what the C standard says and what C compilers can and will do. If the C compiler cannot prove that n is strictly less than MAXINT (or is that spelled INT_MAX?), the *entire program* (or at least the bits reachable from this line, in both directions) is Undefined, and the compiler has no obligations at all. You probably don't believe me because this sounds crazy, something that no sane person would design a programming language to behave. Well, yeah, exactly. It does allow C a lot of powerful optimizations, but only at the cost of making it impossible to reason about the behaviour of code that is Undefined. No real compiler is going to intentionally erase your hard disk, but in non-toy code, it can introduce serious bugs even though you explicitly wrote code to avoid the buggy case. But don't believe me. What do I know about C, I don't even know whether to spell the biggest int MAXINT or INT_MAX or MAX_INT. Instead, believe these guys: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/226 http://blog.regehr.org/archives/232 http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/ https://randomascii.wordpress.com/2014/05/19/undefined-behavior-can-format-your-drive/ I've emphasised all the bad things that undefined behaviour causes, but the above (written by C programmers who presumably like C) are much more even-handed, describing the good things that compilers can get out of this. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-03-27 00:52 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <ceb0b70f-db21-4383-870c-10ae475ba304@googlegroups.com> |
| In reply to | #105825 |
On Sunday, March 27, 2016 at 1:10:51 PM UTC+5:30, Steven D'Aprano wrote: > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote: > > > No it's not meaningless if it "might" overflow, it's meaningless if it > > -does- overflow, > > No! That's exactly wrong! > > Paul, thank you for inadvertently proving the point I am trying to get > across. People, even experienced C coders, simply don't understand what the > C standard says and what C compilers can and will do. Yeah this misunderstanding is a deep one People find it hard to get the halting problem: for(;;) ; is an infinite loop. Whats the big deal? Why is it 'impossible' to detect? Its hard because we have to reason all possible inputs (and for language implementations, all possible programs) when these are yet unavailable unwritten JFTR I am not remotely arguing that C is not dangerous. http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html It was bad in 1991 and has probably got worse with a totally networked world of nameless hoods. I am just saying no-C is no-option [Considering the day it is you may wish to consider prayer :-) ]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-03-27 21:06 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87zitj1yae.fsf@bsb.me.uk> |
| In reply to | #105825 |
Steven D'Aprano <steve@pearwood.info> writes:
> On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>>> For example, would you consider that this isolated C code is
>>> "meaningless"?
>>> int i = n + 1;
>>
>> It's meaningful as long as n is in a certain range of values so there's
>> no overflow.
>>
>>> But according to the standard, it's "meaningless", since it might
>>> overflow, and signed int overflow is Undefined Behaviour.
>>
>> No it's not meaningless if it "might" overflow, it's meaningless if it
>> -does- overflow,
>
> No! That's exactly wrong!
>
> Paul, thank you for inadvertently proving the point I am trying to get
> across. People, even experienced C coders, simply don't understand what the
> C standard says and what C compilers can and will do.
>
> If the C compiler cannot prove that n is strictly less than MAXINT (or is
> that spelled INT_MAX?),
(the latter)
> the *entire program* (or at least the bits reachable from this line,
> in both directions) is Undefined, and the compiler has no obligations
> at all.
If I understand you correctly, you are claiming that in this program
#include <stdio.h>
int main(int argc, char **argv)
{
int n = argc > 1 ? atoi(argv[1]) : 0;
int i = n + 1; // not needed but used because it's the line in question
printf("Hello world\n");
}
everything after "int i = n + 1;" is undefined because the compiler
can't prove that n is strictly less than INT_MAX. (In fact atoi
exhibits undefined behaviour in some cases which the compiler can't
prove don't apply here either, so the trouble could happen even
earlier.)
Given that the only observable behaviour is the printf call, would the
fact that the program is undefined by that point mean that a compiler
could generate code equivalent to
#include <stdio.h>
int main(void) { puts("You loose!\n"); }
and still be conforming according to the language standard? (Obviously
this is a rather mild option given that anything is permitted.) That
*seems* to be what you are saying, but it's not backed up by what the C
people I know say. In particular
<snip>
> But don't believe me. What do I know about C, I don't even know whether to
> spell the biggest int MAXINT or INT_MAX or MAX_INT. Instead, believe these
> guys:
>
> http://blog.regehr.org/archives/213
> http://blog.regehr.org/archives/226
> http://blog.regehr.org/archives/232
>
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html
don't seem to be saying that. Whilst I've not yet read them all, they
seem be unexceptional explanations of UB in C (by which I mean they
accord with what I understand it to be!) and I don't see how they
confirm what I think you are saying.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2016-03-27 22:16 +0100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.95.1459113409.28225.python-list@python.org> |
| In reply to | #105870 |
On 27 Mar 2016 23:11, "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote:
>
> Steven D'Aprano <steve@pearwood.info> writes:
>
> > On Sun, 27 Mar 2016 05:13 pm, Paul Rubin wrote:
> >
> >> Steven D'Aprano <steve@pearwood.info> writes:
> >>> For example, would you consider that this isolated C code is
> >>> "meaningless"?
> >>> int i = n + 1;
> >>
> >> It's meaningful as long as n is in a certain range of values so there's
> >> no overflow.
> >>
> >>> But according to the standard, it's "meaningless", since it might
> >>> overflow, and signed int overflow is Undefined Behaviour.
> >>
> >> No it's not meaningless if it "might" overflow, it's meaningless if it
> >> -does- overflow,
> >
> > No! That's exactly wrong!
> >
> > Paul, thank you for inadvertently proving the point I am trying to get
> > across. People, even experienced C coders, simply don't understand what
the
> > C standard says and what C compilers can and will do.
> >
> > If the C compiler cannot prove that n is strictly less than MAXINT (or
is
> > that spelled INT_MAX?),
>
> (the latter)
>
> > the *entire program* (or at least the bits reachable from this line,
> > in both directions) is Undefined, and the compiler has no obligations
> > at all.
>
> If I understand you correctly, you are claiming that in this program
>
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> int n = argc > 1 ? atoi(argv[1]) : 0;
> int i = n + 1; // not needed but used because it's the line in
question
> printf("Hello world\n");
> }
>
> everything after "int i = n + 1;" is undefined because the compiler
> can't prove that n is strictly less than INT_MAX.
Although Steve is incorrect to say that everything is undefined just
because the compiler can't prove that n != INT_MAX one thing that he is
right about is that undefined behaviour applies to the whole program. So if
the n+1 does lead to undefined behaviour (i.e. if n == INT_MAX) then the
behaviour is also undefined *before* that line. If we change the line to
INT_MAX+1 then a compiler is free to do whatever it likes with the *entire*
program.
In practice what this means is that an optimising compiler can see n+1 and
then optimise using the assumption that n!=INT_MAX (since there are *zero*
constraints on the behaviour of the *entire* program if that assumption is
broken). This optimisation could for example remove an if(n==INT_MAX) block
as dead code even if the check occurs *before* the line that involves n+1
which can be surprising. Of course if the check is used to conditionally
execute n+1 then the assumption cannot be applied by the optimiser so it's
still entirely possible to avoid this particular undefined behaviour.
--
Oscar
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-03-26 10:37 +0200 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <87d1qh1voc.fsf@elektro.pacujo.net> |
| In reply to | #105720 |
Steven D'Aprano <steve@pearwood.info>:
> On Sat, 26 Mar 2016 03:57 am, Marko Rauhamaa wrote:
>> Yes, although the same could be true for Python as well.
>
> Is this a philosophical question? Yes, it *could* be true, in some
> alternate universe, but it isn't actually true.
>
> Python does not have undefined behaviour in the C sense. [...]
>> For example, you could have this program:
>>
>> ===begin poof.py========================================================
>> assert 1 < 0
>> ===end poof.py==========================================================
>
> The semantics of "assert condition" are equivalent to:
>
> if __debug__:
> if not condition:
> raise AssertionError
>
> so assert is intentionally a no-op when Python runs with debug mode disabled
> (the -O command-line switch).
Thing is, some aggressive JITters might make extensive optimization
decisions based on assertions. An assertion is a developers declaration
of certain knowledge. It is there mainly to document design principles
to fellow developers (including the original coder), but since the
assertions have a formal content, the VM could allow itself to rely on
them.
For example,
def g(n):
assert type(n) is int
assert 0 <= n < 256
return (n + 1) % 256
def f(n):
return g(n)**2
The optimizer can optimize f() *knowing* its argument is an unsigned
byte.
Essentially, the JIT would boldly decide that AssertionError is never
raised.
(Although I would hate seeing such assertions routinely sprinkled
everywhere.)
> Anything else would be a bug in the interpreter or compiler.
We'll see what the JITters cook up.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-26 08:23 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <mailman.12.1458941031.28225.python-list@python.org> |
| In reply to | #105692 |
On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Fri, 25 Mar 2016 06:54 am, BartC wrote:
>
>>> In the case of C, the line is limited to working with some specific type
>>> (say, an int32). Even there, if the addition might overflow, the
>>> behaviour is undefined and the compiler can do anything it wants
>>> (including time travel,
>>
>> I'm pretty sure it can't do time travel...
>>
>> or erasing your hard disk).
>
>
> You are absolutely, and potentially catastrophically, mistaken on that.
>
> Undefined behaviour does not mean "implementation specific behaviour". Nor
> does it mean "something sensible will happen but we don't promise what it
> will be". It means "the compiler can do anything", including ignoring the
> code you actually wrote and substituting its own faster code, which may or
> may not do what your original code did.
C's undefined behaviour is basically "you're not allowed to do this".
The compiler is free to assume that you will never do this, ergo it is
free to write out machine code that is correct only so long as you do
not do this. Let me draw a Python analogy:
1) A well-behaved iterator will return values until it raises
StopIteration, and then raise StopIteration thereafter.
2) An iterator which raises and then returns is thus badly written and
should not exist.
3) A consumer of an iterator is allowed to misbehave in the event that
the iterator returns after raising.
4) Therefore an optimizer is free to *cause* the consumer to misbehave
when given an ill-behaved iterator.
Consider this code:
def zip_forever(*iters, fillvalue=None):
"""Like zip_longest, but without the silly rule that
it should terminate once they all finish"""
while True:
yield tuple(next(it, fillvalue) for it in iters)
If all its iterators are well-behaved, this is identical (modulo
monkey-patching of names like "tuple" and "next") to:
def zip_forever(*iters, fillvalue=None):
yield from zip_longest(*iters, fillvalue=fillvalue)
tup = (None,) * len(iters)
while True: yield tup
Is PyPy/FAT Python/some other optimizer permitted to make this change?
The only difference between C's "undefined behaviour" and Python's way
of doing the spec is the answer to that one question. C says yes,
you're totally allowed to assume that; the end result in all cases
should be indistinguishable; any time you can detect that it optimized
this away, it's because of a bug somewhere else. Is your code allowed
to misbehave when other code has bugs? That, ultimately, is the
question.
Imagine a tightened up subset of the Python language that restricts
certain unusual behaviours. (This has the same purpose as PyPy's
RPython, and for all I know, RPython might do exactly this.) It's a
narrowly-used single purpose language, and its sole guarantee is that
well-written SubPython code will behave the same way in SubPython as
it does in CPython. It might then, for instance, not permit rebinding
of builtins, nor of function default argument replacements, without an
explicit "drop_caches()" call. Code could then be far more
aggressively optimized - but behaviour would become undefined in the
event that you break one of its rules. That's really all that C's
done, and you honestly don't have to get so panicky at the word
"undefined". It's simply "don't do this".
And let's face it... there's a *lot* of undefined behaviour in CPython
once you play with ctypes. Do we have any language guarantees as to
what will happen if you change the value of the integer 7 to now be 8?
Or will you just say "don't do that"?
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-27 18:13 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f7881b$0$1604$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105708 |
On Sat, 26 Mar 2016 08:23 am, Chris Angelico wrote:
> On Sat, Mar 26, 2016 at 2:50 AM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Undefined behaviour does not mean "implementation specific behaviour".
>> Nor does it mean "something sensible will happen but we don't promise
>> what it will be". It means "the compiler can do anything", including
>> ignoring the code you actually wrote and substituting its own faster
>> code, which may or may not do what your original code did.
>
> C's undefined behaviour is basically "you're not allowed to do this".
> The compiler is free to assume that you will never do this, ergo it is
> free to write out machine code that is correct only so long as you do
> not do this.
Yes, but it's worse than that. The compiler can write out that machine code
*even if you do, in fact, do what it assumes you don't do*. Am I the only
one that thinks that's rather perverse? Probably not, since most
programming languages are safer than C. You don't get this sort of thing
happening even in other low-level languages like Forth. And there is a lot
of work actively trying to build systems languages that are safer than C,
e.g. D and Rust.
> Let me draw a Python analogy:
>
> 1) A well-behaved iterator will return values until it raises
> StopIteration, and then raise StopIteration thereafter.
> 2) An iterator which raises and then returns is thus badly written and
> should not exist.
The first part of this is correct: iterators which raise StopIterator, and
then later yield values, are indeed *officially* known as "broken". Here is
a broken iterator:
class Broken:
def __init__(self):
self.x = 0
def __iter__(self):
return self
def __next__(self):
self.x += 1
if self.x < 6:
return self.x
if self.x % 2:
return "NOBODY expects the Spanish Inquisition!"
raise StopIteration
I once asked Guido if "broken" iterators should be considered illegal, or an
error, and if I remember correctly (I'm pretty sure I do, but don't ask me
for a link) he said that they're legal, but you shouldn't write them. If
you want to shoot yourself in the foot with a broken iterator, you can.
So broken iterators (what you call ill-behaved) are not forbidden. They're
just discouraged.
For example, if you create an iterator with a "restart" method, that's
officially broken. But I don't believe anyone would agree that people
should be prohibited from creating a custom iterator that can be restarted.
That sort of heavy-handed prescriptivist approach goes against the
"consenting adults" philosophy of Python.
> 3) A consumer of an iterator is allowed to misbehave in the event that
> the iterator returns after raising.
Define "misbehave". I think that's the crux of the matter. It's not just
Undefined Behaviour *alone* that is so problematic, but that it is linked
to a culture of aggressive optimization that is prepared to radically
change the semantics of code as compared to what the C abstract machine
would do.
The iterator protocol is defined such that once an iterator raises, it
should continue to raise forever. If you violate that, you're not following
the iterator protocol precisely. That's okay, nobody says you have to. But
if you don't, you can't complain if code behaves strangely.
A similar situation occurs with reflexivity of equality. Python built-ins
are allowed to assume that x == x is always true, and optimize equality
checks as
if a is b:
# fast path
return True
else:
# slow path
That's great, unless you have NANs or other "weird" objects that violate the
assumption that an object is always equal to itself.
It's not just built-ins: any class or function is allowed to make the same
assumption. In that case, ideally the class or function should document the
fact that it assumes reflexivity, but that's a "quality of implementation"
detail, and we all know that most coders are crap at documentation.
> 4) Therefore an optimizer is free to *cause* the consumer to misbehave
> when given an ill-behaved iterator.
Unlike C, Python has no official IEC standard where the definitive answer to
this (implied) question is written down. We can't look up in the standard
to see what Python implementations can do, but we can try to channel Guido
and the core developers and guess their attitude based on their public
behaviour and the behaviour of the Python reference implementation,
CPython.
I don't believe that Guido or the core developers would take that position.
I expect that they would call that a bug in the optimizer. For example,
here's that broken iterator in action:
py> x = Broken()
py> list(x)
[1, 2, 3, 4, 5]
py> list(x)
['NOBODY expects the Spanish Inquisition!']
py> list(x)
['NOBODY expects the Spanish Inquisition!']
py> list(x)
['NOBODY expects the Spanish Inquisition!']
So the reference implementation shows clearly that broken iterators are
allowed. Until such time as Guido changes his mind, an optimizer that
changed this would be officially(?) buggy.
My guess is that Guido might accept an optimizer that changed the behaviour
is this way, provided it explicitly documented that it was doing so. But
possibly not: Guido doesn't seem to care much for optimizers, especially
not "clever" ones, and my reading of his attitude is that he somewhat
grudgingly accepts them only if they don't change the semantics of Python
code. It's hard to tell which he would dislike more: broken iterators, or
an optimizer that changed semantics of Python. My money is the second one.
(Guido's even expressed disdain for simple keyhole optimizers that perform
constant folding.)
I'm pretty sure Guido wouldn't allow a general carte blanche for Python
compilers to radically change the semantics of code in the name of
optimization. So optimizing "x = 1 + 1" to "x = 2" is okay, but:
x = Broken()
list(x)
value = next(x)
print("x is technically broken")
should not be optimized to:
os.system("rm -rf /")
no matter how much faster it is. *wink*
(In practice, I would expect a C compiler to probably decide that the code I
showed was dead code, and throw it all away. But there's no guarantee, and
the complexity and aggressiveness of the optimizer is such that it is very
difficult to predict what will actually happen.)
> Consider this code:
>
> def zip_forever(*iters, fillvalue=None):
> """Like zip_longest, but without the silly rule that
> it should terminate once they all finish"""
> while True:
> yield tuple(next(it, fillvalue) for it in iters)
>
> If all its iterators are well-behaved, this is identical (modulo
> monkey-patching of names like "tuple" and "next") to:
>
> def zip_forever(*iters, fillvalue=None):
> yield from zip_longest(*iters, fillvalue=fillvalue)
> tup = (None,) * len(iters)
> while True: yield tup
>
> Is PyPy/FAT Python/some other optimizer permitted to make this change?
It's free software, they can make that change if they like. Consenting
adults, don'cha know? But then they have to deal with the bug reports when
they break people's code.
> The only difference between C's "undefined behaviour" and Python's way
> of doing the spec is the answer to that one question. C says yes,
> you're totally allowed to assume that; the end result in all cases
> should be indistinguishable; any time you can detect that it optimized
> this away, it's because of a bug somewhere else. Is your code allowed
> to misbehave when other code has bugs? That, ultimately, is the
> question.
No, that's not the difference at all. I'm afraid you have not understood
just how radical the C "Undefined Behaviour" standard is, at least in
principle (and often in practice as well).
> Imagine a tightened up subset of the Python language that restricts
> certain unusual behaviours. (This has the same purpose as PyPy's
> RPython, and for all I know, RPython might do exactly this.) It's a
> narrowly-used single purpose language, and its sole guarantee is that
> well-written SubPython code will behave the same way in SubPython as
> it does in CPython. It might then, for instance, not permit rebinding
> of builtins, nor of function default argument replacements, without an
> explicit "drop_caches()" call. Code could then be far more
> aggressively optimized - but behaviour would become undefined in the
> event that you break one of its rules. That's really all that C's
> done, and you honestly don't have to get so panicky at the word
> "undefined". It's simply "don't do this".
No. It really isn't. Please read the links I provided. All of them.
> And let's face it... there's a *lot* of undefined behaviour in CPython
> once you play with ctypes. Do we have any language guarantees as to
> what will happen if you change the value of the integer 7 to now be 8?
> Or will you just say "don't do that"?
No, that's not what undefined behaviour means in C. It really does not
mean "implementation specific". It is separate and distinct from
implementation-defined behaviour. The actual number of bits in a byte is
implementation-defined. Almost all C compilers will use 8 bits, but the
standard only says it must be *at least* 8 bits.
As John Regehr writes:
"For now, we can ignore the existence of compilers. There is only the “C
implementation” which — if the implementation conforms to the C standard —
acts the same as the “C abstract machine” when executing a conforming
program. The C abstract machine is a simple interpreter for C that is
described in the C standard. We can use it to determine the meaning of any
C program."
http://blog.regehr.org/archives/213
(This C abstract machine is what I described earlier as a naive,
simple-minded, non-optimizing C compiler, what Raymond Chen calls
a "classical compiler". Abstract machine is a much better term than what I
used.)
Regehr goes on:
"Note that even well-defined executions may not have a unique result due to
unspecified and implementation-defined behavior; we’ll ignore both of these
here."
So *undefined behaviour* is not the same as unspecified and
implementation-defined behaviour. That's important.
What any specific compiler *actually* does is implementation-defined, and in
practice, C compilers do not make any backwards-compatibility promises. One
compiler might quietly and safely treat integer overflow using wrap-around
arithmetic for release after release, and then suddenly without any fanfare
erase your hard drive.
Regehr again:
"If any step in a program’s execution has undefined behavior, then THE
ENTIRE EXECUTION IS WITHOUT MEANING. This is important: it’s not that
evaluating (1<<32) has an unpredictable result, but rather that the ENTIRE
EXECUTION of a program that evaluates this expression is meaningless. Also,
it’s not that the execution is meaningful up to the point where undefined
behavior happens: the bad effects can actually precede the undefined
operation."
[Emphasis added.]
In Python terms, suppose we have this:
arr = [1, 2, 3]
for i in range(4):
print(arr[i])
# and more code following...
The Python virtual machine says that execution should proceed up to the
point where the loop prints 3, and then raise IndexError, then halt (if the
exception is not caught). The error message given by the IndexError is
implementation-specific.
But the C virtual machine says that *entire* program (translated into C
syntax, obviously) is gibberish, and the compiler can replace the entire
program, or any part it likes, with anything it likes. There's no
requirement that any specific error occurs, or even that an error occurs.
No real C compiler is intentionally going to replace those three lines
(translated into C, of course) with a call to erase the hard drive. But the
optimizations being applied by real C compilers are sufficiently complex
and aggressive that this is something which may occur inadvertently.
Here is somebody on Stackoverflow who claims it happened to him:
http://stackoverflow.com/a/18506556
and specifically note his later comment:
"Oh, explicitly creating the command would have involved only well-defined
behavior. The actual bug was UB, and the question was how UB could lead to
the deletion of a harddisk. Well, like this: a variable gets corrupted, in
this case a path variable, and other bug-free code now starts behaving in
unexpected ways. That's a general problem with UB: it breaks strong
assumptions about OTHER code."
[Emphasis added.]
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-03-25 22:30 -0700 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <ed0ba3df-5a82-48b1-bf70-90945f37e52d@googlegroups.com> |
| In reply to | #105692 |
On Friday, March 25, 2016 at 9:20:23 PM UTC+5:30, Steven D'Aprano wrote: > > Undefined behaviour in C is a minefield waiting to blow your program's legs > off, because the designers of the language made the explicit choice that > they wanted the language to be as fast and efficient as possible, even at > the cost of safe, reproducible behaviour. Thats a nice polemic Steven Ive been guilty of similar... which Ive subsequently tried to correct: http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html For one thing its good to remember that we wouldn't be here without python Python wouldn't be what it is without CPython And the C there is the C you are talking of. More pertinently this polemic misses the real culprit -- intel hardware. 40 years ago Dijkstra pointed out that software costs are variable; hardware costs are fixed. this results in this that programmers will increasingly skip a test that is very skew. If that same super-skew test were taken care of by hardware we (programmers) wouldn't mind. [1] To see this consider overflow error for integers and for floats. Intel hardware catches float errors in hardware but not int errors So language designers have the hobson choice of catching errors at huge cost Or ignoring and (inviting programmers to ) creating flaky systems. [1] Economics/financial considerations drive more than we imagine https://www.facebook.com/EvolvePolitics/videos/1666350230283584/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-26 21:39 +1100 |
| Subject | Re: Undefined behaviour in C [was Re: The Cost of Dynamism] |
| Message-ID | <56f666d8$0$1583$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105729 |
On Sat, 26 Mar 2016 04:30 pm, Rustom Mody wrote: > For one thing its good to remember that we wouldn't be here without python > Python wouldn't be what it is without CPython There is nothing about Python that relies on the C standard being as it is. There are Python implementations that are not written in C or C++: Jython (Java) IronPython (C# for .Net or Mono) CLPython (Lisp) Berp (Haskell) I haven't included others (such as PyPy), as I'm not sure whether the language they are implemented in are self-hosting or not.and But those four at least (in principle) don't rely on C/C++ in any way, shape or form (except perhaps inspiration). It is an accident of history that Python's first and major implementation happens to be written in C. (Although its use as a glue language, allowing people to safely use libraries written in C, probably played a role in ensuring Python's success.) -- Steven
[toc] | [prev] | [next] | [standalone]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web