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 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-22 11:05 +0000 |
| Message-ID | <ncr8n3$625$1@dont-email.me> |
| In reply to | #105430 |
On 22/03/2016 01:01, Steven D'Aprano wrote:
> On Tue, 22 Mar 2016 06:43 am, BartC wrote:
>
>> This code was adapted from a program that used:
>>
>> readstrfile(filename)
>>
>> which either returned the contents of the file as a string, or 0.
>
> What an interesting function. And I don't mean that in a good way.
>
> So if it returns 0, how do you know what the problem is? Mistyped file name?
> Permission denied? File doesn't actually exist? Disk corruption and you
> can't open the file? Some weird OS problem where you can't *close* the
> file? (That can actually happen, although it's never happened to me.) How
> do you debug any problems, given only "0" as a result?
>
> What happens if you read (let's say) a 20GB Blue-Ray disk image?
I think you're making far too much of a throwaway function to grab a
file off disk and into memory.
But out of interest, how would /you/ write a function that takes a
file-spec and turns it into an in-memory string? And what would its use
look like?
> Pythonic code probably uses a lot of iterables:
>
> for value in something:
> ...
> in preference to Pascal code written in Python:
>
> for index in range(len(something)):
> value = something[index]
(Suppose you need both the value and its index in the loop? Then the
one-line for above won't work. For example, 'something' is [10,20,30]
and you want to print:
0: 10
1: 20
2: 30 )
> ...
> or worse:
>
> index = 0
> while index < len(something):
> value = something[index]
> ...
> index += 1
> (I don't know where that while-loop idiom comes from. C? Assembly? Penitent
> monks living in hair shirts in the desert and flogging themselves with
> chains every single night to mortify the accursed flesh? But I'm seeing it
> a lot in code written by beginners. I presume somebody, or some book, is
> teaching it to them. "Learn Python The Hard Way" perhaps?)
Are you suggesting 'while' is not needed? Not everything fits into a
for-loop you know! Why, take my own readtoken() function:
symbol = anything_other_than_skip_sym
while symbol != skip_sym:
symbol = readnextsymbol()
Of course, a repeat-until or repeat-while would suit this better (but I
don't know how it fits into Python syntax). So there's a case here for
increasing the number of loop statements not reducing them.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-22 22:15 +1100 |
| Message-ID | <mailman.1.1458645343.2244.python-list@python.org> |
| In reply to | #105459 |
On Tue, Mar 22, 2016 at 10:05 PM, BartC <bc@freeuk.com> wrote:
> But out of interest, how would /you/ write a function that takes a file-spec
> and turns it into an in-memory string? And what would its use look like?
def read_file(fn, *a, **kw):
with open(fn, *a, **kw) as f:
return f.read()
Usage:
script = read_file(".bashrc")
data = read_file("Ellalune_AlicePortrait.jpg", "rb")
decoded = read_file("greek.srt", encoding="ISO-8859-7")
If there's any problem with reading the file, an exception will be
raised. Also, thanks to the 'with' block, I'm guaranteed that the file
will have been closed before read_file() returns, which means I can
immediately go and write to the file without a conflict.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-22 12:59 +0000 |
| Message-ID | <ncrfdg$um7$1@dont-email.me> |
| In reply to | #105461 |
On 22/03/2016 11:15, Chris Angelico wrote:
> On Tue, Mar 22, 2016 at 10:05 PM, BartC <bc@freeuk.com> wrote:
>> But out of interest, how would /you/ write a function that takes a file-spec
>> and turns it into an in-memory string? And what would its use look like?
>
> def read_file(fn, *a, **kw):
> with open(fn, *a, **kw) as f:
> return f.read()
>
> Usage:
>
> script = read_file(".bashrc")
> data = read_file("Ellalune_AlicePortrait.jpg", "rb")
> decoded = read_file("greek.srt", encoding="ISO-8859-7")
>
> If there's any problem with reading the file, an exception will be
> raised. Also, thanks to the 'with' block, I'm guaranteed that the file
> will have been closed before read_file() returns, which means I can
> immediately go and write to the file without a conflict.
I'm not sure I follow. Your solution to dealing with the scenarios
raised by Steven D'Aprano is to:
(1) Not bother with exceptions at all inside the function
(2) Not bother with them in the user code either
(3) Let any errors just crash out (raise a Python system error) (just
like I did in my original jpeg program which I was called out on)
(4) Or if the user code does want to check for certain errors (like,
File Not Found, by far the most likely, and so that it can deal with
that and continue executing), it now has to go and dig out docs for ...
what? The user code needs to know what is going on inside the supposedly
opaque function it's calling.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 00:13 +1100 |
| Message-ID | <mailman.9.1458652430.2244.python-list@python.org> |
| In reply to | #105476 |
On Tue, Mar 22, 2016 at 11:59 PM, BartC <bc@freeuk.com> wrote: > (1) Not bother with exceptions at all inside the function > > (2) Not bother with them in the user code either > > (3) Let any errors just crash out (raise a Python system error) (just like I > did in my original jpeg program which I was called out on) > > (4) Or if the user code does want to check for certain errors (like, File > Not Found, by far the most likely, and so that it can deal with that and > continue executing), it now has to go and dig out docs for ... what? The > user code needs to know what is going on inside the supposedly opaque > function it's calling. Yes, yes, at first, and try it. The first step in any program is to write it in the very simplest way possible. That usually means ignoring all error handling. And yes, this is true in EVERY language - C, PHP, Pike, DeScribe Macro Language, you name it. Then you try it, and you find one of two things: 1) The code you've written is encountering error conditions that it can't handle, and has to pass upstream; or 2) The code you've written is getting passed error conditions that it knows how to deal with. The first one is a time to raise an exception. The second is a time to catch one. And since, by default, Python prints those exceptions to the console, you should [1] have all the information you need to catch the ones you understand, because you've seen them in testing. Note, though, that "deal with" really means "deal with", and NOT "print oops to the console and terminate". If all you're going to do with an exception is print and terminate, *let it go*, unless it's a user-triggered failure, in which case you catch it right at the very highest level, and basically fall off the end of your program. The number of times you have sys.exit() in an except clause should be vanishingly small. ChrisA [1] Some libraries force you to dig around a bit to figure out how you're supposed to import those exception classes. But that's usually *one* thing to look up in the docs - "oh, so I import foobarbletch.exceptions.OutOfBeerException".
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-03-22 13:46 +0000 |
| Message-ID | <slrnnf2jcd.19u.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #105479 |
On 2016-03-22, Chris Angelico <rosuav@gmail.com> wrote: > The first step in any program is to write it in the very simplest way > possible. That usually means ignoring all error handling. And yes, > this is true in EVERY language - C, PHP, Pike, DeScribe Macro > Language, you name it. I'm afraid I have to say I think this is absolutely terrible advice. If you write code in a language that does not have exceptions (e.g. C) and get it working with no error handling, the chances are approximately 100% that it will stay that way and be shipped without error handling, until that lack causes someone a major problem.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 01:02 +1100 |
| Message-ID | <mailman.14.1458655351.2244.python-list@python.org> |
| In reply to | #105487 |
On Wed, Mar 23, 2016 at 12:46 AM, Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote: > On 2016-03-22, Chris Angelico <rosuav@gmail.com> wrote: >> The first step in any program is to write it in the very simplest way >> possible. That usually means ignoring all error handling. And yes, >> this is true in EVERY language - C, PHP, Pike, DeScribe Macro >> Language, you name it. > > I'm afraid I have to say I think this is absolutely terrible advice. > If you write code in a language that does not have exceptions (e.g. C) > and get it working with no error handling, the chances are > approximately 100% that it will stay that way and be shipped without > error handling, until that lack causes someone a major problem. There are languages in which it's inadvisable. But can you honestly say that you've never written a C program with even a single error check omitted, first time? (The trivial case of having never written a C program counts only because smart people leave C to other people.) And PHP's strpos function is not an abomination because it's impossible to distinguish FALSE from 0, but because *most* PHP programs are written without the mandatory check for FALSE after every strpos. So yes, it does happen, a lot. The difference with languages like Python is that this actually *is* good advice in Python. Due to a mistake in editing, the parentheses around the "true in EVERY language" sentence were lost, which would have made it clearer that this is in two distinct parts: 1) This IS what happens, whatever language you use 2) This is the right thing to do in Python, but not always elsewhere. My apologies for the confusion. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-03-22 15:07 +0000 |
| Message-ID | <slrnnf2o3d.19u.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #105489 |
On 2016-03-22, Chris Angelico <rosuav@gmail.com> wrote: > On Wed, Mar 23, 2016 at 12:46 AM, Jon Ribbens ><jon+usenet@unequivocal.co.uk> wrote: >> On 2016-03-22, Chris Angelico <rosuav@gmail.com> wrote: >>> The first step in any program is to write it in the very simplest way >>> possible. That usually means ignoring all error handling. And yes, >>> this is true in EVERY language - C, PHP, Pike, DeScribe Macro >>> Language, you name it. >> >> I'm afraid I have to say I think this is absolutely terrible advice. >> If you write code in a language that does not have exceptions (e.g. C) >> and get it working with no error handling, the chances are >> approximately 100% that it will stay that way and be shipped without >> error handling, until that lack causes someone a major problem. > > There are languages in which it's inadvisable. But can you honestly > say that you've never written a C program with even a single error > check omitted, first time? No, quite the opposite - having done it is how I know that what tends to happen is that the error handling never gets added ;-) > So yes, it does happen, a lot. The difference with languages like > Python is that this actually *is* good advice in Python. Indeed, this is why I think that exceptions are a vital part of a high-level language (and why Java's mandatory exception-declarations are an abomination). > Due to a mistake in editing, the parentheses around the "true in > EVERY language" sentence were lost, which would have made it clearer > that this is in two distinct parts: > > 1) This IS what happens, whatever language you use > 2) This is the right thing to do in Python, but not always elsewhere. > > My apologies for the confusion. Ah yes with the clarification I now agree with you ;-)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 02:18 +1100 |
| Message-ID | <mailman.16.1458659910.2244.python-list@python.org> |
| In reply to | #105493 |
On Wed, Mar 23, 2016 at 2:07 AM, Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote: >> Due to a mistake in editing, the parentheses around the "true in >> EVERY language" sentence were lost, which would have made it clearer >> that this is in two distinct parts: >> >> 1) This IS what happens, whatever language you use >> 2) This is the right thing to do in Python, but not always elsewhere. >> >> My apologies for the confusion. > > Ah yes with the clarification I now agree with you ;-) This is why we have multiple people on the list :) I detest places that basically have "here, send a message to this address and one person will respond" - I wouldn't have noticed my lack of clarity, and the recipient would have received duff advice. Thanks for ensuring the quality of the final result :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-03-22 14:02 +0000 |
| Message-ID | <ncrj3m$ctd$1@dont-email.me> |
| In reply to | #105479 |
On 22/03/2016 13:13, Chris Angelico wrote:
> On Tue, Mar 22, 2016 at 11:59 PM, BartC <bc@freeuk.com> wrote:
> The first step in any program is to write it in the very simplest way
> possible. That usually means ignoring all error handling. And yes,
> this is true in EVERY language - C, PHP, Pike, DeScribe Macro
> Language, you name it. Then you try it, and you find one of two
> things:
(Not in C; you can cause serious damage! But when I tried that approach
in my experimental Python programs, it wasn't popular, I recall.)
> Note, though, that "deal with" really means "deal with", and NOT
> "print oops to the console and terminate". If all you're going to do
> with an exception is print and terminate, *let it go*, unless it's a
> user-triggered failure, in which case you catch it right at the very
> highest level, and basically fall off the end of your program. The
> number of times you have sys.exit() in an except clause should be
> vanishingly small.
So code like the following is consigned to history?
while 1:
| file = input ("Filename (press enter to quit)? ")
| if file == "": break
| print ("Trying to open:",file,"...")
| s = readstrfile(file)
| if s != 0:
| | print (" ",file,"has",len(s),"characters")
| else:
| | print (" There was a problem opening:",file)
(Oops, ignore the bars.)
And, forgetting file input for a minute, what about function return
values in general; should they still be allowed to return some status or
error codes, or does it all have to be exceptions now?
I mean, is a function allowed to still return True or False, or just
False? (Or perhaps just nothing if the exception mechanism can signal
either.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-03-22 07:15 -0700 |
| Message-ID | <f9607328-e841-4acf-bf7b-beba9dcadbf8@googlegroups.com> |
| In reply to | #105488 |
On Tuesday, March 22, 2016 at 10:02:41 AM UTC-4, BartC wrote:
> On 22/03/2016 13:13, Chris Angelico wrote:
> > On Tue, Mar 22, 2016 at 11:59 PM, BartC <bc@freeuk.com> wrote:
>
> > The first step in any program is to write it in the very simplest way
> > possible. That usually means ignoring all error handling. And yes,
> > this is true in EVERY language - C, PHP, Pike, DeScribe Macro
> > Language, you name it. Then you try it, and you find one of two
> > things:
>
> (Not in C; you can cause serious damage! But when I tried that approach
> in my experimental Python programs, it wasn't popular, I recall.)
>
> > Note, though, that "deal with" really means "deal with", and NOT
> > "print oops to the console and terminate". If all you're going to do
> > with an exception is print and terminate, *let it go*, unless it's a
> > user-triggered failure, in which case you catch it right at the very
> > highest level, and basically fall off the end of your program. The
> > number of times you have sys.exit() in an except clause should be
> > vanishingly small.
>
> So code like the following is consigned to history?
>
> while 1:
> | file = input ("Filename (press enter to quit)? ")
> | if file == "": break
> | print ("Trying to open:",file,"...")
> | s = readstrfile(file)
> | if s != 0:
> | | print (" ",file,"has",len(s),"characters")
> | else:
> | | print (" There was a problem opening:",file)
>
> (Oops, ignore the bars.)
We can certainly improve on this:
while True:
filename = input("Filename (press enter to quit)? ")
if not filename:
break
print("Trying to open: {}...".format(filename))
try:
s = readstrfile(filename)
except Exception as e:
print(" There was a problem opening {}: {}".format(filename, e))
else:
print(" {} has {} characters".format(filename, len(s)))
Some detail of the problem is now displayed. In your code,
there's no information about what was wrong with the filename.
Was it an invalid filename for the OS? Was the file there but
the permissions prevented you from reading it? There's no way
to know. With the exception-based code, we have the message from
the exception itself to provide the details.
> And, forgetting file input for a minute, what about function return
> values in general; should they still be allowed to return some status or
> error codes, or does it all have to be exceptions now?
It doesn't *have* to be exceptions. But they are greatly preferred.
They don't clutter the semantics of your return value, and they prevent
accidents by omission.
> I mean, is a function allowed to still return True or False, or just
> False? (Or perhaps just nothing if the exception mechanism can signal
> either.)
Of course a function can still return True or False, if that's a reasonable
semantic. For example, os.path.exists(filename) returns a True or False.
--Ned.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 01:31 +1100 |
| Message-ID | <mailman.15.1458657100.2244.python-list@python.org> |
| In reply to | #105488 |
On Wed, Mar 23, 2016 at 1:02 AM, BartC <bc@freeuk.com> wrote:
>> Note, though, that "deal with" really means "deal with", and NOT
>> "print oops to the console and terminate". If all you're going to do
>> with an exception is print and terminate, *let it go*, unless it's a
>> user-triggered failure, in which case you catch it right at the very
>> highest level, and basically fall off the end of your program. The
>> number of times you have sys.exit() in an except clause should be
>> vanishingly small.
>
>
> So code like the following is consigned to history?
>
> while 1:
> | file = input ("Filename (press enter to quit)? ")
> | if file == "": break
> | print ("Trying to open:",file,"...")
> | s = readstrfile(file)
> | if s != 0:
> | | print (" ",file,"has",len(s),"characters")
> | else:
> | | print (" There was a problem opening:",file)
>
> (Oops, ignore the bars.)
Your "else" clause there conceals the fact that it's actually
*recovering* from an error condition, by reporting it and then
returning to the main loop. So here's how I'd write it:
while "moar files":
filename = input("Filename (blank to quit): ")
if not filename: break
print("Reading %s..." % filename, end="\r")
try:
print(" %s has %d characters." % (filename, len(readfile(filename))))
except (IOError, OSError) as e:
print(" Cannot read %s: %s" % (filename, e))
Aside from a few trivial changes to names and text strings and such,
the one significant change is that I catch just two types of error
(I/O and OS), and *I print out the error message*. In this case, the
traceback wouldn't be very helpful, so it's dropped; but the text
message is useful *to the user*, not just the programmer. If I were
using a program like this and it didn't distinguish between "file not
found", "permission denied", "is a directory", and "disk read
failure", I would be extremely displeased.
Note that I didn't catch UnicodeDecodeError here. If the file you're
trying to read isn't a text file, the exception will terminate the
process. Perhaps you decide that this should be handled too; all you
have to do is add it to the existing except clause, or add a second
one to handle this differently (maybe just "except UnicodeDecodeError:
print('is binary')"). That's the beauty of exception handling; you
handle as many or as few types as make sense for you to handle.
> And, forgetting file input for a minute, what about function return values
> in general; should they still be allowed to return some status or error
> codes, or does it all have to be exceptions now?
>
> I mean, is a function allowed to still return True or False, or just False?
> (Or perhaps just nothing if the exception mechanism can signal either.)
Depends on what those return values mean! If they mean exceptional
conditions, perhaps they should be changed; if they mean return
values, of course they shouldn't.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-03-23 12:14 +1100 |
| Message-ID | <56f1ee00$0$1608$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105488 |
On Wed, 23 Mar 2016 01:02 am, BartC wrote:
> And, forgetting file input for a minute, what about function return
> values in general; should they still be allowed to return some status or
> error codes, or does it all have to be exceptions now?
It doesn't *have to* be exceptions, but exceptions are considered to be a
generally better approach. Some people disagree, must famously Rob Pike,
the highly respected creator of Go (the language, not the ancient Chinese
board game). But Go's approach of returning error codes is most certainly
not Pythonic. (It might be Go-thonic :-)
> I mean, is a function allowed to still return True or False, or just
> False? (Or perhaps just nothing if the exception mechanism can signal
> either.)
You can answer this question yourself by looking at what functions are
provided in the standard library and built-ins:
py> "hello world".find("goodbye")
-1
py> "hello world".startswith("goodbye")
False
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 12:21 +1100 |
| Message-ID | <mailman.25.1458696114.2244.python-list@python.org> |
| In reply to | #105504 |
On Wed, Mar 23, 2016 at 12:14 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> I mean, is a function allowed to still return True or False, or just
>> False? (Or perhaps just nothing if the exception mechanism can signal
>> either.)
>
>
> You can answer this question yourself by looking at what functions are
> provided in the standard library and built-ins:
>
> py> "hello world".find("goodbye")
> -1
> py> "hello world".startswith("goodbye")
> False
To add to the "experiment" advice, a general rule of thumb: Any
function/method that appears to be asking a yes/no question should be
happy to return True/False for the two answers. It can still raise if
the question doesn't make sense:
>>> "hello world".startswith(3.14159)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: startswith first arg must be str or a tuple of str, not float
>>> "hello world".startswith(b"\x41")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: startswith first arg must be str or a tuple of str, not bytes
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-03-22 13:43 -0600 |
| Message-ID | <mailman.20.1458675835.2244.python-list@python.org> |
| In reply to | #105476 |
On 03/22/2016 06:59 AM, BartC wrote: > I'm not sure I follow. Your solution to dealing with the scenarios > raised by Steven D'Aprano is to: > > (1) Not bother with exceptions at all inside the function Correct, if your function is not equipped to handle this exceptional circumstance and do the right thing, the right thing to do is let the caller deal with it. Otherwise debugging is very hard if not impossible. In your former example, a 0 return code means what exactly? File not found? File exists but permission is denied? > > (2) Not bother with them in the user code either Again, it depends on whether the user code is equipped to react to the exception and do the right thing. I probably would catch file and i/o errors like file-not-found and print a specific message out (or a dialog box). Or loop back to try again if the user was picking a file to work with. And despite the impression you may have gotten, it is appropriate to look before you leap. Using os.exists() and other pre-flight checks are appropriate. > (3) Let any errors just crash out (raise a Python system error) (just > like I did in my original jpeg program which I was called out on) Any exceptions your program is not explicitly equipped to deal with should indeed bubble up to the OS and crash out. After all it's by definition an exceptional event and the state of your program and data after this point is not reliable if such an event is ignored. And it provides valuable information an end user can pass back to you as a developer to find bugs you missed. > (4) Or if the user code does want to check for certain errors (like, > File Not Found, by far the most likely, and so that it can deal with > that and continue executing), it now has to go and dig out docs for ... > what? The user code needs to know what is going on inside the supposedly > opaque function it's calling. Good documentation should describe exactly what exceptions a function or library raises and why. I tend to try to follow the example of Python's standard library. I keep my exception classes few, and raise a good error message with it. But often times the exceptions we're talking about are standard Python exceptions arising from things like I/O, not custom library classes.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 09:23 +1100 |
| Message-ID | <mailman.23.1458685394.2244.python-list@python.org> |
| In reply to | #105476 |
On Wed, Mar 23, 2016 at 6:43 AM, Michael Torrie <torriem@gmail.com> wrote: > And despite the impression you may have gotten, it is appropriate to > look before you leap. Using os.exists() and other pre-flight checks are > appropriate. Hmm, can you justify this? Remember, as soon as any other process has done anything, your LBYL is invalid. You check that the file exists, then it gets deleted. Or you check that it doesn't, and bam, suddenly it does. The only way to be certain is to do an operation that enforces it on the hard disk itself - either open the file (after that, deletion can't affect you - on some OSes, deletion can't happen), or create it and hold it open exclusively (nobody else can create a file with that name). >> (4) Or if the user code does want to check for certain errors (like, >> File Not Found, by far the most likely, and so that it can deal with >> that and continue executing), it now has to go and dig out docs for ... >> what? The user code needs to know what is going on inside the supposedly >> opaque function it's calling. > > Good documentation should describe exactly what exceptions a function or > library raises and why. I tend to try to follow the example of Python's > standard library. I keep my exception classes few, and raise a good > error message with it. > > But often times the exceptions we're talking about are standard Python > exceptions arising from things like I/O, not custom library classes. If you have documentation like this, it should list only the exceptions that you explicitly raise, not those that can bubble up through it - this is where Java gets it wrong, IMO. If you attempt to read from a file that gets passed in as an argument, AttributeError could get raised, but you shouldn't document that; but if you have a line of code that says "raise InconsistentDNSRecordError", then yes, that's something worth documenting. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-03-23 17:07 +1100 |
| Message-ID | <56f23287$0$1607$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #105503 |
On Wednesday 23 March 2016 09:23, Chris Angelico wrote:
> On Wed, Mar 23, 2016 at 6:43 AM, Michael Torrie <torriem@gmail.com> wrote:
>> And despite the impression you may have gotten, it is appropriate to
>> look before you leap. Using os.exists() and other pre-flight checks are
>> appropriate.
>
> Hmm, can you justify this? Remember, as soon as any other process has
> done anything, your LBYL is invalid.
"Time of check to time of use":
https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
Fortunately, not all such "bugs" are of equal severity. In this case, there
are two failure modes. Consider a *false positive* bug: we think the file
exists when it actually doesn't.
if os.path.exists(filename):
os.unlink(filename) # some other process does this
open(filename)
This is probably bad. At best, we get some sort of unhandled exception. At
worst, we get some sort of TOCTTOU security vulnerability.
Consider a *false negative* bug: we think the file doesn't exist, when it
actually does, and report an error:
if os.path.exists(filename):
...
else:
open(filename, 'w').write('stuff') # some other process does this
print("No such file, please try again.")
This is probably trivial. The user simply tries again, or refreshes the
application's "file open" selector, or something similar. No harm done.
Or consider scripting a file rename:
for old, new in zip(oldnames, newnames):
if os.path.exists(new):
print("skipping...")
os.rename(old, new)
Is it safe? Strictly speaking, no, but for a single user computer, it's
probably safe enough. If I'm busy saving new files to a directory at the
same time as I'm running a bulk rename of the files in that same directory,
I probably deserve to have data loss :-)
(But having said that, if someone can give a recipe for the right way to do
a file rename without overwriting existing files, I'd love to see it.)
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-03-23 17:28 +1100 |
| Message-ID | <mailman.30.1458714528.2244.python-list@python.org> |
| In reply to | #105513 |
On Wed, Mar 23, 2016 at 5:07 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Fortunately, not all such "bugs" are of equal severity. In this case, there
> are two failure modes. Consider a *false positive* bug: we think the file
> exists when it actually doesn't.
>
> if os.path.exists(filename):
> os.unlink(filename) # some other process does this
> open(filename)
>
>
> This is probably bad. At best, we get some sort of unhandled exception.
Yes - and it's exactly why it's not worth bothering with the 'exists'
check. Your code would end up looking like this:
if os.path.exists(filename):
try:
open(filename)
except FileNotFoundError:
# file got deleted out from under you
else:
# file doesn't exist
Which is exactly why error handling (whether with structured
exceptions or error codes) is better than LBYL for anything involving
the file system, or shared resources and concurrency, or anything with
a potential TOCTTOU discrepancy.
All the other situations (apart from renaming) are handled the same
way - sure, the consequences aren't as serious, but it's just as easy
to use the same technique everywhere. I don't know of a cross-platform
way to rename without overwriting, but the "mv" command on my system
has a --no-clobber option, and the underlying rename system call seems
to have a non-standard flags parameter that can be set to
RENAME_NOREPLACE to prevent overwriting. This is generally the way to
fix it; it's only in the system call that this can actually be done
reliably (hence things like temp file creation are done with flags to
the file-open syscall).
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-03-22 04:23 -0700 |
| Message-ID | <f8a1d9ee-ee86-4355-bae7-4cfc5f6cebbd@googlegroups.com> |
| In reply to | #105459 |
On Tuesday, March 22, 2016 at 7:05:20 AM UTC-4, BartC wrote:
> On 22/03/2016 01:01, Steven D'Aprano wrote:
> > Pythonic code probably uses a lot of iterables:
> >
> > for value in something:
> > ...
>
> > in preference to Pascal code written in Python:
> >
> > for index in range(len(something)):
> > value = something[index]
>
> (Suppose you need both the value and its index in the loop? Then the
> one-line for above won't work. For example, 'something' is [10,20,30]
> and you want to print:
>
> 0: 10
> 1: 20
> 2: 30 )
Then you use enumerate:
for index, value in enumerate(something):
print("{}: {}".format(index, value))
Python has a number of iteration features that you don't find in other
languages. You might find this introduction to them helpful:
Loop Like a Native: http://nedbatchelder.com/text/iter.html
>
> > ...
> > or worse:
> >
> > index = 0
> > while index < len(something):
> > value = something[index]
> > ...
> > index += 1
>
> > (I don't know where that while-loop idiom comes from. C? Assembly? Penitent
> > monks living in hair shirts in the desert and flogging themselves with
> > chains every single night to mortify the accursed flesh? But I'm seeing it
> > a lot in code written by beginners. I presume somebody, or some book, is
> > teaching it to them. "Learn Python The Hard Way" perhaps?)
>
> Are you suggesting 'while' is not needed? Not everything fits into a
> for-loop you know!
Steven wasn't saying 'while' is not needed. He was wondering about the
idiom of manually maintaining an integer count of the number of times
around a while loop ("I don't know where *that* while-loop idiom comes from").
While-loops are still useful in Python, but for-loops are much more common.
--Ned.
[toc] | [prev] | [next] | [standalone]
| From | Ian Foote <ian@feete.org> |
|---|---|
| Date | 2016-03-22 11:27 +0000 |
| Message-ID | <mailman.2.1458646087.2244.python-list@python.org> |
| In reply to | #105459 |
On 22/03/16 11:05, BartC wrote:
> On 22/03/2016 01:01, Steven D'Aprano wrote:
>
>> Pythonic code probably uses a lot of iterables:
>>
>> for value in something:
>> ...
>
>> in preference to Pascal code written in Python:
>>
>> for index in range(len(something)):
>> value = something[index]
>
> (Suppose you need both the value and its index in the loop? Then the
> one-line for above won't work. For example, 'something' is [10,20,30]
> and you want to print:
>
> 0: 10
> 1: 20
> 2: 30 )
>
The builtin enumerate function is the idiomatic way:
for index, item in enumerate(something):
...
Regards,
Ian F
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-03-22 07:45 -0400 |
| Message-ID | <mailman.3.1458647106.2244.python-list@python.org> |
| In reply to | #105459 |
On Tue, 22 Mar 2016 11:05:01 +0000, BartC <bc@freeuk.com> declaimed the
following:
>
>But out of interest, how would /you/ write a function that takes a
>file-spec and turns it into an in-memory string? And what would its use
>look like?
>
At the basics -- and letting the garbage collector get the file handle
later...
imstr = open(fileName, "r").read()
If you want a separate function... (the name here stinks, but...)
def fn2str(fileName):
fin = open(fileName, "r")
imstr = fin.read()
fin.close()
return imstr
...
data = fn2str("some.file")
letting any exceptions propagate upwards. I've never gotten comfortable
with "with" but if one wants to avoid the manual close operation...
def fn2str(fileName):
with open(fileName, "r") as fin:
imstr = fin.read()
return imstr
>(Suppose you need both the value and its index in the loop? Then the
>one-line for above won't work. For example, 'something' is [10,20,30]
>and you want to print:
>
> 0: 10
> 1: 20
> 2: 30 )
>
for i, v in enumerate([10, 20, 30]):
print "%s: %s" % (i, v)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
Back to top | Article view | comp.lang.python
csiph-web