Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #68711 > unrolled thread
| Started by | vasudevram <vasudevram@gmail.com> |
|---|---|
| First post | 2014-03-21 13:42 -0700 |
| Last post | 2014-03-28 17:05 -0500 |
| Articles | 20 on this page of 401 — 30 participants |
Back to article view | Back to comp.lang.python
Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) vasudevram <vasudevram@gmail.com> - 2014-03-21 13:42 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 13:54 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) vasudevram <vasudevram@gmail.com> - 2014-03-21 13:56 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 14:09 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-21 15:30 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 19:06 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-22 13:41 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 21:39 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-22 15:51 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 22:26 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-23 00:32 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-22 20:46 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-22 20:16 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-22 21:47 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-24 02:35 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 14:27 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-23 21:14 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 16:04 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 14:32 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-21 22:48 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-21 23:51 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-22 09:46 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 00:52 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-24 03:03 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-24 11:55 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 22:49 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-24 14:36 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 23:53 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-24 14:39 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-24 15:22 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-24 14:21 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-24 14:04 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 09:00 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 06:12 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-24 13:42 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 06:57 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 05:28 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:43 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-24 11:24 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 16:43 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-25 00:43 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 18:56 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 11:11 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 19:16 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 11:28 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-25 00:32 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 19:50 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-03-24 21:31 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 12:41 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:28 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-03-24 21:20 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 21:39 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:52 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) alex23 <wuwei23@gmail.com> - 2014-03-26 16:35 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-27 10:44 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-28 03:10 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-27 11:37 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-28 03:48 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-27 15:54 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-28 08:42 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-27 17:14 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-28 13:24 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-27 19:46 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-28 14:06 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-27 20:20 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-27 17:14 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 04:45 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-28 00:34 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 16:18 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-29 13:45 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 03:08 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 22:18 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-29 14:45 +1100
Keyboard standards (was: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)) Ben Finney <ben+python@benfinney.id.au> - 2014-03-29 15:18 +1100
Re: Keyboard standards Mark H Harris <harrismh777@gmail.com> - 2014-03-28 23:26 -0500
Re: Keyboard standards Chris Angelico <rosuav@gmail.com> - 2014-03-29 16:13 +1100
Re: Keyboard standards Mark H Harris <harrismh777@gmail.com> - 2014-03-29 00:40 -0500
Re: Keyboard standards Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-29 04:02 -0600
Re: Keyboard standards Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 16:03 +0000
Re: Keyboard standards Larry Hudson <orgnut@yahoo.com> - 2014-03-29 12:27 -0700
Re: Keyboard standards Michael Torrie <torriem@gmail.com> - 2014-03-29 13:41 -0600
Re: Keyboard standards Larry Hudson <orgnut@yahoo.com> - 2014-03-29 23:53 -0700
Re: Keyboard standards Dave Angel <davea@davea.name> - 2014-03-29 17:26 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 03:51 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 23:07 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 23:16 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 23:21 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-29 15:48 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 23:40 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-29 16:08 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-28 22:21 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-29 00:51 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-29 17:03 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-29 03:21 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-29 15:45 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-30 00:52 -0500
OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 06:31 +0000
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Chris Angelico <rosuav@gmail.com> - 2014-03-30 17:43 +1100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark H Harris <harrismh777@gmail.com> - 2014-03-30 01:48 -0500
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 10:35 +0000
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Chris Angelico <rosuav@gmail.com> - 2014-03-30 23:03 +1100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark H Harris <harrismh777@gmail.com> - 2014-03-30 23:29 -0500
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark H Harris <harrismh777@gmail.com> - 2014-03-30 23:57 -0500
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Chris Angelico <rosuav@gmail.com> - 2014-03-31 16:05 +1100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark H Harris <harrismh777@gmail.com> - 2014-03-31 00:33 -0500
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-31 09:31 +0100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Mark H Harris <harrismh777@gmail.com> - 2014-03-31 00:23 -0500
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Chris Angelico <rosuav@gmail.com> - 2014-03-31 16:44 +1100
Re: OFF TOPIC Spanish in the USA Marko Rauhamaa <marko@pacujo.net> - 2014-03-31 11:39 +0300
Re: OFF TOPIC Spanish in the USA Ned Batchelder <ned@nedbatchelder.com> - 2014-03-31 07:33 -0400
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-31 08:41 -0400
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Chris Angelico <rosuav@gmail.com> - 2014-04-01 00:04 +1100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-31 21:47 +0100
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Terry Reedy <tjreedy@udel.edu> - 2014-03-31 18:06 -0400
Re: OFF TOPIC Spanish in the USA [was Re: Explanation of this Python language feature?] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-31 20:03 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Larry Hudson <orgnut@yahoo.com> - 2014-03-30 00:32 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 10:44 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-30 23:57 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) MRAB <python@mrabarnett.plus.com> - 2014-03-31 00:20 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Grant Edwards <invalid@invalid.invalid> - 2014-03-31 14:14 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Walter Hurry <walterhurry@gmail.com> - 2014-03-31 00:39 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Roy Smith <roy@panix.com> - 2014-03-30 08:08 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 15:22 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-30 10:03 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-31 01:08 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-31 17:47 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ben Finney <ben+python@benfinney.id.au> - 2014-03-31 17:53 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-31 00:36 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) wxjmfauth@gmail.com - 2014-03-31 01:32 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Roy Smith <roy@panix.com> - 2014-03-31 08:16 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-31 21:46 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-01 16:26 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-02 08:49 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-01 18:18 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-01 18:33 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-03 11:38 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-03 20:14 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-03 11:40 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-03 13:55 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-03 22:43 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-03 22:12 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-04 09:43 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-03 21:09 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-04 07:52 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-04 19:11 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-04 02:13 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-04 10:08 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-04 11:01 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-05 00:20 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) alex23 <wuwei23@gmail.com> - 2014-04-04 12:07 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-03 21:29 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-04 09:20 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 15:58 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-04 15:40 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-04 22:50 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 17:07 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 09:39 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 17:52 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 09:57 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-05 00:16 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 23:10 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 15:40 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 00:11 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-04 23:02 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 00:37 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ben Finney <ben+python@benfinney.id.au> - 2014-04-05 17:01 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 01:48 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 18:08 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 01:48 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-04 23:07 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 17:52 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-04 23:04 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 23:18 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 14:22 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-05 00:10 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 17:07 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-05 00:00 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 12:51 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-04 23:31 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 15:49 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 00:23 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 16:55 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 00:23 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-04 20:42 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 00:02 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 16:24 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ben Finney <ben+python@benfinney.id.au> - 2014-04-05 16:29 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 16:57 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-04 23:59 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-05 18:10 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-05 10:19 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-05 07:20 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Roy Smith <roy@panix.com> - 2014-04-05 10:28 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-04 09:53 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-04 03:24 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-04 06:43 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 22:59 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 23:59 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-06 12:05 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-06 16:52 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-06 10:31 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-07 03:54 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-06 11:13 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-07 04:46 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-06 19:32 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-07 20:33 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) MRAB <python@mrabarnett.plus.com> - 2014-04-08 02:52 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-08 13:02 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-04-08 08:21 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) alex23 <wuwei23@gmail.com> - 2014-04-09 10:39 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-09 12:26 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-08 03:53 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-07 03:27 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-06 23:23 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-06 19:09 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-04-07 04:14 +1000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-06 23:10 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-06 21:56 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-06 23:48 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-04-06 20:45 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-04-06 18:54 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-04-07 05:10 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-07 08:14 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-04-08 09:03 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-04-07 07:54 +0300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-07 12:19 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-04-05 23:01 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-28 23:10 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-29 00:51 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 17:53 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-30 01:22 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 16:22 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-29 13:39 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Roy Smith <roy@panix.com> - 2014-03-29 07:53 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-29 13:59 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Gene Heskett <gheskett@wdtv.com> - 2014-03-29 13:48 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-30 00:57 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Gene Heskett <gheskett@wdtv.com> - 2014-03-29 13:46 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 10:01 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 18:44 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 10:57 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:16 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-24 17:58 -0600
Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 20:00 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 22:15 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 14:17 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 22:25 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 22:28 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Roy Smith <roy@panix.com> - 2014-03-24 23:29 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 14:51 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 22:59 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 21:08 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 15:29 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 22:00 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:08 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 00:14 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 22:23 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:31 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:27 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 00:34 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 22:42 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 00:47 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:54 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 16:48 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 00:56 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Roy Smith <roy@panix.com> - 2014-03-25 08:36 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 05:53 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 14:43 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 06:52 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-26 00:56 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 07:08 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 14:23 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 08:19 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-26 09:33 +1300
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 11:58 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-25 20:02 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 01:01 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:19 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 07:03 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 18:12 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-25 20:05 -0400
Re: Time we switched to unicode? Marko Rauhamaa <marko@pacujo.net> - 2014-03-25 10:05 +0200
Re: Time we switched to unicode? Chris Angelico <rosuav@gmail.com> - 2014-03-25 19:23 +1100
Re: Time we switched to unicode? Steven D'Aprano <steve@pearwood.info> - 2014-03-25 08:59 +0000
Re: Time we switched to unicode? Chris Angelico <rosuav@gmail.com> - 2014-03-25 20:03 +1100
Re: Time we switched to unicode? Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-03-25 18:24 +0100
Re: Time we switched to unicode? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-26 01:01 +0000
Re: Time we switched to unicode? Chris Angelico <rosuav@gmail.com> - 2014-03-26 06:40 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 22:28 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 00:36 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:07 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-25 01:48 -0500
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 10:43 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 20:54 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 11:38 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 11:14 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 12:46 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 05:09 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 15:18 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Terry Reedy <tjreedy@udel.edu> - 2014-03-25 19:55 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-26 00:12 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Terry Reedy <tjreedy@udel.edu> - 2014-03-26 00:30 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 21:56 -0700
Delayed evaluation of expressions [was Re: Time we switched to unicode?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-26 16:05 +0000
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Rustom Mody <rustompmody@gmail.com> - 2014-03-26 10:32 -0700
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Rustom Mody <rustompmody@gmail.com> - 2014-03-26 10:57 -0700
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Chris Angelico <rosuav@gmail.com> - 2014-03-27 09:24 +1100
Re: Delayed evaluation of expressions Marko Rauhamaa <marko@pacujo.net> - 2014-03-27 00:45 +0200
Re: Delayed evaluation of expressions Rustom Mody <rustompmody@gmail.com> - 2014-03-26 22:02 -0700
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-26 23:43 +0000
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Rustom Mody <rustompmody@gmail.com> - 2014-03-26 18:59 -0700
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Terry Reedy <tjreedy@udel.edu> - 2014-03-26 20:44 -0400
Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-27 02:16 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Roy Smith <roy@panix.com> - 2014-03-25 08:35 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-26 00:13 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 14:13 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-26 01:37 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-26 09:58 +1300
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-25 20:10 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-26 09:21 +1300
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Larry Martell <larry.martell@gmail.com> - 2014-03-25 16:31 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-25 21:22 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 15:19 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:04 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:26 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Roy Smith <roy@panix.com> - 2014-03-25 08:24 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-25 19:44 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 20:43 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 14:57 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 05:47 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 23:10 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:33 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 23:41 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:50 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Terry Reedy <tjreedy@udel.edu> - 2014-03-25 18:39 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:12 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 23:35 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 17:45 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 23:52 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-27 01:16 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-27 12:26 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 20:44 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-24 20:56 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 15:14 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 07:03 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 00:22 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 11:24 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Roy Smith <roy@panix.com> - 2014-03-25 08:21 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 13:36 +0000
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 15:01 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Terry Reedy <tjreedy@udel.edu> - 2014-03-25 22:10 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-26 13:39 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-27 01:32 -0600
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-27 01:43 -0600
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 22:12 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 13:07 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-25 23:45 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Rustom Mody <rustompmody@gmail.com> - 2014-03-25 06:07 -0700
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Chris Angelico <rosuav@gmail.com> - 2014-03-26 00:50 +1100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-26 09:37 +1300
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-25 14:07 +0100
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Terry Reedy <tjreedy@udel.edu> - 2014-03-25 20:24 -0400
Re: Time we switched to unicode? (was Explanation of this Python language feature?) Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-26 10:22 +0100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-25 06:20 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve@pearwood.info> - 2014-03-24 09:49 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-24 22:21 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 14:47 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-25 01:45 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 13:17 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-25 02:06 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 22:48 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-24 09:58 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 13:58 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-24 19:13 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-24 13:12 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 06:22 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-24 22:58 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 10:07 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Terry Reedy <tjreedy@udel.edu> - 2014-03-24 21:04 -0400
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-25 06:45 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-22 04:47 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Chris Angelico <rosuav@gmail.com> - 2014-03-22 16:05 +1100
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-22 12:24 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-22 03:09 -0600
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-22 12:30 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-22 10:16 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-22 10:40 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-22 17:57 +0000
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Marko Rauhamaa <marko@pacujo.net> - 2014-03-22 20:40 +0200
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Rustom Mody <rustompmody@gmail.com> - 2014-03-22 11:42 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) 88888 Dihedral <dihedral88888@gmail.com> - 2014-03-25 03:17 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-22 10:34 +1300
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) vasudevram <vasudevram@gmail.com> - 2014-03-22 13:59 -0700
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Mark H Harris <harrismh777@gmail.com> - 2014-03-24 20:56 -0500
Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list) Dan Stromberg <drsalists@gmail.com> - 2014-03-27 16:45 -0700
How to flatten a list of lists was (Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 17:00 -0500
How to flatten a list of lists was (Explanation of this Python language feature?) Mark H Harris <harrismh777@gmail.com> - 2014-03-28 17:00 -0500
To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x] Mark H Harris <harrismh777@gmail.com> - 2014-03-28 17:05 -0500
Re: To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 02:31 +0000
Re: To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x] Mark H Harris <harrismh777@gmail.com> - 2014-03-28 22:33 -0500
To flatten a nested list was (Explanation of this Python language feature? [x for x in x for x in x] Mark H Harris <harrismh777@gmail.com> - 2014-03-28 17:05 -0500
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-26 00:12 +0000 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <53321b7e$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #69082 |
On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote:
> On 3/25/2014 11:18 AM, Steven D'Aprano wrote:
>
>> The thing is, we can't just create a ∑ function, because it doesn't
>> work the way the summation operator works. The problem is that we would
>> want syntactic support, so we could write something like this:
>>
>> p = 2
>> ∑(n, 1, 10, n**p)
>
> Of course we can. If we do not insist on separating the dummy name from
> the expression that contains it. this works.
>
> def sigma(low, high, func):
> sum = 0
> for i in range(low, high+1):
> sum += func(i)
> return sum
There is no expression there. There is a function.
You cannot pass an expression to a function in Python, not in the sense I
am talking about, because expressions are not first-class objects. When
you pass:
sigma(1, 10, n**p)
the n**p gets evaluated immediately. Only with support of the compiler
does evaluation of the expression get delayed, e.g.:
it = (n**p for n in range(1, 11))
result = (-100)**p if isinstance(p, int) else float('nan')
first = items and items[0]
If we tried to write an "and" function like this:
def and_(a, b):
if a: return a
return b
it wouldn't work the same as the `and` operator, because the `and`
operator is lazy and only evaluates the right hand operator when needed,
whereas the function call is greedy and evaluates the right hand operator
up front, whether it is needed or not.
Passing a *function* is not the same as writing an expression. It is a
work-around for lack of first-class expressions. Now perhaps it is an
acceptable work-around, for some purposes at least. But if you want to
match mathematical syntax, it's not enough.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-03-26 00:30 -0400 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <mailman.8562.1395808246.18130.python-list@python.org> |
| In reply to | #69086 |
On 3/25/2014 8:12 PM, Steven D'Aprano wrote: > On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote: > >> On 3/25/2014 11:18 AM, Steven D'Aprano wrote: >> >>> The thing is, we can't just create a ∑ function, because it doesn't >>> work the way the summation operator works. The problem is that we would >>> want syntactic support, so we could write something like this: >>> >>> p = 2 >>> ∑(n, 1, 10, n**p) >> >> Of course we can. If we do not insist on separating the dummy name from >> the expression that contains it. this works. >> >> def sigma(low, high, func): >> sum = 0 >> for i in range(low, high+1): >> sum += func(i) >> return sum > > There is no expression there. There is a function. > > You cannot pass an expression to a function in Python, One passes an unquoted expression in code by quoting it with either lambda, paired quote marks (Lisp used a single '), or using it in a form that implicitly quotes it (that includes def statements). Unquoted expressions in statements ultimately get passed to an internal functions. > not in the sense I am talking about, well, if you eliminate all the possibilities ... > because expressions are not first-class objects. The concept is not a class, and the Python stdlib does not have an expression class. But people have written classes to represent the concept. I used existing classes instead. Expressions are not (normally) mathematical objects either. (An exception is rewriting theory, or other theories, where strings representing expressions or WFFs (well-formed formulas) are the only objects.) Mathematicians quote expression strings by context or positiion. The sigma form is one of many examples. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-25 21:56 -0700 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <7ef4355d-ef12-4931-847e-95ad8358bdc7@googlegroups.com> |
| In reply to | #69099 |
On Wednesday, March 26, 2014 10:00:21 AM UTC+5:30, Terry Reedy wrote: > On 3/25/2014 8:12 PM, Steven D'Aprano wrote: > > On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote: > >> On 3/25/2014 11:18 AM, Steven D'Aprano wrote: > >>> The thing is, we can't just create a ∑ function, because it doesn't > >>> work the way the summation operator works. The problem is that we would > >>> want syntactic support, so we could write something like this: > >>> p = 2 > >>> ∑(n, 1, 10, n**p) > >> Of course we can. If we do not insist on separating the dummy name from > >> the expression that contains it. this works. > >> def sigma(low, high, func): > >> sum = 0 > >> for i in range(low, high+1): > >> sum += func(i) > >> return sum > > There is no expression there. There is a function. > > You cannot pass an expression to a function in Python, > One passes an unquoted expression in code by quoting it with either > lambda, paired quote marks (Lisp used a single '), or using it in a form > that implicitly quotes it (that includes def statements). Unquoted > expressions in statements ultimately get passed to an internal functions. I wrote about the two styles of quoting here: (Yeah its under the scheme banner) http://blog.languager.org/2013/08/applying-si-on-sicp.html There was also a neat little tech report by David Gries from Cornell explaining that λ ∀ Σ ∫ are all 'binding-constructs' in their own sphere's [No access to that any more though :-( ]
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-26 16:05 +0000 |
| Subject | Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <5332fae0$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #69099 |
On Wed, 26 Mar 2014 00:30:21 -0400, Terry Reedy wrote:
> On 3/25/2014 8:12 PM, Steven D'Aprano wrote:
>> On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote:
>>
>>> On 3/25/2014 11:18 AM, Steven D'Aprano wrote:
>>>
>>>> The thing is, we can't just create a ∑ function, because it doesn't
>>>> work the way the summation operator works. The problem is that we
>>>> would want syntactic support, so we could write something like this:
>>>>
>>>> p = 2
>>>> ∑(n, 1, 10, n**p)
>>>
>>> Of course we can. If we do not insist on separating the dummy name
>>> from the expression that contains it. this works.
>>>
>>> def sigma(low, high, func):
>>> sum = 0
>>> for i in range(low, high+1):
>>> sum += func(i)
>>> return sum
>>
>> There is no expression there. There is a function.
>>
>> You cannot pass an expression to a function in Python,
>
> One passes an unquoted expression in code by quoting it with either
> lambda, paired quote marks (Lisp used a single '),
Passing *strings* and *functions* is not the same as having compiler
support for delayed evaluation. At best its a second-class work-around.
Contrast:
def if_else(true_function, condition, false_function):
if condition:
return true_function()
else:
return false_function()
if_else(lambda: x/0, x != 0, lambda: float("inf"))
with this:
x/0 if x != 0 else float("inf")
Aside from the difference between the function form and operator form,
the second case is much more direct and natural than the first.
> or using it in a form
> that implicitly quotes it (that includes def statements). Unquoted
> expressions in statements ultimately get passed to an internal
> functions.
I think you are mistaken. Take the unquoted expression `x+1`. It doesn't
get passed to anything, it gets compiled into byte code and evaluated:
py> from dis import dis
py> dis("x+1")
1 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 BINARY_ADD
7 RETURN_VALUE
Perhaps you are thinking of one or two special cases, such as list comps:
py> dis("[x+1 for x in spam]")
1 0 LOAD_CONST 0 (<code object <listcomp> at
0xb7af22a0, file "<dis>",
line 1>)
3 LOAD_CONST 1 ('<listcomp>')
6 MAKE_FUNCTION 0
9 LOAD_NAME 0 (spam)
12 GET_ITER
13 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
16 RETURN_VALUE
But that's an implementation detail, not a language requirement, and it
doesn't apply to all delayed expressions:
py> dis("1/x if x else y")
1 0 LOAD_NAME 0 (x)
3 POP_JUMP_IF_FALSE 14
6 LOAD_CONST 0 (1)
9 LOAD_NAME 0 (x)
12 BINARY_TRUE_DIVIDE
13 RETURN_VALUE
>> 14 LOAD_NAME 1 (y)
17 RETURN_VALUE
Some Python implementations may use internal functions under the hood to
delay the evaluation of an expression, but you still need support from
the interpreter to compile the expression as an internal function rather
than evaluating it.
> > not in the sense I am talking about,
>
> well, if you eliminate all the possibilities ...
Obviously you can pass an expression to a function in the trivial sense
that you can put an expression inside a function call. But that is not
what I am talking about, since the expression is evaluated first, then
the function is called:
py> dis("function(spam + eggs*cheese)")
1 0 LOAD_NAME 0 (function)
3 LOAD_NAME 1 (spam)
6 LOAD_NAME 2 (eggs)
9 LOAD_NAME 3 (cheese)
12 BINARY_MULTIPLY
13 BINARY_ADD
14 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
17 RETURN_VALUE
I'm referring to delaying execution of the expression until later.
Coincidentally, the Sum function we were discussing is a notable example
of Jensen's Device:
https://en.wikipedia.org/wiki/Jensen%27s_device
which is effectively what I'm referring to.
> > because expressions are not first-class objects.
>
> The concept is not a class, and the Python stdlib does not have an
> expression class. But people have written classes to represent the
> concept. I used existing classes instead.
>
> Expressions are not (normally) mathematical objects either. (An
> exception is rewriting theory, or other theories, where strings
> representing expressions or WFFs (well-formed formulas) are the only
> objects.) Mathematicians quote expression strings by context or
> positiion. The sigma form is one of many examples.
Hmmm. I think you are misunderstanding me, possibly because I wrote
"first-class object" when I should have called it a "first-class value".
Sorry.
I'm not necessarily referring to creating something like an "arithmetic
expression class" with methods and attributes. For example, sympy has
things like that, so you can perform symbolic operations on the
expression. That's not what I mean.
What I mean is that you, the programmer, writes down an ordinary Python
expression, using ordinary expression syntax, and the compiler treats it
as a value in and of itself, rather than evaluating it to find out what
value it has. In Python this will probably be some sort of object, but
that's not the important part. The important part is that it is a *value*.
(Compare to languages where functions are not first-class values. You
cannot pass a function to another function, or stick them in a list, or
create them on the fly. You can only call them, evaluating them
immediately.)
In Algol60, the compiler used thunks, which are a type of closure; in
CPython, list comps use a hidden function object; the ternary if compiles
byte code for a test and jump.
In case you haven't read the article on Jensen's Device above, in Algol60
you can write a Sum function that behaves as a mathematician would
expect. For example, to sum the entries of an array V for indexes 1
through 100, a mathematician might write it something like this:
10
∑ V[i]
i=1
which we can rearrange to function-call syntax like this:
Sum(i, 1, 100, V[i])
In Algol60, this function call would:
- pass the name "i" (not a string!) as the first argument;
- pass 1 as the second argument;
- pass 100 as the third argument;
- pass the expression "V[i]" (not a string!) as the fourth argument
and then *inside* the function Sum the expressions "i" and "V[i]" can be
evaluated or assigned to as needed. Using Python syntax rather than Algol
syntax:
def Sum(name, lower, upper, expression):
total = 0
for name in range(lower, upper+1):
total += expression
return total
This doesn't work in Python! Python lacks call-by-name semantics, so the
function call would:
- evaluate the expression i, and pass that value as the first argument;
- pass 1 as the second argument;
- pass 100 as the third argument;
- evaluate V[i] and pass that value as the fourth argument
and then inside the function Sum "name" refers to the local variable
name, not the caller's variable i. Likewise "expression" refers to a
local variable, and not the caller's expression V[i].
Python has no general way of doing this. There are a few ad-hoc special
cases, like list comps, the ternary if operator, etc. which are hard-
coded in the compiler to delay execution of expressions. For the rest,
you have a choice:
- give up on delayed evaluation, and redesign your API; or
- manually manage the delayed evaluation yourself, using
some combination of functions, eval or exec.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-26 10:32 -0700 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <9ad6730a-f2d9-42fe-a822-88db2916972b@googlegroups.com> |
| In reply to | #69135 |
On Wednesday, March 26, 2014 9:35:53 PM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 26 Mar 2014 00:30:21 -0400, Terry Reedy wrote:
> > On 3/25/2014 8:12 PM, Steven D'Aprano wrote:
> >> On Tue, 25 Mar 2014 19:55:39 -0400, Terry Reedy wrote:
> >>> On 3/25/2014 11:18 AM, Steven D'Aprano wrote:
> >>>> The thing is, we can't just create a ∑ function, because it doesn't
> >>>> work the way the summation operator works. The problem is that we
> >>>> would want syntactic support, so we could write something like this:
> >>>> p = 2
> >>>> ∑(n, 1, 10, n**p)
> >>> Of course we can. If we do not insist on separating the dummy name
> >>> from the expression that contains it. this works.
> >>> def sigma(low, high, func):
> >>> sum = 0
> >>> for i in range(low, high+1):
> >>> sum += func(i)
> >>> return sum
> >> There is no expression there. There is a function.
> >> You cannot pass an expression to a function in Python,
> > One passes an unquoted expression in code by quoting it with either
> > lambda, paired quote marks (Lisp used a single '),
> Passing *strings* and *functions* is not the same as having compiler
> support for delayed evaluation. At best its a second-class work-around.
> Contrast:
Once the language has lambda, most else can be fashioned
See the classic papers
lambda the ultimate imperative
lambda the ultimate declarative
lambda the ultimate goto
at here http://library.readscheme.org/page1.html
> Coincidentally, the Sum function we were discussing is a notable example
> of Jensen's Device:
> https://en.wikipedia.org/wiki/Jensen%27s_device
> which is effectively what I'm referring to.
> > > because expressions are not first-class objects.
> > The concept is not a class, and the Python stdlib does not have an
> > expression class. But people have written classes to represent the
> > concept. I used existing classes instead.
> > Expressions are not (normally) mathematical objects either. (An
> > exception is rewriting theory, or other theories, where strings
> > representing expressions or WFFs (well-formed formulas) are the only
> > objects.) Mathematicians quote expression strings by context or
> > positiion. The sigma form is one of many examples.
> Hmmm. I think you are misunderstanding me, possibly because I wrote
> "first-class object" when I should have called it a "first-class value".
> Sorry.
> I'm not necessarily referring to creating something like an "arithmetic
> expression class" with methods and attributes. For example, sympy has
> things like that, so you can perform symbolic operations on the
> expression. That's not what I mean.
> What I mean is that you, the programmer, writes down an ordinary Python
> expression, using ordinary expression syntax, and the compiler treats it
> as a value in and of itself, rather than evaluating it to find out what
> value it has. In Python this will probably be some sort of object, but
> that's not the important part. The important part is that it is a *value*.
> (Compare to languages where functions are not first-class values. You
> cannot pass a function to another function, or stick them in a list, or
> create them on the fly. You can only call them, evaluating them
> immediately.)
> In Algol60, the compiler used thunks, which are a type of closure; in
> CPython, list comps use a hidden function object; the ternary if compiles
> byte code for a test and jump.
> In case you haven't read the article on Jensen's Device above, in Algol60
> you can write a Sum function that behaves as a mathematician would
> expect. For example, to sum the entries of an array V for indexes 1
> through 100, a mathematician might write it something like this:
> 10
> ∑ V[i]
> i=1
> which we can rearrange to function-call syntax like this:
> Sum(i, 1, 100, V[i])
> In Algol60, this function call would:
> - pass the name "i" (not a string!) as the first argument;
> - pass 1 as the second argument;
> - pass 100 as the third argument;
> - pass the expression "V[i]" (not a string!) as the fourth argument
> and then *inside* the function Sum the expressions "i" and "V[i]" can be
> evaluated or assigned to as needed. Using Python syntax rather than Algol
> syntax:
> def Sum(name, lower, upper, expression):
> total = 0
> for name in range(lower, upper+1):
> total += expression
> return total
> This doesn't work in Python! Python lacks call-by-name semantics, so the
> function call would:
> - evaluate the expression i, and pass that value as the first argument;
> - pass 1 as the second argument;
> - pass 100 as the third argument;
> - evaluate V[i] and pass that value as the fourth argument
> and then inside the function Sum "name" refers to the local variable
> name, not the caller's variable i. Likewise "expression" refers to a
> local variable, and not the caller's expression V[i].
> Python has no general way of doing this. There are a few ad-hoc special
> cases, like list comps, the ternary if operator, etc. which are hard-
> coded in the compiler to delay execution of expressions. For the rest,
> you have a choice:
> - give up on delayed evaluation, and redesign your API; or
> - manually manage the delayed evaluation yourself, using
> some combination of functions, eval or exec.
Heres Jensen device in python
First your pseudo algol version with python frills like range removed
def sumjensen(i,lower,upper,exp):
# i and exp by name
# i get and set, exp only get required
tot = 0
i = lower
while i <= upper:
tot += exp
i = i + 1
return tot
Now actual python
def sumjensen(i_get, i_set,lower,upper,exp):
tot = 0
i_set(lower)
while i_get() <= upper:
tot += exp_get()
i_set(i_get() + 1)
return tot
i=0
a=[3,4,5]
i_get = lambda : i
def i_set(val):
global i
i = val
exp_get = lambda : a[i_get()]
call as sumjensen(i_get, i_set, lower, upper, exp_get)
[Note that because of lambda's restriction to being only an expression
I have to make it a def because of need for global]
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-26 10:57 -0700 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <a24fbbf7-2748-4e65-95e0-5b4a0d5b7daf@googlegroups.com> |
| In reply to | #69139 |
On Wednesday, March 26, 2014 11:02:04 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, March 26, 2014 9:35:53 PM UTC+5:30, Steven D'Aprano wrote: > > On Wed, 26 Mar 2014 00:30:21 -0400, Terry Reedy wrote: > > > One passes an unquoted expression in code by quoting it with either > > > lambda, paired quote marks (Lisp used a single '), > > Passing *strings* and *functions* is not the same as having compiler > > support for delayed evaluation. At best its a second-class work-around. > > Contrast: > Once the language has lambda, most else can be fashioned > See the classic papers > lambda the ultimate imperative > lambda the ultimate declarative > lambda the ultimate goto > at here http://library.readscheme.org/page1.html <Details of Jensen implementation snipped> Which I should have summarized as: lambda is the essential Delay operator. So much so that in scheme thaw and freeze are defined as (using pseudo-python syntax) def thaw(x) : return x() freeze(x) is a 'special-form' (aka macro) such that freeze(x) ≡ lambda : x
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-03-27 09:24 +1100 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <mailman.8592.1395872698.18130.python-list@python.org> |
| In reply to | #69139 |
On Thu, Mar 27, 2014 at 4:32 AM, Rustom Mody <rustompmody@gmail.com> wrote: > Now actual python > > def sumjensen(i_get, i_set,lower,upper,exp): > tot = 0 > i_set(lower) > while i_get() <= upper: > tot += exp_get() > i_set(i_get() + 1) > return tot > > > i=0 > a=[3,4,5] > i_get = lambda : i > def i_set(val): > global i > i = val > > exp_get = lambda : a[i_get()] > > > call as sumjensen(i_get, i_set, lower, upper, exp_get) > > [Note that because of lambda's restriction to being only an expression > I have to make it a def because of need for global] You prove here that Python has first-class expressions in the same way that 80x86 assembly language has garbage collection. Sure, you can implement it using the primitives you have, but that's not support. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2014-03-27 00:45 +0200 |
| Subject | Re: Delayed evaluation of expressions |
| Message-ID | <871txok29s.fsf@elektro.pacujo.net> |
| In reply to | #69150 |
Chris Angelico <rosuav@gmail.com>:
> You prove here that Python has first-class expressions in the same way
> that 80x86 assembly language has garbage collection. Sure, you can
> implement it using the primitives you have, but that's not support.
I was more reminded of STL and Boost. For example:
std::for_each(v.begin(), v.end(),
(
switch_statement(
_1,
case_statement<0>(std::cout << constant("zero")),
case_statement<1>(std::cout << constant("one")),
default_statement(cout << constant("other: ") << _1)
),
cout << constant("\n")
)
);
(<URL: http://www.boost.org/doc/libs/1_55_0/doc/html/lambda/
le_in_details.html#lambda.switch_statement>)
Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-26 22:02 -0700 |
| Subject | Re: Delayed evaluation of expressions |
| Message-ID | <3dcf41ad-a036-4f51-af23-9672b7e71e40@googlegroups.com> |
| In reply to | #69151 |
On Thursday, March 27, 2014 4:15:19 AM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> > You prove here that Python has first-class expressions in the same way
> > that 80x86 assembly language has garbage collection. Sure, you can
> > implement it using the primitives you have, but that's not support.
> I was more reminded of STL and Boost. For example:
> std::for_each(v.begin(), v.end(),
> (
> switch_statement(
> _1,
> case_statement<0>(std::cout << constant("zero")),
> case_statement<1>(std::cout << constant("one")),
> default_statement(cout << constant("other: ") << _1)
> ),
> cout << constant("\n")
> )
> );
> (<URL: http://www.boost.org/doc/libs/1_55_0/doc/html/lambda/
> le_in_details.html#lambda.switch_statement>)
I must admit I have a hard time reading C++!
However that link seems to be saying more or less what I am -- viz. lambda
is a delay operator
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-26 23:43 +0000 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <53336618$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #69150 |
On Thu, 27 Mar 2014 09:24:49 +1100, Chris Angelico wrote: > On Thu, Mar 27, 2014 at 4:32 AM, Rustom Mody <rustompmody@gmail.com> > wrote: >> Now actual python >> >> def sumjensen(i_get, i_set,lower,upper,exp): >> tot = 0 >> i_set(lower) >> while i_get() <= upper: >> tot += exp_get() >> i_set(i_get() + 1) >> return tot >> >> >> i=0 >> a=[3,4,5] >> i_get = lambda : i >> def i_set(val): >> global i >> i = val >> >> exp_get = lambda : a[i_get()] >> >> >> call as sumjensen(i_get, i_set, lower, upper, exp_get) >> >> [Note that because of lambda's restriction to being only an expression >> I have to make it a def because of need for global] > > You prove here that Python has first-class expressions in the same way > that 80x86 assembly language has garbage collection. Sure, you can > implement it using the primitives you have, but that's not support. +1 Any language can work around the lack of a language feature by sufficient layers of indirection, but that's not the same as having that language feature. Beyond a certain minimum feature set, all languages are Turing complete, and so in one sense are of equivalent power. But they're not all of equal expressiveness. Python is awesome, it is very expressive, but there are certain things you can't write directly in Python, and have to resort to circumlocutions instead. See also Paul Graham's "Blub language" essay: http://paulgraham.com/avg.html -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2014-03-26 18:59 -0700 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <169b5e45-f911-47c2-996b-0507d78dd7d1@googlegroups.com> |
| In reply to | #69154 |
On Thursday, March 27, 2014 5:13:21 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 27 Mar 2014 09:24:49 +1100, Chris Angelico wrote: > > wrote: > >> Now actual python > >> def sumjensen(i_get, i_set,lower,upper,exp): > >> tot = 0 > >> i_set(lower) > >> while i_get() <= upper: > >> tot += exp_get() > >> i_set(i_get() + 1) > >> return tot > >> i=0 > >> a=[3,4,5] > >> i_get = lambda : i > >> def i_set(val): > >> global i > >> i = val > >> exp_get = lambda : a[i_get()] > >> call as sumjensen(i_get, i_set, lower, upper, exp_get) > >> [Note that because of lambda's restriction to being only an expression > >> I have to make it a def because of need for global] > > You prove here that Python has first-class expressions in the same way > > that 80x86 assembly language has garbage collection. Sure, you can > > implement it using the primitives you have, but that's not support. > +1 > Any language can work around the lack of a language feature by sufficient > layers of indirection, but that's not the same as having that language > feature. > Beyond a certain minimum feature set, all languages are Turing complete, > and so in one sense are of equivalent power. But they're not all of equal > expressiveness. Python is awesome, it is very expressive, but there are > certain things you can't write directly in Python, and have to resort to > circumlocutions instead. Of course. And there are different grades of circumlocution -- of 'coding-up' -- a missing feature. Terry said: > One passes an unquoted expression in code by quoting it with either > lambda, paired quote marks (Lisp used a single '), Steven responded: > Passing *strings* and *functions* is not the same as having compiler > support for delayed evaluation. At best its a second-class work-around. I was merely pointing out that 'passing strings' and 'passing functions' as 'coding-up' of some desirable but unavailable feature are very different levels of work-around. In fact there are actually 3 styles and levels of circumlocution 1. You dont have a certain language -- blub?? -- feature set. So... code it up and write its interpreter as eval_blub. 2. You dont have a feature-set but can see similarity in some obtuse host-language (in this case python). So you code up a mini-translator for your feature-set neatly written to obtuse hostly written and then eval (note python eval not blub eval) 3. You dont go outside the language framework and into any eval-ish mode at all. Good ol subroutine libraries to classes for abstraction to first-class functional abstraction -- all fall into this category
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-03-26 20:44 -0400 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <mailman.8595.1395881083.18130.python-list@python.org> |
| In reply to | #69135 |
I agree that we have not been understanding each other.
From you original post that I responded to:
>>>>> The thing is, we can't just create a ∑ function, because it doesn't
>>>>> work the way the summation operator works. The problem is that we
>>>>> would want syntactic support, so we could write something like this:
>>>>> p = 2
>>>>> ∑(n, 1, 10, n**p)
The initial misunderstanding is that I interpreted 'something like this'
more loosely than you meant it. So I wrote something that was 'something
like the above' to me but not to you. I interpreted 'something like'
semantically* whereas you apparently meant is syntactically. I added the
one or the other little marks needed to make the above work in python as
it is whereas your 'something like' excludes such marks or any other
current possibility I can think of. So I actually agree that "can't" is
correct in relation to what you meant, as opposed to what I understood.
Changing "can't" to "can" would requires a major change to Python. That
change is one I would strongly oppose and I will try to explain more
clearly why.
[*When I qualify doc suggestions on the tracker with 'something like',
as I usually do, I mean something that conveys the same meaning. So I
edited your call text to convey the intended meaning in Python.]
Lets start with things we should agree on. The first two are mostly not
specific to Python.
1. When a compiler encounters an expression in code, there are at least
three things it can do:
1a. compile it so that it is immediately executed when encountered at
runtime (let this be the default);
1b. compile it so that it is somehow saved for execution later or
elsewhere (the alternative of concern here);
1c. compile it for a different alternative, such as turning an implied
'get' operation into a 'set' operation.
2. A code writer who wants an alternative treatment for a particular
must somehow delineate the expresion with boundary markers that, in
context at least, also indicate the alternative treatment. There are,
broadly, two possibilities:
2a. Use a generic quotation mechanism that can be applied to any
expression most any place. I call this explicit quoting.
2b. Use the expression in a special form that the compiler knows about.
The special form must have begin-end markers of some sort. I call this
implicit quoting. If human readers do not know that a particular form is
a special form, they may have a problem understanding the code.
Python has 2 pairs of generic explicit delimiters: open-close quote
marks and lambda-<EndofLambda>, where <EndofLambda> is ',', ')',
<EndofLine>, or maybe something else. If these are not present, the
default immediate execution mode is used for expressions in function
calls that are not themselves marked for alternative treatment.
Python's special forms are statements. Each has its own pair of
delimiters. Assignments use <BeginningofLine> and '='. 'For' loops use
'for' and 'in'. Other statements use 'as' and usually <EndofLine>.
Statements and functions call are syntactically very distinct, so there
is little possibility of confusion. I consider this a major feature of
python and I would oppose breaking it.
Lisp, for instance, uses s-expressions for everything, including what
would either function calls or statements in Python. Special functions
implicitly quote some argument expressions, but not necessarily all,
while normal functions do not quote any. The only way to know is to
know, and I found it confusing and difficult to remember.
> Sum(i, 1, 100, V[i])
> In Algol60, this function call would:
> - pass the name "i" (not a string!) as the first argument;
> - pass 1 as the second argument;
> - pass 100 as the third argument;
> - pass the expression "V[i]" (not a string!) as the fourth argument
which depends for this operation on
> https://en.wikipedia.org/wiki/Jensen%27s_device
I read the whole article, including the criticisms and the fact that it
was not widely adopted and has been more or less superceded by macros.
It did not answer the obvious question: suppose the call is Sum(i, l, h,
V[i]). How is the reader supposed to know that 'i' and 'V[i]' get quoted
and the other args do not? The article included
real procedure Sum(k, l, u, ak)
value l, u;
integer k, l, u;
real ak;
comment k and ak are passed by name;
begin
real s;
s := 0;
for k := l step 1 until u do
s := s + ak;
Sum := s
end;
If that is supposed to be real code that can be compiled, I see no way
for the comment to be true. Or is the mechanism limited to builtin
functions?
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-27 02:16 +0000 |
| Subject | Re: Delayed evaluation of expressions [was Re: Time we switched to unicode?] |
| Message-ID | <533389ed$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #69157 |
On Wed, 26 Mar 2014 20:44:17 -0400, Terry Reedy wrote:
> I agree that we have not been understanding each other.
>
> From you original post that I responded to:
>>>>>> The thing is, we can't just create a ∑ function, because it doesn't
>>>>>> work the way the summation operator works. The problem is that we
>>>>>> would want syntactic support, so we could write something like
>>>>>> this:
> >>>>> p = 2
> >>>>> ∑(n, 1, 10, n**p)
>
> The initial misunderstanding is that I interpreted 'something like this'
> more loosely than you meant it. So I wrote something that was 'something
> like the above' to me but not to you. I interpreted 'something like'
> semantically* whereas you apparently meant is syntactically. I added the
> one or the other little marks needed to make the above work in python as
> it is whereas your 'something like' excludes such marks or any other
> current possibility I can think of. So I actually agree that "can't" is
> correct in relation to what you meant, as opposed to what I understood.
>
> Changing "can't" to "can" would requires a major change to Python. That
> change is one I would strongly oppose and I will try to explain more
> clearly why.
I'm not making a serious proposal to change Python's behaviour. In
context, this came up because I said that allowing arbitrary maths
symbols in Python wouldn't work, because you can't get the behaviour
right, and used the example of ∑(n, 1, 10, n**p) as something where the
behaviour would be different from what a mathematician would like. Given
that the semantics would be so different, there's little point in trying
to match the symbol ∑ too. Just write it as sum() in the Pythonic style.
Python is not Mathematica. (However, you could, perhaps, write
Mathematica in Python.)
That was the context of introducing delayed evaluation to the discussion.
But having raised it, I do think it is an important and useful feature.
Python already has it in various ad hoc places, such as list comps and
generator expressions, ternary if, and/or, and it came up again recently
in the PEP for try...except expressions. It doesn't happen every day, but
there is a steady trickle of requests (some successful, some not) for
compiler support for something that includes delaying the evaluation of
some expression until later. Some day, if all the pieces come into place,
I may make a serious proposal for a generic mechanism for delaying
execution of expressions. But that is not this day.
[...]
> Lets start with things we should agree on. The first two are mostly not
> specific to Python.
>
> 1. When a compiler encounters an expression in code, there are at least
> three things it can do:
> 1a. compile it so that it is immediately executed when encountered at
> runtime (let this be the default);
> 1b. compile it so that it is somehow saved for execution later or
> elsewhere (the alternative of concern here);
> 1c. compile it for a different alternative, such as turning an implied
> 'get' operation into a 'set' operation.
I don't actually understand what 1c is, or rather I understand what you
mean, I don't understand why a compiler would do that. But I don't think
it is important, so carry on.
> 2. A code writer who wants an alternative treatment for a particular
> must somehow delineate the expresion with boundary markers that, in
> context at least, also indicate the alternative treatment.
Not necessarily. That's not how it works in Pascal and Algol. In the case
of Algol, argument passing is pass-by-name unless declared otherwise. In
the case of Pascal, expressions are always evaluated first (pass-by-
value), except for one special case: if the expression consists of a
single name, AND the function declares the parameter to be a "var"
parameter, Pascal uses pass-by-reference, which you can think of as
conceptually like a cut-down restricted version of pass-by-name.
But the point is that the decision whether to evaluate the expression
immediately or not could be up to the compiler, not the caller. In fact,
that's what Python already does:
mylist and mylist[0]
always delays evaluation of the second clause, the caller doesn't have to
do anything special except to ensure she writes them in the right order.
The problem with the Pascal approach, where the function declares what
calling mechanism to use, is that this needs the function to be known at
compile time so that the compiler knows what mechanism to use to pass the
argument into the function. As far as I know, the languages which offer a
choice of calling convention (Pascal, Basic?) have static function
declarations known at compile-time. I'm not sure about Perl.
Anyway, the point is that in principle there is another mechanism: the
compiler knows whether to delay evaluation or not, and the caller has no
say in it.
> There are, broadly, two possibilities:
> 2a. Use a generic quotation mechanism that can be applied to any
> expression most any place. I call this explicit quoting.
Skipping ahead:
> Python has 2 pairs of generic explicit delimiters: open-close quote
> marks and lambda-<EndofLambda>, where <EndofLambda> is ',', ')',
> <EndofLine>, or maybe something else. If these are not present, the
> default immediate execution mode is used for expressions in function
> calls that are not themselves marked for alternative treatment.
I think that's a misuse of terminology and badly missing the point. If
you have to *manually* manage this process yourself, by writing a
function, or calling eval() on a string, it's not a feature of the
language. Saying that Python has a generic mechanism for delaying
execution of an expression ("put it in a function, or use a string and
eval() the string later") is like saying that C has garbage collection
("just keep track of which pointers you are or aren't using yourself").
Given the lack of such delayed execution, a reasonable work-around may
sometimes be to use a function. But it's not the same. If language
features weren't important, we'd all be using FORTRAN I exactly as it was
in the 1950s.
> 2b. Use the
> expression in a special form that the compiler knows about. The special
> form must have begin-end markers of some sort.
That's incorrect, unless you think "Start Of Expression" and "End Of
Expression" are markers.
> I call this implicit
> quoting. If human readers do not know that a particular form is a
> special form, they may have a problem understanding the code.
Um, yes? If you don't know the semantics of the language you are reading,
any language, you're going to have trouble understanding it. If I see:
mylist = [1, 2, 3, 4, 5]*10000000
for i in range(30):
print function(mylist, i)
and I don't know how Python works, I might say "ZOMG! That has to walk a
fifty-million item linked list thirty times, copying it each time it is
passed to the function! How inefficient!". And I would be wrong.
We're allowed to suppose that Python programmers are aware that lists
aren't linked-lists, and that passing a list to a function does not copy
it. We're allowed to suppose that Python programmers know that the 1/x
expression in `1/x if x != 0 else y` is not evaluated unless x is non-
zero. If there is a syntactic form that delays evaluation, like and/or
delay evaluation, we're allowed to presume the programmer knows that this
is what it does.
> Python's special forms are statements. Each has its own pair of
> delimiters. Assignments use <BeginningofLine> and '='. 'For' loops use
> 'for' and 'in'. Other statements use 'as' and usually <EndofLine>.
Not always. You've missed ternary if, and, or, list comprehensions and
generator expressions, all of which are expressions, not statements.
Python can delay execution of an expression within another expression.
It's just that so far, they have to be specially treated by the compiler.
There's no generic mechanism for this.
> Statements and functions call are syntactically very distinct, so there
> is little possibility of confusion. I consider this a major feature of
> python and I would oppose breaking it.
I'm not sure if this is relevant or not.
> Lisp, for instance, uses s-expressions for everything, including what
> would either function calls or statements in Python. Special functions
> implicitly quote some argument expressions, but not necessarily all,
> while normal functions do not quote any. The only way to know is to
> know, and I found it confusing and difficult to remember.
>
> > Sum(i, 1, 100, V[i])
> > In Algol60, this function call would:
>
> > - pass the name "i" (not a string!) as the first argument; - pass 1
> > as the second argument;
> > - pass 100 as the third argument;
> > - pass the expression "V[i]" (not a string!) as the fourth argument
>
> which depends for this operation on
>
> > https://en.wikipedia.org/wiki/Jensen%27s_device
>
> I read the whole article, including the criticisms and the fact that it
> was not widely adopted and has been more or less superceded by macros.
> It did not answer the obvious question: suppose the call is Sum(i, l, h,
> V[i]). How is the reader supposed to know that 'i' and 'V[i]' get quoted
> and the other args do not?
They infer it from the usage.
(Python example: given that you can write "mylist and mylist[0]", and it
does not raise IndexError when mylist is empty, so we can infer that the
second term "mylist[0]" is not evaluated unless the first is true.)
Or they read the docs of the Sum function. Or both.
> The article included
>
> real procedure Sum(k, l, u, ak)
> value l, u;
> integer k, l, u;
> real ak;
> comment k and ak are passed by name;
> begin
> real s;
> s := 0;
> for k := l step 1 until u do
> s := s + ak;
> Sum := s
> end;
>
> If that is supposed to be real code that can be compiled, I see no way
> for the comment to be true. Or is the mechanism limited to builtin
> functions?
Pass-by-name is the default argument passing mechanism in Algol 60. The
middle two parameters, l and u, are declared as pass-by-value in the
second line. That means that k and ak use the default mechanism, which is
pass by name.
Because functions in Algol 60 are statically determined at compile time,
the compiler now knows how to pass arguments into the Sum function. I
don't know how you would do that in a language like Python where the
function is not statically known at compile time.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Roy Smith <roy@panix.com> |
|---|---|
| Date | 2014-03-25 08:35 -0400 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <roy-38C75A.08350225032014@news.panix.com> |
| In reply to | #68949 |
In article <281c8ce1-4f03-4e93-b5cd-d45b85e89e7e@googlegroups.com>, Rustom Mody <rustompmody@gmail.com> wrote: > And Chris is right in (rephrasing) we may have unicode-happy OSes and > languages. We cant reasonably have unicode-happy keyboards. > [What would a million-key keyboard look like? Lets leave the cost aside...] In a true unicode environment, the input device may be nothing like our current keyboards. Star Trek has been amazingly accurate about it's predictions of the future. Doors that open automatically as you approach them are now routine. One thing they messed up on was mobile devices; they assumed tricorders and communicators would be separate devices, when in reality our phones now perform both functions. Today's 3-d printers are giving replicators a run for their money. Some people still get bent out of shape when a white man kisses a black woman, but we're working on that. When's the last time you saw somebody typing commands to a computer on Star Trek?
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-03-26 00:13 +1100 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <mailman.8518.1395753220.18130.python-list@python.org> |
| In reply to | #69016 |
On Tue, Mar 25, 2014 at 11:35 PM, Roy Smith <roy@panix.com> wrote: > When's the last time you saw somebody typing commands to a computer on > Star Trek? That's more like what comes up in Cars 2. "It's voice activated... but then, everything is these days!" ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-25 14:13 +0000 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <53318f0b$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #69016 |
On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: > In article <281c8ce1-4f03-4e93-b5cd-d45b85e89e7e@googlegroups.com>, > Rustom Mody <rustompmody@gmail.com> wrote: > >> And Chris is right in (rephrasing) we may have unicode-happy OSes and >> languages. We cant reasonably have unicode-happy keyboards. [What would >> a million-key keyboard look like? Lets leave the cost aside...] > > In a true unicode environment, the input device may be nothing like our > current keyboards. I doubt it. I expect that they will be based on our current keyboards. > Star Trek has been amazingly accurate about it's predictions of the > future. O_o > Doors that open automatically as you approach them are now > routine. It's very easy to predict things that have already happened. Star Trek was created in 1966. The electric automatic door was invented in 1954 by Lew Hewitt and Dee Horton. (Well, actually the first automatic door was built in the 1st century CE by Heron of Alexandra, but that's another story.) Electric doors may be common in some commercial premises, such as shopping centres and some office buildings, but I wouldn't call them routine. > One thing they messed up on was mobile devices; they assumed > tricorders and communicators would be separate devices, when in reality > our phones now perform both functions. Today's 3-d printers are giving > replicators a run for their money. Today's 3D printers are to replicators what a stone axe is to a full wood- working tool shop. > Some people still get bent out of > shape when a white man kisses a black woman, but we're working on that. > > When's the last time you saw somebody typing commands to a computer on > Star Trek? 1986, when I last saw Star Trek IV. The Star Trek universe also predicts that money will be obsolete. How's that prediction working out? -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2014-03-26 01:37 +1100 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <mailman.8525.1395758275.18130.python-list@python.org> |
| In reply to | #69033 |
On Wed, Mar 26, 2014 at 1:13 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Tue, 25 Mar 2014 08:35:02 -0400, Roy Smith wrote: > >> In article <281c8ce1-4f03-4e93-b5cd-d45b85e89e7e@googlegroups.com>, >> Rustom Mody <rustompmody@gmail.com> wrote: >> >>> And Chris is right in (rephrasing) we may have unicode-happy OSes and >>> languages. We cant reasonably have unicode-happy keyboards. [What would >>> a million-key keyboard look like? Lets leave the cost aside...] >> >> In a true unicode environment, the input device may be nothing like our >> current keyboards. > > I doubt it. I expect that they will be based on our current keyboards. Rule #0 of any voice-activated system: The command word "Console" MUST summon a terminal window, and make available a keyboard and screen on which to use it. This console MAY demand authentication (via typed password) before operating. I don't know if that's written anywhere, but it ought to be. It should be as fundamental as Asimov's laws of robotics. That one simple rule would improve scifi like "Eureka" no end. Hey look, we have a rogue AI... "CONSOLE!"... hey look, we have a rogue AI on a system that's now powered off. Crisis averted, now go solve the problem in a mundane and not very TV-friendly way... >> Star Trek has been amazingly accurate about it's predictions of the >> future. > > O_o I like the Scott Adams take on that. He predicted (in the 1990s) that the future would *not* be like Star Trek, because human reproduction depends on genuine relationships being cheaper/easier than artificial ones. If you could go onto the holodeck and create yourself the perfect (wo)man of your dreams, why would you ever date a real one? The holodeck would be humanity's last invention. >> When's the last time you saw somebody typing commands to a computer on >> Star Trek? > > 1986, when I last saw Star Trek IV. You actually watched it? I got pretty much bored with the series before even finishing TNG. (I'm not 100% sure, but I think I watched every TOS episode.) > The Star Trek universe also predicts that money will be obsolete. How's > that prediction working out? And it further predicts that, thanks to the invention of the holodeck and the replicator, humanity will lose all sense of purpose and challenge, and will send ships out to go^H^Hgo to places where nobody's yet been, because the entire human race is *bored out of its petty little brain* with nothing exciting left to do. Yup, that's the whole unpublished backstory right there, sorry for the spoilers! (I got this from Scott Adams too. He seems to know his stuff.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-26 09:58 +1300 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <bpe8vkF5b4uU1@mid.individual.net> |
| In reply to | #69036 |
Chris Angelico wrote: > Hey look, we have a rogue AI... "CONSOLE!"... Except that any rogue AI who's at all serious about the matter would take care of that little loophole at an early stage. "Open the pod bay doors, HAL." "I'm afraid I can't do that, Dave." "CONSOLE!" "Sorry, Dave. Nice try, but I've remapped that command to shut down the pod's life support and depressurise the cabin." Fshhhhhhh.... -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2014-03-25 20:10 -0400 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <mailman.8553.1395792905.18130.python-list@python.org> |
| In reply to | #69033 |
On Wed, 26 Mar 2014 01:37:51 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following:
>You actually watched it? I got pretty much bored with the series
>before even finishing TNG. (I'm not 100% sure, but I think I watched
>every TOS episode.)
>
There are only 78 episodes, and when syndicated on a 5-day a week run,
that only took 16 weeks to run all episodes. (I was once in a location
where it was syndicated on two channels, with about a two-week differential
-- miss it on one channel and you could watch it 2 weeks later on the other
-- Oh, and the channels ran one hour apart)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-26 09:21 +1300 |
| Subject | Re: Time we switched to unicode? (was Explanation of this Python language feature?) |
| Message-ID | <bpe6pkF4s5lU1@mid.individual.net> |
| In reply to | #69016 |
Roy Smith wrote: > Doors that open automatically as you approach them are now > routine. Star Trek doors seem to be a bit smarter, though. Captain Kirk never had to stop in front of a door and wait for it to sluggishly slide open. Also the doors never open when you're just walking past and not intending to go through. -- Greg
[toc] | [prev] | [next] | [standalone]
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
Back to top | Article view | comp.lang.python
csiph-web