Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #111760 > unrolled thread
| Started by | Kent Tong <kent.tong.mo@gmail.com> |
|---|---|
| First post | 2016-07-22 08:33 -0700 |
| Last post | 2016-07-26 16:31 +0200 |
| Articles | 20 on this page of 258 — 33 participants |
Back to article view | Back to comp.lang.python
Why not allow empty code blocks? Kent Tong <kent.tong.mo@gmail.com> - 2016-07-22 08:33 -0700
Re: Why not allow empty code blocks? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-22 16:44 +0000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-23 11:49 +1000
Re: Why not allow empty code blocks? Kent Tong <kent.tong.mo@gmail.com> - 2016-07-22 19:06 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 14:13 +0300
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-23 21:34 +1000
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 14:49 +0300
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-23 15:00 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 00:19 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 10:58 +0200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 07:14 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-29 14:15 +0100
Re: Why not allow empty code blocks? Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-29 07:41 -0600
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-29 23:43 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 15:55 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 00:38 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 20:32 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 13:49 +1000
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-02 09:31 +0200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 12:28 -0400
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-29 12:20 -0400
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-29 15:46 +0200
Re: Why not allow empty code blocks? Terry Reedy <tjreedy@udel.edu> - 2016-07-29 15:43 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-29 21:19 +0100
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-30 01:01 +0300
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 13:35 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 11:15 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 21:25 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 04:39 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 21:49 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 05:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:22 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 05:31 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:44 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 01:07 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 13:39 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:47 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:47 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 13:27 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 22:34 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 00:58 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 00:47 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:15 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:29 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 03:53 +1000
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-30 12:16 -0600
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 13:37 +1200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 19:34 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 13:14 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 20:34 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:12 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 23:42 -0700
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-30 22:10 -0700
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 19:39 +1200
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-31 10:51 +0300
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 01:18 -0700
Re: Why not allow empty code blocks? Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-31 06:51 -0600
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 09:23 -0700
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 01:14 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 03:06 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 10:32 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 02:37 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 09:58 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 03:15 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-30 10:48 -0700
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 13:45 +1200
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 12:17 +1000
Procedures and functions [was Re: Why not allow empty code blocks?] Steven D'Aprano <steve@pearwood.info> - 2016-07-31 13:32 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 00:01 -0400
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Steven D'Aprano <steve@pearwood.info> - 2016-07-31 16:40 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Rustom Mody <rustompmody@gmail.com> - 2016-07-30 23:47 -0700
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Chris Angelico <rosuav@gmail.com> - 2016-07-31 16:55 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:05 +1000
Re: Procedures and functions [was Re: Why not allow empty code blocks?] Random832 <random832@fastmail.com> - 2016-07-31 00:26 -0400
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-30 23:51 -0400
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:21 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 21:22 +0100
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-02 12:30 +0200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-02 05:29 -0700
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-08-03 10:26 +0200
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 04:48 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:09 +0300
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:23 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:27 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:37 +0300
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:43 -0700
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-03 15:34 +0300
{non sequitur/bad humor} was: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-08-03 18:01 -0400
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:43 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-30 23:06 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-30 23:36 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 14:58 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 01:48 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 02:34 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 19:46 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 12:10 +1000
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-30 23:41 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-31 11:18 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 01:31 +1000
Re: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-31 12:39 -0400
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 17:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 10:21 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 17:55 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 11:10 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 19:09 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 12:14 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 00:55 -0700
Re: Why not allow empty code blocks? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-07-31 22:08 -0400
Re: Why not allow empty code blocks? Gene Heskett <gheskett@shentel.net> - 2016-07-31 21:29 -0400
Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-07-31 14:58 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 12:05 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 00:58 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 18:12 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:57 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 20:14 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-03 15:43 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-03 11:16 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:18 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+python@pearwood.info> - 2016-08-04 13:23 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-04 10:13 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-04 19:39 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-04 19:38 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-08-04 14:37 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-05 04:54 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 05:18 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Christian Gollwitzer <auriocus@gmx.de> - 2016-08-02 21:55 +0200
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-03 06:50 +1000
Re: Debugging (was Re: Why not allow empty code blocks?) Terry Reedy <tjreedy@udel.edu> - 2016-08-02 17:27 -0400
Re: Debugging (was Re: Why not allow empty code blocks?) Paul Rubin <no.email@nospam.invalid> - 2016-08-02 14:54 -0700
Re: Debugging (was Re: Why not allow empty code blocks?) BartC <bc@freeuk.com> - 2016-08-02 23:38 +0100
Re: Debugging (was Re: Why not allow empty code blocks?) Chris Angelico <rosuav@gmail.com> - 2016-08-01 05:03 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 15:12 +1200
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-31 14:07 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 15:16 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:08 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-31 02:10 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-31 15:10 +1200
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-30 10:39 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 16:14 +0100
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-30 13:11 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-30 19:15 +0100
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-01 00:25 +1000
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 11:53 -0400
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-03 23:38 +1000
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-31 12:04 -0400
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-07-31 09:27 -0700
Re: Why not allow empty code blocks? Gordon Levi <gordon@address.invalid> - 2016-08-02 01:30 +1000
Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:05 -0400
Re: Using valid emails Chris Angelico <rosuav@gmail.com> - 2016-08-02 02:22 +1000
Re: Using valid emails Marko Rauhamaa <marko@pacujo.net> - 2016-08-01 22:16 +0300
Re: Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:40 -0400
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-08-01 22:14 +0300
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-31 19:41 +0300
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-08-01 03:22 +1000
Re: Why not allow empty code blocks? "Jan Erik Moström" <lists@mostrom.pp.se> - 2016-07-31 20:58 +0200
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-31 14:01 -0600
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 16:43 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 09:49 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-07-31 17:21 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-01 10:33 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 01:05 -0700
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-01 09:50 +0000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 06:26 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-01 20:12 +1000
Re: Why not allow empty code blocks? bart4858@gmail.com - 2016-08-01 06:19 -0700
Re: Why not allow empty code blocks? bartc <bart4858@gmail.com> - 2016-08-01 13:22 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-02 06:28 -0700
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-02 17:56 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:54 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 05:10 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-02 20:19 +0100
Re: Why not allow empty code blocks? Grant Edwards <grant.b.edwards@gmail.com> - 2016-08-02 19:38 +0000
Re: Why not allow empty code blocks? lists@juliensalort.org (Julien Salort) - 2016-08-02 21:45 +0200
Re: Why not allow empty code blocks? Steven D'Aprano <steve+python@pearwood.info> - 2016-08-03 03:50 +1000
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-08-02 12:22 -0700
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 03:02 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-08-03 18:58 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-08-03 05:16 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 22:36 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 14:04 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:25 +1000
Re: Why not allow empty code blocks? Grant Edwards <grant.b.edwards@gmail.com> - 2016-08-03 14:06 +0000
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-03 20:40 +0000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 14:23 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-03 23:31 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 19:52 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 06:12 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 21:53 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 07:39 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-03 23:21 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-08-04 08:31 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-04 00:51 +0100
Re: Why not allow empty code blocks? Paul Rubin <no.email@nospam.invalid> - 2016-08-03 16:25 -0700
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-08-04 00:48 +0100
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-08-01 09:40 +0000
Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 12:32 -0400
Re: Using valid emails Michael Torrie <torriem@gmail.com> - 2016-08-01 12:38 -0600
Re: Using valid emails "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-08-01 15:27 -0400
Re: Why not allow empty code blocks? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-07-28 20:01 +0000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-29 06:11 +1000
Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Rustom Mody <rustompmody@gmail.com> - 2016-07-23 05:28 -0700
Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 11:15 +0100
Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) Rustom Mody <rustompmody@gmail.com> - 2016-07-24 07:49 -0700
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-23 08:29 -0400
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-23 16:13 +0300
Re: Why not allow empty code blocks? "D'Arcy J.M. Cain" <darcy@Vex.Net> - 2016-07-23 09:54 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-23 15:06 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-24 01:55 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 11:35 +0100
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 11:45 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 21:27 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 14:09 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 23:24 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 15:05 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 00:32 +1000
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-25 12:40 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 02:14 +0100
Re: Why not allow empty code blocks? Ben Finney <ben+python@benfinney.id.au> - 2016-07-25 11:45 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 09:54 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-26 03:02 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 10:11 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-26 03:26 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-25 19:43 -0700
Re: Why not allow empty code blocks? Michael Torrie <torriem@gmail.com> - 2016-07-24 20:48 -0600
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 13:12 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 20:20 -0700
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 13:28 +1000
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 20:46 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-25 17:20 +1000
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 14:27 +1000
Re: Why not allow empty code blocks? neceros@gmail.com - 2016-07-24 11:27 -0700
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-24 22:17 +1000
Re: Why not allow empty code blocks? Joel Goldstick <joel.goldstick@gmail.com> - 2016-07-24 08:28 -0400
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 22:48 +1000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-24 23:38 +1000
Re: Why not allow empty code blocks? Marco Sulla <mail.python.org@marco.sulla.e4ward.com> - 2016-07-24 15:11 +0200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 15:44 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 00:51 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 19:14 +0100
Re: Why not allow empty code blocks? Jonathan Hayward <jonathan.hayward@pobox.com> - 2016-07-24 13:34 -0500
Re: Why not allow empty code blocks? alister <alister.ware@ntlworld.com> - 2016-07-24 18:52 +0000
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 05:00 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 21:03 +0100
Re: Why not allow empty code blocks? Chris Angelico <rosuav@gmail.com> - 2016-07-25 07:08 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-24 23:13 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-25 13:04 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 10:44 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 19:21 +1200
Re: Why not allow empty code blocks? Marko Rauhamaa <marko@pacujo.net> - 2016-07-26 10:56 +0300
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 20:35 +1200
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-26 11:11 +0100
Re: Why not allow empty code blocks? Steven D'Aprano <steve@pearwood.info> - 2016-07-25 12:37 +1000
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 11:39 +0100
Re: Why not allow empty code blocks? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-07-26 19:23 +1200
Re: Why not allow empty code blocks? Random832 <random832@fastmail.com> - 2016-07-25 10:36 -0400
Re: Why not allow empty code blocks? BartC <bc@freeuk.com> - 2016-07-25 18:33 +0100
Re: Why not allow empty code blocks? Rustom Mody <rustompmody@gmail.com> - 2016-07-24 17:56 -0700
Re: Why not allow empty code blocks? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-07-26 16:31 +0200
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 00:58 +1000 |
| Message-ID | <579cc090$0$1617$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112059 |
On Sat, 30 Jul 2016 10:27 pm, BartC wrote: > This is one thing I can never get right in Python: controlling when a > newline is or isn't generated and what happens with separators. In Python 3, that's easy: the default space separator and newline at the end can both be customized to any string you like: print(x, y, z, sep=' +++ ', end='\n\tEND\n') individually or together, including the empty string: print(x, y, z, sep='\n', end='') And naturally, since these are just ordinary function arguments, they are restricted to constant literals. They can be variables or expressions: print(x, y, z, end=(get_output_end() or OUTPUT_END)) [...] > (Some languages use 'write' or 'writeln', or 'print' or 'println'; what > could be simpler? Or you just explicitly output a "\n" string.) One function is simpler than two, so print() with explicit keyword arguments is obviously simpler AND more powerful. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 00:47 +1000 |
| Message-ID | <579cbded$0$1605$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112053 |
On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote:
> On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote:
>> On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote:
>> > Anyway, if you're going to talk about annoying things forced upon you
>> > by the language, what about:
>> >
>> > "()" in "print (x)" for Python 3
>>
>> Why are you singling out print? It's just a function like any other.
>> Are you complaining about the way function calls need parentheses?
>
> Its a function… ok.
> Its ‘just’ a function… Arguable
"Granny Weatherwax, you are a natural-born disputant."
"I ain't!"
> For example:
>
> - Prior Art: Its builtin and special in Fortran, Pascal, Basic
Possibly Fortran. But which version of Fortran? Do we really want to take
decisions made in 1953 for the first ever high-level language as the
epitome of good design?
Pascal? There is no "print" in standard Pascal, there are a pair of
procedures writeln() and write().
Early BASIC has a built-in print statement, but BASIC had very little
facility for functions or procedures. *Every* built-in command
was "special" to a language where you used GOTO and GOSUB instead of
functions.
And in any case, Python's print is a built-in, so it is *just as special* as
Fortran, Pascal and BASIC versions.
> - More immediate : It was a special in python2
It was *too* special in Python 2.
Being a statement, there's nothing you can do with it except use it
directly. You can't pass it to another function, or use it as a callback,
or apply functools.partial to it, or monkeypatch it. When people proposed
adding new functionality to it, the ability to print to a file, instead of
adding a simple keyword argument, the actual grammar of the language had to
be changed to support a hideously ugly variant:
print >>file, args
If Python had originally been a function, and somebody proposed making it a
statement, what do you think the chances are that proposal would be
accepted? Some design decisions are simply bad ideas, and making print a
statement was one of them.
> - Poorer error catching: What was a straight syntax error is now a
> lint-catch (at best)
> [print (x) for x in range(20)]
Using a list comprehension just for the side effects is *poor practice* but
legal. Besides, perhaps print() has been monkey-patched to return a useful
value, which you wish to collect in a list.
Its not the compiler's job to decide what is and isn't good code. There are
an infinite number of things a programmer can do which is "poor practice".
Should we try to make them all syntax errors?
# Calculate x plus ten.
y = x + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y + 1
y = y - 1 # Oops, we went too far, go back one.
Should we insist that Python must have a "add 10" statement, and forbid the
plus operator, so that poor quality code like the above will be a syntax
error?
# new and improved special syntax
addten x as y
print never should have been a statement. Being a built-in function is
special enough.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 09:15 -0700 |
| Message-ID | <758a1961-00bc-4b1c-834b-a7deca94d029@googlegroups.com> |
| In reply to | #112075 |
On Saturday, July 30, 2016 at 8:17:19 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote:
>
> > On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote:
> >> On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote:
> >> > Anyway, if you're going to talk about annoying things forced upon you
> >> > by the language, what about:
> >> >
> >> > "()" in "print (x)" for Python 3
> >>
> >> Why are you singling out print? It's just a function like any other.
> >> Are you complaining about the way function calls need parentheses?
> >
> > Its a function… ok.
> > Its ‘just’ a function… Arguable
>
> "Granny Weatherwax, you are a natural-born disputant."
> "I ain't!"
Heh I really aint :D
At least not for this dispute — its not my baby
Or rather its a stepbaby of stepbaby
Diff between
print "x"
and
print("x")
is one char — the closing ‘)’
To make a dispute about that — I’ll leave to BartC!
The more general baby that is significant is that beginners should have
it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being
absent is a much more significant problem (for beginners) than print.
Brings me to the even more general baby
>
>
> > For example:
> >
> > - Prior Art: Its builtin and special in Fortran, Pascal, Basic
>
> Possibly Fortran. But which version of Fortran? Do we really want to take
> decisions made in 1953 for the first ever high-level language as the
> epitome of good design?
That comment assumes that things in 1953 were somehow worse than today
This is the general religious commitment to progress
And anyone who questions it is heretical
As for 1953 Ive no idea — I was not there (Fortran came in 57)
But I studied in the 80s and there was greater clarity (about some matters
of course) than now.
eg It was completely natural that in ‘school’ one studied
‘nice’ things like Pascal, Lisp, Prolog, Snobol, APL etc
And in a professional context used ‘real’ things like
Fortran, Cobol, PL-1 and a little later C.
Once omnibus languages like C++, Java, C# and Python became popular
the academic vs real-world division has disappeared.
So beginners start with these ‘real-world’
And get their brains scrambled
And think it wonderful
Ok Python is better than Java is better than C++
But it cannot stand up to scheme as a teaching language
[The MIT Profs who replaced scheme by python admit to as much viz.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 09:29 -0700 |
| Message-ID | <3dda684a-0de2-4942-bb22-728a18d46fae@googlegroups.com> |
| In reply to | #112083 |
On Saturday, July 30, 2016 at 9:45:34 PM UTC+5:30, Rustom Mody wrote: > Ok Python is better than Java is better than C++ > But it cannot stand up to scheme as a teaching language > [The MIT Profs who replaced scheme by python admit to as much viz. Send pressed prematurely — Sorry MIT on practical reasons for python over scheme: https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python Berkeley on fundamental reasons for the opposite choice: https://people.eecs.berkeley.edu/~bh/proglang.html
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 03:53 +1000 |
| Message-ID | <579ce9b8$0$1616$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112086 |
On Sun, 31 Jul 2016 02:29 am, Rustom Mody wrote: > MIT on practical reasons for python over scheme: > https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python > Berkeley on fundamental reasons for the opposite choice: > https://people.eecs.berkeley.edu/~bh/proglang.html Not a very useful discussion. His argument basically boils down to: "Lisp came up with some good ideas that were copied by other languages. Therefore Lisp is a good teaching language." -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-07-30 12:16 -0600 |
| Message-ID | <mailman.59.1469902583.6033.python-list@python.org> |
| In reply to | #112094 |
On 07/30/2016 11:53 AM, Steven D'Aprano wrote: > On Sun, 31 Jul 2016 02:29 am, Rustom Mody wrote: > >> MIT on practical reasons for python over scheme: >> > https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python >> Berkeley on fundamental reasons for the opposite choice: >> https://people.eecs.berkeley.edu/~bh/proglang.html > > Not a very useful discussion. His argument basically boils down to: > > "Lisp came up with some good ideas that were copied by other languages. > Therefore Lisp is a good teaching language." Maybe. Lisp and Scheme are great languages to teach the theory of programming with because they are so easy to use to build DSLs (all within the same syntax as Lisp), and it kind of acts like a meta-language. I'll never use Scheme again in my life, but I'm very glad to have learned it in my Theory of Programming Languages course at uni. Python would have been alright to teach "programming," but to teach the actual theory of programming languages (lambda calculus, lists as a foundation unit for all other data structures), Scheme was an ideal choice for teaching these fundamentals. The continued confusion that pops up on the list from new users on how Python variables work wouldn't be an issue if they came from a Scheme background. The idea of names and binding of names would make perfect sense to them. I remember using Scheme the class to build a full object-oriented language out of Scheme parts. Was pretty interesting to create your own syntactic sugar right in the language itself. I think they use a version of Scheme called Racket now.
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-31 13:37 +1200 |
| Message-ID | <e0532pF9hi4U1@mid.individual.net> |
| In reply to | #112096 |
Michael Torrie wrote: > Python would have been alright to teach "programming," but to > teach the actual theory of programming languages (lambda calculus, lists > as a foundation unit for all other data structures) I wouldn't say that "lists as a foundation unit for all other data structures" is (or should be) part of the fundamental theory of programming languages. It seems to me that Python's notions of sequences and mappings are much more general and elegant theoretical elements to build on. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 19:34 -0700 |
| Message-ID | <054d829c-1b1b-4b8b-98de-56c7a8ab7a6f@googlegroups.com> |
| In reply to | #112104 |
On Sunday, July 31, 2016 at 7:07:45 AM UTC+5:30, Gregory Ewing wrote:
> Michael Torrie wrote:
> > Python would have been alright to teach "programming," but to
> > teach the actual theory of programming languages (lambda calculus, lists
> > as a foundation unit for all other data structures)
>
> I wouldn't say that "lists as a foundation unit for all other
> data structures" is (or should be) part of the fundamental theory
> of programming languages.
>
> It seems to me that Python's notions of sequences and mappings
> are much more general and elegant theoretical elements to build
> on.
A key component of a fundamental theory of computation is the idea of
a universal data structure.
For a turing machine its the tape that can carry data or another TM to make
a UTM (UNIVERSAL turing machine)
For a von Neumann machine its the memory that is impartial to whether its
holding data or code (as against Harvard architecture)
https://en.wikipedia.org/wiki/Harvard_architecture#Contrast_with_von_Neumann_architectures
For Gödel's theorem it is humonguous integers which can ‘carry’ plain ol’
integers or theorems, proofs and effectively ‘the whole world’ via the
Gödel-numbering:
https://en.wikipedia.org/wiki/G%C3%B6del_numbering
At the other end of the spectrum is Lisp whose S-expression is likewise
universal and can be effectively used for carrying the whole theory much more
elegantly than Turing more elegantly than Gödel:
http://www.diku.dk/~neil/comp2book2007/book-whole.pdf
From a software engineering pov, yes one can encode any data structure as
arbitrary length integers. It works as data structure but its a horrible.
This is the Gödel approach
By cutting up the humonguous number into small squares on a tape, Turing’s
approach is more tractable. Its still clumsy because it requires parsing.
Structure the tape as a tree and this nuisance vanishes.
This Lisp/S-exp/Neil-Jones cleanest of all solutions is like everything else in
our field least known.
Of course one could argue that mapping is somehow more universal than list.
[I have often pondered this question]
ie one can represent
[a,b,c]
as
{0:a, 1:b, 2:c}
Still, whatever is chosen, one needs one single data structure (or more
correctly data type) to carry the whole world.
Lists PLUS Mappings will not do
[Note I am not talking software engineering but requirements for a complete theory]
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 13:14 +1000 |
| Message-ID | <579d6cfa$0$22142$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112096 |
On Sun, 31 Jul 2016 04:16 am, Michael Torrie wrote:
> On 07/30/2016 11:53 AM, Steven D'Aprano wrote:
>> On Sun, 31 Jul 2016 02:29 am, Rustom Mody wrote:
>>
>>> MIT on practical reasons for python over scheme:
>>>
>>
https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python
>>> Berkeley on fundamental reasons for the opposite choice:
>>> https://people.eecs.berkeley.edu/~bh/proglang.html
>>
>> Not a very useful discussion. His argument basically boils down to:
>>
>> "Lisp came up with some good ideas that were copied by other languages.
>> Therefore Lisp is a good teaching language."
>
> Maybe. Lisp and Scheme are great languages to teach the theory of
> programming with because they are so easy to use to build DSLs (all
> within the same syntax as Lisp), and it kind of acts like a
> meta-language.
Doesn't sound like a good teaching language to me.
Meta-reasoning is harder than regular reasoning. That's why metaclasses are
harder to use than ordinary classes. Beginners have trouble enough learning
even simple features of languages, and you want to drop them straight into
meta-languages as their first taste of programming?
I suspect that Lisp/Scheme would make a really good *third* language. Or
even fourth.
> I'll never use Scheme again in my life, but I'm very
> glad to have learned it in my Theory of Programming Languages course at
> uni. Python would have been alright to teach "programming," but to
> teach the actual theory of programming languages (lambda calculus, lists
> as a foundation unit for all other data structures), Scheme was an ideal
> choice for teaching these fundamentals.
People misuse language. You say that scheme was "ideal". That literally
means that there is *not one single thing* about Scheme that isn't PERFECT
for the task, that it reaches a faultless standard of perfection lacking
all weaknesses. That's much stronger than saying "Scheme is the best
language for...", and much stronger than saying "nothing will ever be
better". It's saying that nothing *could* be better, because perfection has
been reached.
(Yes yes, I know you don't actually mean that, not literally. I'm making a
rhetorical point.)
Let's look at some problems with Scheme:
- For starters, there's the whole parentheses thing. While its true that
people claim[1] that the experienced Schemer or Lisper stops seeing them,
beginners and students are possibly five or ten years away from being
experienced Schemers. In the meantime, all those nested parentheses hurt
legibility and code comprehension.
- And then there's the use of prefix order of terms (Polish notation). For
the beginner, having to learn in prefix notation instead of infix notation
(which comes much more easily to English speakers) is a major problem.
- Writing DSLs is not something that ought to be encouraged, or at least not
required. DSLs impose a maintenance burden: you know have to learn both the
DSL and the metalanguage it is written in. One needs to be wary of going
there without a good reason.
It has always perplexed me that Lisp's prefix notation is held up as
the /sine qua non/ of elegance and power, while Forth is ignored if not
ridiculed. Forth is just as expressive as Lisp, just as meta, just as
customizable. You can create your own syntax in Forth. Forth doesn't have
macros, because it doesn't need them: you have complete control of what is
compiled and what is interpreted and when.
Perhaps it is because Lisp started as an academic language in the computer
science department, invented by people who knew all the right terms from
formal and complex mathematics (the parts they don't teach undergraduates)
while Forth was merely a practical language invented to control telescopes,
by an astronomer. Perhaps it is because the most popular Forth book
("Starting Forth" by Leo Brodie) shamelessly and intentionally
anthropomorphised the Forth interpreter in order to make it more accessible
to non-academics, while Lisp/Scheme are elitist languages used by elite
academics who, for the most part, would probably stop using Lisp/Scheme if
they became popular outside of university again.
I maintain that Forth would be a better meta-language than Lisp. If you're
going to require students to learn to think using a grammar which isn't OVS
or SVO (i.e. infix) then it seems to me that postfix with a stack is easier
to learn than prefix with parentheses.
> The continued confusion that
> pops up on the list from new users on how Python variables work wouldn't
> be an issue if they came from a Scheme background. The idea of names
> and binding of names would make perfect sense to them.
Of course. But that's because they would have suffered the same confusion
when learning Scheme, and got past it by their second language, Python.
[1] I'm choosing this word carefully. People claim all sorts of things.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 20:34 -0700 |
| Message-ID | <9853172b-f7a0-4070-97ea-1d5c2120eb6d@googlegroups.com> |
| In reply to | #112111 |
On Sunday, July 31, 2016 at 8:44:13 AM UTC+5:30, Steven D'Aprano wrote: > It has always perplexed me that Lisp's prefix notation is held up as > the /sine qua non/ of elegance and power, while Forth is ignored if not > ridiculed. Forth is just as expressive as Lisp, just as meta, just as > customizable. You can create your own syntax in Forth. Forth doesn't have > macros, because it doesn't need them: you have complete control of what is > compiled and what is interpreted and when. > > I maintain that Forth would be a better meta-language than Lisp. If you're > going to require students to learn to think using a grammar which isn't OVS > or SVO (i.e. infix) then it seems to me that postfix with a stack is easier > to learn than prefix with parentheses. That may well be In principle just flip (f x y) to x y f and we get from Lisp to Forth (or postscript) In practice people have taken the pains to work out much of the theory of CS in Lisp. Has it been done in Forth?? Maybe… Dunno… > On Sun, 31 Jul 2016 04:16 am, Michael Torrie wrote: > > I'll never use Scheme again in my life, but I'm very > > glad to have learned it in my Theory of Programming Languages course at > > uni. Python would have been alright to teach "programming," but to > > teach the actual theory of programming languages (lambda calculus, lists > > as a foundation unit for all other data structures), Scheme was an ideal > > choice for teaching these fundamentals. > > People misuse language. You say that scheme was "ideal". That literally > means that there is *not one single thing* about Scheme that isn't PERFECT > for the task, that it reaches a faultless standard of perfection lacking > all weaknesses. As usual you are making up definitions and being ridiculous. In most common usage ‘ideal’ is used as opposed to ‘real’ > That's much stronger than saying "Scheme is the best > language for...", and much stronger than saying "nothing will ever be > better". It's saying that nothing *could* be better, because perfection has > been reached. > > (Yes yes, I know you don't actually mean that, not literally. I'm making a > rhetorical point.) Good to know. But its not clear what the point is. Michael said Lisp is ideal FOR TEACHING <some list of topics> > > > > The continued confusion that > > pops up on the list from new users on how Python variables work wouldn't > > be an issue if they came from a Scheme background. The idea of names > > and binding of names would make perfect sense to them. > > Of course. But that's because they would have suffered the same confusion > when learning Scheme, and got past it by their second language, Python. That’s because variables are first class in lisp and neither-fish-nor-foul class in python
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 14:12 +1000 |
| Message-ID | <mailman.68.1469938372.6033.python-list@python.org> |
| In reply to | #112114 |
On Sun, Jul 31, 2016 at 1:34 PM, Rustom Mody <rustompmody@gmail.com> wrote: > to >> > teach the actual theory of programming languages (lambda calculus, lists >> > as a foundation unit for all other data structures), Scheme was an ideal >> > choice for teaching these fundamentals. >> >> People misuse language. You say that scheme was "ideal". That literally >> means that there is *not one single thing* about Scheme that isn't PERFECT >> for the task, that it reaches a faultless standard of perfection lacking >> all weaknesses. > > As usual you are making up definitions and being ridiculous. > In most common usage ‘ideal’ is used as opposed to ‘real’ Oh? So you're saying that there are other real choices for teaching, but Scheme is merely ideal? The phrase "an ideal choice", if taken at face value, means exactly what Steven is claiming: that it is logically impossible for there to be any better choice, because this is the greatest idea you could have. It is the very definition of "better" and "worse", in that a better option is nearer to the ideal than a worse one. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 23:42 -0700 |
| Message-ID | <85423a70-792c-47fd-915a-48f3c0f42e89@googlegroups.com> |
| In reply to | #112120 |
On Sunday, July 31, 2016 at 9:43:03 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jul 31, 2016 at 1:34 PM, Rustom Mody wrote: > > to > >> > teach the actual theory of programming languages (lambda calculus, lists > >> > as a foundation unit for all other data structures), Scheme was an ideal > >> > choice for teaching these fundamentals. > >> > >> People misuse language. You say that scheme was "ideal". That literally > >> means that there is *not one single thing* about Scheme that isn't PERFECT > >> for the task, that it reaches a faultless standard of perfection lacking > >> all weaknesses. > > > > As usual you are making up definitions and being ridiculous. > > In most common usage ‘ideal’ is used as opposed to ‘real’ > > Oh? So you're saying that there are other real choices for teaching, > but Scheme is merely ideal? > > The phrase "an ideal choice", if taken at face value, means exactly > what Steven is claiming: that it is logically impossible for there to > be any better choice, because this is the greatest idea you could > have. It is the very definition of "better" and "worse", in that a > better option is nearer to the ideal than a worse one. > > ChrisA Michael said: [emphasis and re-permuting mine] > Scheme was an ideal choice FOR TEACHING THE FUNDAMENTALS: [viz.] > the actual theory of programming languages — lambda calculus, lists > as a foundation unit for all other data structures. > [Whereas] Python would have been alright to teach "programming"… And it started with me saying that MIT has switched from scheme to python because: [MIT prof’s not my opinion] Not that python is any better at fundamentals than scheme but because hacking together a solution is more centerstage today than clarity in covering fundamentals. IOW those guys like Michael are pitting real vs ideal
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-30 22:10 -0700 |
| Message-ID | <8737mq8kal.fsf@jester.gateway.pace.com> |
| In reply to | #112111 |
Steven D'Aprano <steve@pearwood.info> writes:
>> Maybe. Lisp and Scheme are great languages to teach the theory..
> Doesn't sound like a good teaching language to me.>
> Meta-reasoning is harder than regular reasoning. That's why metaclasses are
> harder to use than ordinary classes.
Python metaclasses are monstrously more complicated than simple
metacircular evaluators in Scheme.
> Beginners have trouble enough learning even simple features of
> languages, and you want to drop them straight into meta-languages as
> their first taste of programming?
The classic SICP course didn't deal with meta-evaluation until towards
the end. It starts out with simple computation, then goes into higher
order functions, lazy evaluation, logic programming, and other topics;
finally it shows how to write a Scheme compiler in Scheme.
The book is really great, highly recommended, full text online:
https://www.mitpress.mit.edu/sicp/
Wadler critique (note: Miranda is a forerunner of Haskell):
https://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf
> I suspect that Lisp/Scheme would make a really good *third* language. Or
> even fourth.
FORTH heh heh ;-)
> - For starters, there's the whole parentheses thing.
That stops being a problem almost immediately, really.
> It has always perplexed me that Lisp's prefix notation is held up as
> the /sine qua non/ of elegance and power, while Forth is ignored if not
> ridiculed.
A postfix ("concatenative") language like Factor, with Forth-like syntax
but Scheme-like semantics, would be an interesting alternative to
Scheme. But traditional Forth, while cool in its own way, is extremely
low level, especially using the classical pure stack-oriented style.
Lots of mucking with raw machine addresses, no type system either at
compile time or runtime, not even local variables in the Forth loved by
purists. Consider multiplying two complex numbers a+bi and c+di in
Scheme (never mind that it has an actual complex datatype), giving a
2-element list (x y) representing x+yi which is (ac-bd) + i(ad+bc):
(define (z* a b c d)
(list (- (* a c) (* b d)) (+ (* a d) (* b c))))
Yeah there's parentehses etc. but it's obvious how to write it.
Now let's try that in Forth. It takes some head scratching--this is the
best I can do:
: ad+bc ( a b c d -- x ) -rot * -rot * + ;
: ac-bd ( a b c d -- y ) rot * >r * r> - ;
: z* ( a b c d -- x y ) 2over 2over ad+bc >r ac-bd r> ;
Have a look at the table of contents of SICP even if you don't read the
whole book, and imagine covering those topics in a Forth-based course.
You've probably already seen this too:
http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html
The ideas in that paper translate naturally into Haskell and with a bit
of exertion into Scheme, but would be painful in Forth.
> Lisp started as an academic language in the computer science
> department,
Actually math department (there was no such thing as CS then) but ok.
> while Forth was merely a practical language invented to control
> telescopes,
Forth was actually inspired by Lisp, and was invented while Chuck Moore
was working at a carpet company (he got into telescope control later).
It's still interesting for hardware control but painful for anything
that doesn't fit easily into fixed-width cells and not much use of
memory allocation.
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-31 19:39 +1200 |
| Message-ID | <e05oa0Fdum2U1@mid.individual.net> |
| In reply to | #112111 |
Steven D'Aprano wrote: > It has always perplexed me that Lisp's prefix notation is held up as > the /sine qua non/ of elegance and power, while Forth is ignored if not > ridiculed. The reason Lisp is easier to program in than Forth is not because of prefix vs. postfix. It's because in Lisp a function call is syntactically grouped together with its arguments, whereas in Forth it's not. Forth requires you to mentally simulate the stack to figure out what's operating on what. A language that was just like Forth except that it used prefix rather than postfix would be just as hard to reason about. Likewise, a postfix version of Lisp would be just as easy. > Perhaps it is because Lisp started as an academic language in the computer > science department ... > while Forth was merely a practical language invented to control telescopes, No, it's because Lisp has just enough structure, and Forth has too little. If Forth had come out of a computer science department and Lisp had been invented by an astronomer, Lisp would still be the easier language to use. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-31 10:51 +0300 |
| Message-ID | <87h9b6dz4l.fsf@elektro.pacujo.net> |
| In reply to | #112128 |
Gregory Ewing <greg.ewing@canterbury.ac.nz>: > If Forth had come out of a computer science department and Lisp had > been invented by an astronomer, Lisp would still be the easier > language to use. It is quite astounding how Lisp is steadily being reinvented by the down-to-earth programming community. It was famously observed by Paul Graham in 2002 (<URL: http://www.paulgraham.com/icad.html>). The evolution has kept on going since then: * Closures are everywhere (C++, C#, Java). * XML is being replaced by JSON. Python, of course, is part of that evolution. Marko
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 01:18 -0700 |
| Message-ID | <87twf66x04.fsf@jester.gateway.pace.com> |
| In reply to | #112129 |
Marko Rauhamaa <marko@pacujo.net> writes:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>> If Forth had come out of a computer science department and Lisp had
>> been invented by an astronomer, Lisp would still be the easier
>> language to use.
>
> It is quite astounding how Lisp is steadily being reinvented by the
> down-to-earth programming community.
"With a few very basic principles at its foundation, it [LISP] has
shown a remarkable stability. Besides that, LISP has been the
carrier for a considerable number of in a sense our most
sophisticated computer applications. LISP has jokingly been
described as “the most intelligent way to misuse a computer”. I
think that description a great compliment because it transmits the
full flavour of liberation: it has assisted a number of our most
gifted fellow humans in thinking previously impossible
thoughts." -- E. W. Dijkstra, 1972 Turing Award lecture
Greenspun's tenth rule of programming is an aphorism in computer
programming and especially programming language circles that
states:
"Any sufficiently complicated C or Fortran program contains an ad
hoc, informally-specified, bug-ridden, slow implementation of
half of Common Lisp".
-- https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2016-07-31 06:51 -0600 |
| Message-ID | <mailman.75.1469969542.6033.python-list@python.org> |
| In reply to | #112129 |
On Sun, Jul 31, 2016 at 1:51 AM, Marko Rauhamaa <marko@pacujo.net> wrote: > It is quite astounding how Lisp is steadily being reinvented by the > down-to-earth programming community. It was famously observed by Paul > Graham in 2002 (<URL: http://www.paulgraham.com/icad.html>). The > evolution has kept on going since then: > > * Closures are everywhere (C++, C#, Java). > > * XML is being replaced by JSON. > > Python, of course, is part of that evolution. What does JSON have to do with LISP?
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 09:23 -0700 |
| Message-ID | <87popt7p4b.fsf@jester.gateway.pace.com> |
| In reply to | #112136 |
Ian Kelly <ian.g.kelly@gmail.com> writes: > What does JSON have to do with LISP? JSON is a crappy form of S-expressions.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 01:14 -0700 |
| Message-ID | <87y44i6x7d.fsf@jester.gateway.pace.com> |
| In reply to | #112128 |
Gregory Ewing <greg.ewing@canterbury.ac.nz> writes: > The reason Lisp is easier to program in than Forth is not > because of prefix vs. postfix. It's because in Lisp a function > call is syntactically grouped together with its arguments, > whereas in Forth it's not. Forth requires you to mentally > simulate the stack to figure out what's operating on what. You said this much better than I did. I missed that point but it's very accurate. And of course traditional Forth doesn't even bind function args to symbols. If you want to use an arg more than once, you have to copy it and juggle it around on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-08-01 03:06 +1000 |
| Message-ID | <579e300e$0$1615$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112128 |
On Sun, 31 Jul 2016 05:39 pm, Gregory Ewing wrote: > Steven D'Aprano wrote: >> It has always perplexed me that Lisp's prefix notation is held up as >> the /sine qua non/ of elegance and power, while Forth is ignored if not >> ridiculed. > > The reason Lisp is easier to program in than Forth is not > because of prefix vs. postfix. It's because in Lisp a function > call is syntactically grouped together with its arguments, > whereas in Forth it's not. Forth requires you to mentally > simulate the stack to figure out what's operating on what. That's generally not hard though, and arguably more natural than thinking about higher-order functions, especially when you have higher-order stack words (at least according to some): https://news.ycombinator.com/item?id=1681174 You do make a good point but I don't think its the full story. Forth does have variables, and constants, but only global variables. And of course more modern languages like Factor have locals and even closures: http://factor-language.blogspot.com.au/2007/08/named-local-variables-and-lexical.html as well as garbage collection, currying/partial, objects, etc. There's a real mystery why concatenative/postfix languages have received so little attention from the academic community compared to prefix languages. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web