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 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 04:48 -0700 |
| Message-ID | <7b6caa1c-890a-4104-be7e-f8e279e34bb0@googlegroups.com> |
| In reply to | #112265 |
On Wednesday, August 3, 2016 at 1:57:43 PM UTC+5:30, Antoon Pardon wrote:
> Op 02-08-16 om 14:29 schreef Rustom Mody:
> > So I was talking of 3 very different levels:
> >
> > 1. print x vs print(x)
> > — a difference too petty for me to waste my time with
> >
> > 2. Procedure vs Function as something very necessary for beginner
> > thinking-ontology which Pascal gets right
> >
> > 3. The fact that the gap between a mainly-for-teaching language and a serious
> > software-engineering-real-world language is not closable
> > And that saying that the same language could be used for both purposes is
> > like arguing that both these delightful ladies are pianists:
> >
> >
> > Martha: https://www.youtube.com/watch?v=YLZLp6AcAi4
> > Rose : https://www.youtube.com/watch?v=_bjKDJD-CLc
> >
> >
> > Scheme and Pascal happen to be two well-known well-crafted but quite different
> > for-teaching languages
>
> But on what ground is scheme a well-crafted for-teaching language?
>
> It is not because it gets the Procedure vs Function ontology right.
>
> As far as I know scheme has about the same data structures as python,
> they are just called differently and there are some limitations.
Technically you are right
But “technically” is not the most important facet.
So yes scheme are python have similar underbellies but the culture of use
is quite different.
eg The very first example in the python tutorial uses a print statement/expr.
Whereas in scheme you can go through much of the text(s) before you see the same
Note: You CAN use python scheme-ishly but few people do that.
eg here is SICP in python with the first examples pure useful powerful functions:
http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-example
So people can use python functionally but somehow have the idea that imperative
is easier/more natural/what-have-you
Scheme and python data structures:
Python has a rich COLLECTION of data structures
Scheme really has just one — S-exp
Software-engineering-wise this conduces to power in python and headache/nuisance
in scheme
But for a learner its the opposite:
You do say dir([]) or dir({}) and you get a whole truckload of methods — how many
to learn??
With scheme you chew up car/cdr/cons until you reach an epiphany of understanding
vide Bruce Lee's quote: I am not afraid of the man who has practised ten
thousand kicks. I am afraid of the man who has practised one kick ten thousand
times
Then there are motley little things that make python beginner-unfriendly.
Noob makes a file whose name masks a builtin module and random things stop working. Umpteen such examples keep appearing out here. All point to one direction: Guido wants his language to be lightweight and for serious software
engineering.
Sure the ‘lightweight’ conduces to a neater language for teaching than say
C++, Java etc. But the teaching/learning is not the primary goal, its software
engineering.
This can be seen in many sundry choices
Backward compatibility: Guido is chary about introducing new keywords since
code that currently uses that will break unexpectedly. And so we get new features
that are seemingly clever but actually rather infelicitous; eg
- conditional expression with wrong order of arguments
- def overloaded for (ordinary) function and generator
- yield overloaded for coroutine and generator
For a beginner backward compatibility is a meaningless requirement:
If python-2016 is inconsistently different from python-2015 who is affected
since the bunch of learners has moved on.
[Hapless teacher excepted!]
Scheme — especially Dr. Scheme/racket — embraces inconsistency by offering
different ‘teachpacks’ — different language syntaxes/semantics' for learners
at different levels
Likewise platform independence:
One important goal of (core) python is that unless you go out of your way to
be troublesome, a python program (script) on linux will run on windows and vice-
versa (eg. universal newlines)
This is of course good
The flip-side is that important functionality that cant be easily supported
— eg GUIs — get relegated to ‘advanced’ topics which is a euphemism for get
neglected
[As a thought experiment: If we started by teaching VB would GUIs look as
advanced as they do in python?]
Once again like backward compatibility, platform independence is meaningless
to a beginner: For the one system that (s)he uses/owns it works or doesn’t work.
That it may or may not work for other invisible, unimaginable systems is
wildly over-the-top philosophy.
OTOH racket (scheme) comes with fairly comprehensive GUI/graphics functionality
[not tried myself]
I expect
1. Its not really in the professional league of Qt or Wx but its enough for
a beginner to have a comprehensive experience
2. An experience which is likely perceived as easier than struggling with
PyQt wxPython etc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-08-03 15:09 +0300 |
| Message-ID | <87fuqmjbpz.fsf@elektro.pacujo.net> |
| In reply to | #112273 |
Rustom Mody <rustompmody@gmail.com>: > So yes scheme are python have similar underbellies but the culture of > use is quite different. I don't know if there's enough Scheme activity out there to call it a culture. As far as underbellies go, Scheme macros and operators are not first-class. The Kernel programming language (<URL: http://klisp.org/>) addresses this flaw. > Note: You CAN use python scheme-ishly but few people do that. I don't know who or what you are referring to. About the only Schemey things not available to Python are tail recursion elimination and macros. From the little I have seen, Scheme programmers use tail recursion too little and macros too much. > So people can use python functionally but somehow have the idea that > imperative is easier/more natural/what-have-you In that regard, I don't see much difference in Scheme and Python practices. > Python has a rich COLLECTION of data structures > Scheme really has just one — S-exp Scheme has all kinds of data structures. > Then there are motley little things that make python > beginner-unfriendly. I can hardly imagine a programming language that would be better-suited for complete beginners. Scheme for beginning programmers could be like abstract algebra for kindergartners. Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 05:23 -0700 |
| Message-ID | <fd9ddf7e-58ae-4e80-8306-dacd0f2efad3@googlegroups.com> |
| In reply to | #112275 |
On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > So yes scheme are python have similar underbellies but the culture of > > use is quite different. > > I don't know if there's enough Scheme activity out there to call it a > culture. > > As far as underbellies go, Scheme macros and operators are not > first-class. The Kernel programming language (<URL: http://klisp.org/>) > addresses this flaw. > > > Note: You CAN use python scheme-ishly but few people do that. > > I don't know who or what you are referring to. I put it in the next line! > Scheme for beginning programmers could be like abstract algebra for > kindergartners. Maybe you are right — Anyhow MIT switching from scheme to python seems to think so. As I said earlier what they (the MIT profs) seem to be saying is that the topical relevance of python — a library for making robots — trumps scheme’s abstract beauty
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 05:27 -0700 |
| Message-ID | <fce1b2d3-7cdf-41c8-9264-85203d42b5fd@googlegroups.com> |
| In reply to | #112278 |
On Wednesday, August 3, 2016 at 5:53:44 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, August 3, 2016 at 5:39:25 PM UTC+5:30, Marko Rauhamaa wrote: > > Rustom Mody : > > I don't know who or what you are referring to. > > I put it in the next line! > > > Scheme for beginning programmers could be like abstract algebra for > > kindergartners. Funny keeps disappearing! One more try! Note: You CAN use python scheme-ishly but few people do that. eg here is SICP in python with the first examples pure useful powerful functions: http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-example
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-08-03 15:37 +0300 |
| Message-ID | <877fbyjae3.fsf@elektro.pacujo.net> |
| In reply to | #112279 |
Rustom Mody <rustompmody@gmail.com>: > Note: You CAN use python scheme-ishly but few people do that. > eg here is SICP in python with the first examples pure useful powerful > functions: > http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-example I see nothing there that is not ordinary Python. Marko
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-03 05:43 -0700 |
| Message-ID | <88b9b7af-1594-4c6f-a303-aa7fc3d1d577@googlegroups.com> |
| In reply to | #112283 |
On Wednesday, August 3, 2016 at 6:08:08 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > Note: You CAN use python scheme-ishly but few people do that. > > eg here is SICP in python with the first examples pure useful powerful > > functions: > > http://www-inst.eecs.berkeley.edu/~cs61a/sp12/book/functions.html#first-example > > I see nothing there that is not ordinary Python. Its an example of python used functionally — normal python (3 I think) ie No loops, no prints (at least in early chapters Ive obviously not scoured the whole book) No assignment is harder, but you will see the assignment is more like a lisp-let; ie its a single assignment
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-08-03 15:34 +0300 |
| Message-ID | <87bn1ajakb.fsf@elektro.pacujo.net> |
| In reply to | #112278 |
Rustom Mody <rustompmody@gmail.com>: > As I said earlier what they (the MIT profs) seem to be saying is that > the topical relevance of python — a library for making robots — trumps > scheme’s abstract beauty Python is an excellent choice. As far as abstract beauty is concerned, I'm wondering why Python abolished braces from statement syntax but not from expression syntax. Marko
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-08-03 18:01 -0400 |
| Subject | {non sequitur/bad humor} was: Why not allow empty code blocks? |
| Message-ID | <mailman.156.1470261693.6033.python-list@python.org> |
| In reply to | #112275 |
On Wed, 03 Aug 2016 15:09:12 +0300, Marko Rauhamaa <marko@pacujo.net>
declaimed the following:
>I don't know if there's enough Scheme activity out there to call it a
>culture.
>
>As far as underbellies go, Scheme macros and operators are not
>first-class. The Kernel programming language (<URL: http://klisp.org/>)
>addresses this flaw.
>
Cultures are what you find in Petri dishes... and maybe slimy
underbellies...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 02:43 +1000 |
| Message-ID | <579cd91b$0$1621$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112075 |
On Sun, 31 Jul 2016 12:47 am, Steven D'Aprano wrote: > On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote: [...] >> - 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? Oops, I meant 1957. -- 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-30 23:06 +1000 |
| Message-ID | <579ca644$0$1589$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112048 |
On Sat, 30 Jul 2016 08:15 pm, BartC wrote:
> Interesting use of 'pass' in this example:
>
> http://pastebin.com/aYJdgEL4
>
> (I do believe he's using 'pass' as 'end'! Although he misses some out in
> that case.)
I wouldn't call it so much "interesting" as "a good example of how not to
program".
All languages -- human and programming -- involve certain quirks, or
features which are matters of taste. If it a sign of a poor programmer that
ignores the common idioms of a language and writes in another
language's "grammar".
"If so smart Yoda is, how come English speak he cannot?"
People are more forgiving off grammatical errors and weird idioms than
computer programs, but still, there are conventions to follow. In English,
we can talk about having a quick meal of fast food, but not a fast meal of
quick food. Our computers are powerful, never mighty, and if we ever invent
a time machine, we'll travel into the past, not onto the past.
You can get away with breaking a language's idioms for humour:
https://www.youtube.com/watch?v=MNyG-xu-7SQ
or, if you're *really* talented, as art. See, for example, James Joyce's
Finnegan's Wake, which is as unidiomatic as it is possible to be while
still being (just barely) English, but deliberately so.
(As opposed to "ee cummings", who was and is lauded far beyond his actual
talent.)
Th same principles apply to programming languages. But outside of highly
optimized code, which is often ugly, or examples of code as art (like code
golf, Obfuscated C and Underhanded C competitions, multi-language hybrid
code, esoteric languages etc.), the aim of programming should be to
maximize *human* communication. And that usually means writing in the
idiomatic style of the natives. There are no awards for trying to hammer
the round pegs of Algol grammar into the square holes of the Python
interpreter.
(1) Using "pass" as a form of "end" is simply bizarre.
(2) Python allows the semi-colon for the convenience of command-line users,
where it is sometimes difficult to write multiple lines of code. Using it
inside a .py file is a sign of somebody who is not a native speaker.
(3) Separating statements by variable numbers of spaces, between 1 and 13 by
my count, is just weird.
Given the lack of Python fluency, the lack of documentation and meaningful
comments, the unusual (for Python) idioms that hurt readability, and some
very odd names (there is one constant called "ONE" with the value
1073741824), the overall impression I get is that the author of that file
simply isn't a good programmer.
[...]
> As I've mentioned, Python also uses explicit block delimiters in the
> form of else, elif, except, finally (and whichever ones I've misssed):
You are wrong. They are not delimiters. They *begin* a new block, they don't
end the previous one except as a side effect of beginning a new block.
if condition:
block
new block
It is the dedent (outdent) that ends the if block. "new block" is permitted
to be an elif or else statement, of course, but you cannot write:
if condition:
block
else: statement
because "else" is not an "end of if" statement. It *begins* a new statement.
> if x: a; b elif y: c; d elif z: e; f else: g
That's not legal Python syntax.
> In the above syntax, it would be:
>
> if x then a; b elsif y then c; d elsif z then e; f else g fi
>
> Doesn't it look like there's something missing in the Python?
No it does not.
> Both the
> 'fi' or 'end', and the possibility of an 'h' statement.
>
> Note the Algol68-style style is more free-format where indents are not
> significant.
Good for Algol. To my eyes, that makes it harder to read: too many
unneeded "ends", to great a risk that the visual structure of the code
doesn't match the logical structure of the code.
> Anyway, if you're going to talk about annoying things forced upon you by
> the language, what about:
>
> ":" after "else"
What about it? When you write a list of items in English, it is more
idiomatic and natural to end the clause with a semi-colon:
- item one
- item two
- item three
than without it.
I've read Cobra code which is very like Python except (among other changes)
they've dropped the semi-colons It simply looks wrong Like sentences
without punctuation Or perhaps like an painting on a wall just every so
slightly on an angle
> "()" in "def fn():"
I could go either way with that.
> "()" in "print (x)" for Python 3
Why? Do you object to other functions using parentheses?
> "for i in range(N):" just to repeat a block N times...
Why should there be special syntax just for repeating a block N times?
There's a general purpose for-loop which performs iteration. Why do you
need special syntax to do what it already does?
We have a general "if" clause for doing conditional branching. Would you
insist on a special purpose if syntax for testing if a number is 2?
if number == 1: # general case
if number == 7921 # general case
iftwo number: # special syntax
> That's apart from the obligatory indents which, with an 'end'-delimited
> scheme, are not always necessary.
Of course they're necessary. The participants of the old "indent style wars"
of the 80s and 90s didn't agree on much, but they did agree on one thing:
- if you write code without indentation that matches the logical structure
of the code, you're a bad programmer.
End of story. As far as I am concerned, the 97% of languages which allow the
visual structure of the code to differ from their logical structure are BAD
LANGUAGES.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 23:36 +1000 |
| Message-ID | <mailman.52.1469885808.6033.python-list@python.org> |
| In reply to | #112066 |
On Sat, Jul 30, 2016 at 11:06 PM, Steven D'Aprano <steve@pearwood.info> wrote: >> "for i in range(N):" just to repeat a block N times... > > Why should there be special syntax just for repeating a block N times? > There's a general purpose for-loop which performs iteration. Why do you > need special syntax to do what it already does? Python could have chosen to make integers iterable, such that you say: for i in 10: but I don't think it really improves readability. It wouldn't materially damage the language, though - the 'for' loop still does exactly what it does, the rules are still just as simple. The only question would be: why can't floats be iterable too? I mean, "for i in 3.5" should start half way down the loop body, complete that loop, and then do three complete loops. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 14:58 +0100 |
| Message-ID | <nnibqb$9n2$1@dont-email.me> |
| In reply to | #112067 |
On 30/07/2016 14:36, Chris Angelico wrote:
> On Sat, Jul 30, 2016 at 11:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>>> "for i in range(N):" just to repeat a block N times...
>>
>> Why should there be special syntax just for repeating a block N times?
>> There's a general purpose for-loop which performs iteration. Why do you
>> need special syntax to do what it already does?
>
> Python could have chosen to make integers iterable, such that you say:
>
> for i in 10:
>
> but I don't think it really improves readability.
On 30/07/2016 13:47, Chris Angelico wrote:
>(Also, it requires the use
> and damage of some iterator variable, which may be significant in some
> contexts.)
The 'i' is superfluous. Why not:
for 10:
(In my own syntaxes I use (actual example):
to 64 do
table append:= nextbyte(fs)
od
Python equivalent:
for i in range(64):
table.append(nextbyte(fs))
The range object isn't really necessary, and the 'i' variable doesn't
need to be exposed (as a programmer-accessible, reference-counted variable).
The 'to' construct I also implemented with a single very fast byte-code,
executed once per iteration.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 01:48 +1000 |
| Message-ID | <579ccc68$0$1583$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112069 |
On Sat, 30 Jul 2016 11:58 pm, BartC wrote: > The 'i' is superfluous. Why not: > > for 10: Why bother? What's so special about this that it needs dedicated syntax? Hypertalk (and related XTalk languages) offer a number of dedicated looping constructs. Using square brackets [] for optional terms: repeat [forever] repeat [for] number [times] repeat until condition repeat while condition repeat with variable = start [to] end repeat with variable = start [down to] end That's right, a bare "repeat" on its own gives you an infinite loop. Does *your* language have special syntax for infinite loops? If not, why not? We should accept that some things are just a matter of taste and idiom. When I wrote code in Hypertalk, I used those six different forms and found them perfectly reasonable *in that language*. When I write Python code, I never find myself wishing I could write Hypertalk code repeat loops (not since 1998 or thereabouts) in Python, since they don't "feel" right for the language: at best, it would be like suddenly dropping into Lolcat in the middle of an ordinary English sentence. Good for a giggle, but that's all. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 02:34 +1000 |
| Message-ID | <mailman.55.1469896469.6033.python-list@python.org> |
| In reply to | #112080 |
On Sun, Jul 31, 2016 at 1:48 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> Hypertalk (and related XTalk languages) offer a number of dedicated looping
> constructs. Using square brackets [] for optional terms:
>
> repeat [forever]
> repeat [for] number [times]
> repeat until condition
> repeat while condition
> repeat with variable = start [to] end
> repeat with variable = start [down to] end
>
>
> That's right, a bare "repeat" on its own gives you an infinite loop. Does
> *your* language have special syntax for infinite loops? If not, why not?
Hmm, very similar to REXX, with one critical difference. Here's REXX's loops:
do
do forever
do number
do while condition
do until condition
do variable = start [to end] [by step] [for count]
In REXX, "do forever" is like Hypertalk's "repeat forever", and the
other constructs are similar (though the counted form is more flexible
- you can say "do i=1 to 10" to set the end marker, or you can say "do
i=1 for 10" to set an iteration count) - but "do" on its own means
"execute this block of code exactly once", not an infinite loop.
(do/end in this form is for defining blocks of code, like Pascal's
begin/end or C's { }.) Curious distinction.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 19:46 +0100 |
| Message-ID | <nnisma$44e$1@dont-email.me> |
| In reply to | #112080 |
On 30/07/2016 16:48, Steven D'Aprano wrote:
> On Sat, 30 Jul 2016 11:58 pm, BartC wrote:
>
>> The 'i' is superfluous. Why not:
>>
>> for 10:
>
> Why bother? What's so special about this that it needs dedicated syntax?
No named loop variable to invent, create, maintain, and destroy. No
range object to create, destroy etc. If you're looking for ways for a
language to be more efficient, then why disregard this possibility?
> Hypertalk (and related XTalk languages) offer a number of dedicated looping
> constructs. Using square brackets [] for optional terms:
>
> repeat [forever]
> repeat [for] number [times]
> repeat until condition
> repeat while condition
> repeat with variable = start [to] end
> repeat with variable = start [down to] end
>
>
> That's right, a bare "repeat" on its own gives you an infinite loop. Does
> *your* language have special syntax for infinite loops? If not, why not?
The infinite loop is: do ... od
However, there aren't multiple statements here, but just one. The full
syntax is:
for i:=A to B by C when D do ... [else...] od
but some parts are optional. So for example:
for i to B do ... od # loop from i=1 to B
to N do ... od # repeat N times
do ... od # repeat forever
for i:=A do ... od # loop from i=A forever
My syntax was based on Algol68 where there is only one loop form and
it's something like this IIRC:
for i:=A to B by C while D do ... od
By leaving out the first parts, you end up with a while-loop! So this
gives you all the possibilities (except repeat ... until/while which is
missing from the language.).
(In Algol68, a false value in 'while D' will terminate the loop. The
'when D' condition in my version will only skip that iteration.
But I have a dedicated 'while' loop as well. As has Python. Note that
the for-loops above iterate only over integers. I use 'forall' for what
Python calls a for-loop.)
> We should accept that some things are just a matter of taste and idiom. When
> I wrote code in Hypertalk, I used those six different forms and found them
> perfectly reasonable *in that language*. When I write Python code, I never
> find myself wishing I could write Hypertalk code repeat loops (not since
> 1998 or thereabouts) in Python, since they don't "feel" right for the
> language: at best, it would be like suddenly dropping into Lolcat in the
> middle of an ordinary English sentence. Good for a giggle, but that's all.
Well, they wouldn't work for a start. But I'm sure you have needed, at
some time or other, infinite loops or repeat N times loops. And then you
just emulate them as best you can with 'while 1:' or 'for _ in
range(N):' or whatever.
But dedicated forms (even if they just map to 'while' or 'for') wouldn't
hurt. Syntax is free after all, and it's about expressing exactly what
you mean.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 12:10 +1000 |
| Message-ID | <579d5e2d$0$1612$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112098 |
On Sun, 31 Jul 2016 04:46 am, BartC wrote:
> On 30/07/2016 16:48, Steven D'Aprano wrote:
>> On Sat, 30 Jul 2016 11:58 pm, BartC wrote:
>>
>>> The 'i' is superfluous. Why not:
>>>
>>> for 10:
>>
>> Why bother? What's so special about this that it needs dedicated syntax?
>
> No named loop variable to invent, create, maintain, and destroy. No
> range object to create, destroy etc. If you're looking for ways for a
> language to be more efficient, then why disregard this possibility?
Who says I've disregarded it? Just because I've concluded that the benefit
fails to outweigh the costs doesn't mean I didn't think about it.
To be clear, it's not *my* decision whether or not Python gets this new
syntactic feature or that. But the same applies to the people (mostly
Guido) whose decision it is. Just because they come to the opposite
conclusion to you doesn't mean they haven't considered alternatives.
[...]
> But I'm sure you have needed, at
> some time or other, infinite loops or repeat N times loops. And then you
> just emulate them as best you can with 'while 1:' or 'for _ in
> range(N):' or whatever.
"As best you can" sounds second best. How about we say *better* instead?
"while True" doesn't merely emulate an infinite loop, it implements an
infinite loop without needing dedicated syntax, byte-code or
implementation. Infinite loops are not conceptually different from finite
loops, they're just ordinary while loops where the condition is always
true.
If you say to me that a dedicated infinite loop construct can save a
comparison each time round, I'll have two responses:
(1) That's close to the worst example of premature optimization I've ever
seen. Outside of artificial and trivial benchmarks involving do-nothing or
do-almost-nothing loops, in what real-world situation is the difference
between:
do forever: # no comparison made
block
and
do while True # always checks that the constant True is, in fact, True
block
going to be significant? The *MOST* you are going to save will be a
conditional test (in Python, that will probably be based on a pointer
comparison, or something equivalently cheap) before the jump.
(2) And even if it is significant, surely that's something that a keyhole
optimizer can detect without requiring the user to care one iota about the
difference? And indeed, that's EXACTLY what Python 3.6 (and probably older
versions) does: it optimizes out the comparison, and unconditionally loops:
py> from dis import dis
py> dis("while flag: spam()")
1 0 SETUP_LOOP 14 (to 16)
>> 2 LOAD_NAME 0 (flag)
4 POP_JUMP_IF_FALSE 14
6 LOAD_NAME 1 (spam)
8 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
10 POP_TOP
12 JUMP_ABSOLUTE 2
>> 14 POP_BLOCK
>> 16 LOAD_CONST 0 (None)
18 RETURN_VALUE
py> dis("while True: spam()")
1 0 SETUP_LOOP 10 (to 12)
>> 2 LOAD_NAME 0 (spam)
4 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
6 POP_TOP
8 JUMP_ABSOLUTE 2
10 POP_BLOCK
>> 12 LOAD_CONST 0 (None)
14 RETURN_VALUE
> But dedicated forms (even if they just map to 'while' or 'for') wouldn't
> hurt. Syntax is free after all, and it's about expressing exactly what
> you mean.
Syntax is not free!
Syntax requires more code in the compiler. Somebody has to write it,
somebody has to maintain it, somebody has to test it, somebody has to
document it.
When you offer a choice between two or more features which do the same
thing, say a general case and a dedicated special case, your users have to
learn them both. They have to understand the difference between them, and
they have to choose which to use. And they invariably have to deal with
code by others which chooses "wrongly" according to the user's own values.
Every little feature increases the size of the compiler, both the source and
binary, and increases the chances of compiler bugs. There are already
situations where compilers are too big (e.g. on embedded devices, or
memory- and storage-constrained machines like the RaspberryPy). It adds to
the time it takes to download, adds to the time it takes to build the
compiler, adds to the time to test the compiler, and adds to the time it
takes to compile your code. It increases the compiler complexity, and
having dedicated opcodes may rule out certain JIT optimization strategies.
You're perfectly welcome to decide that you consider those costs to be
negligible, especially for a language that has a user-base of one, namely
yourself. That's your value judgement. Others may judge differently.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-30 23:41 -0400 |
| Message-ID | <mailman.63.1469936508.6033.python-list@python.org> |
| In reply to | #112106 |
On Sat, Jul 30, 2016, at 22:10, Steven D'Aprano wrote: > "while True" doesn't merely emulate an infinite loop, it implements an > infinite loop without needing dedicated syntax, byte-code or > implementation. Er, it's not like it would need dedicated byte code anyway. The bytecode of an infinite loop is just an unconditional backward jump*, which we already have. The peephole optimizer already takes care of it (which _could_ be considered dedicated implementation; even if it's general enough to also work with "if True", how many of those do you figure there really are?) One argument that exists in favor of a dedicated infinite loop (and dedicated finite repetition loop) syntax, which I don't personally think applies to Python, is that the condition (and the whole construct for "for i in range", for finite repetitions) means additional concepts that have to be introduced at the same time to people being taught programming for the first time. *in fact, the bytecode of while already contains an unconditional backward jump; there's a conditional forward jump at the top - which is eliminated, I assume by the peephole optimizer, when the loop condition is a truthy constant.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-31 11:18 +0100 |
| Message-ID | <nnkj9f$pj6$1@dont-email.me> |
| In reply to | #112106 |
On 31/07/2016 03:10, Steven D'Aprano wrote:
> On Sun, 31 Jul 2016 04:46 am, BartC wrote:
>> No named loop variable to invent, create, maintain, and destroy. No
>> range object to create, destroy etc. If you're looking for ways for a
>> language to be more efficient, then why disregard this possibility?
>
> Who says I've disregarded it? Just because I've concluded that the benefit
> fails to outweigh the costs doesn't mean I didn't think about it.
The costs are near zero: at minimum, a syntactic construct such as:
repeat N:
that expands to:
for _ in range(N):
The benefit is not so much performance, but being able to express
something very easily and quickly.
> (2) And even if it is significant, surely that's something that a keyhole
> optimizer can detect without requiring the user to care one iota about the
> difference? And indeed, that's EXACTLY what Python 3.6 (and probably older
> versions) does: it optimizes out the comparison, and unconditionally loops:
>
> py> dis("while True: spam()")
> 1 0 SETUP_LOOP 10 (to 12)
> >> 2 LOAD_NAME 0 (spam)
> 4 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
> 6 POP_TOP
> 8 JUMP_ABSOLUTE 2
> 10 POP_BLOCK
> >> 12 LOAD_CONST 0 (None)
> 14 RETURN_VALUE
In Python 2.7, the True value has be tested each time.
The reason? Because True is one of those names that could be reassigned
by the programmer. This was the subject of the discussion we had some
time back about not being able to assume anything, because anything
could change.
In Python 3, True wisely seems to have been turned into a reserved word.
With the obvious benefits of the compiler always knowing what's what!
>> But dedicated forms (even if they just map to 'while' or 'for') wouldn't
>> hurt. Syntax is free after all, and it's about expressing exactly what
>> you mean.
>
> Syntax is not free!
>
> Syntax requires more code in the compiler. Somebody has to write it,
> somebody has to maintain it, somebody has to test it, somebody has to
> document it.
For language implementations, dedicated syntax is by far the easiest
thing to code. Far easier that trying to detect certain patterns in the
code later on.
> Every little feature increases the size of the compiler, both the source and
> binary, and increases the chances of compiler bugs.
Support for dedicated endless loops is around 20 lines in my compiler:
http://pastebin.com/wXXVQFkJ
(Plus 3 or 4 more lines distributed elsewhere.)
The first function is to parse the loop. The second to generate code,
which is more complex because it supports extra loop controls which
don't exist in Python.
> There are already
> situations where compilers are too big (e.g. on embedded devices, or
> memory- and storage-constrained machines like the RaspberryPy).
Are you serious? The Pi (even the first one that I've got lying around
somewhere) has hundreds of MB of memory, a clock speed of 700MHz, and
storage measured in GB.
My entire bytecode compiler is less than 0.3MB (and that includes all
sorts of crap).
It adds to
> the time it takes to download,
LOL!
The Anaconda I was recommended to download last year (when I just wanted
numpy) was over 1GB.
While even my ordinary Python 3 installation has 5000 files.
I repeat, adding a bit of extra syntax to a language is utterly trivial
by comparison.
(Not quite so easy in an existing, established language, but that's
another matter. But it does sound as though, even if we were discussing
a totally new language, you still wouldn't be interested in such features.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-08-01 01:31 +1000 |
| Message-ID | <579e19e0$0$1595$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112133 |
On Sun, 31 Jul 2016 08:18 pm, BartC wrote:
> On 31/07/2016 03:10, Steven D'Aprano wrote:
>> On Sun, 31 Jul 2016 04:46 am, BartC wrote:
>
>>> No named loop variable to invent, create, maintain, and destroy. No
>>> range object to create, destroy etc. If you're looking for ways for a
>>> language to be more efficient, then why disregard this possibility?
>>
>> Who says I've disregarded it? Just because I've concluded that the
>> benefit fails to outweigh the costs doesn't mean I didn't think about it.
>
> The costs are near zero:
And the benefits even nearer to zero.
Our discussion about this topic has probably cost more time and energy than
this feature would save in a hundred years of use.
> at minimum, a syntactic construct such as:
>
> repeat N:
>
> that expands to:
>
> for _ in range(N):
>
> The benefit is not so much performance, but being able to express
> something very easily and quickly.
I can express `for i in range(N)` very easily and quickly. It is the One
Obvious Way to do the job. The number of keystrokes is not excessive. I
don't have to think about whether I should use this or `repeat N`. I don't
have to stop and think "If I choose repeat N, will I have to change my mind
in the future?"
As Henry Ford said, you can have any colour you like so long as its black.
There is value in a minimalist syntax. Every syntactic feature has to pull
its weight. `repeat N` doesn't pull its weight. That's the value judgement
expressed by Python. Other languages are free to make other value
judgements.
>> (2) And even if it is significant, surely that's something that a keyhole
>> optimizer can detect without requiring the user to care one iota about
>> the difference? And indeed, that's EXACTLY what Python 3.6 (and probably
>> older versions) does: it optimizes out the comparison, and
>> unconditionally loops:
>>
>
>> py> dis("while True: spam()")
>> 1 0 SETUP_LOOP 10 (to 12)
>> >> 2 LOAD_NAME 0 (spam)
>> 4 CALL_FUNCTION 0 (0 positional, 0 keyword pair)
>> 6 POP_TOP
>> 8 JUMP_ABSOLUTE 2
>> 10 POP_BLOCK
>> >> 12 LOAD_CONST 0 (None)
>> 14 RETURN_VALUE
>
> In Python 2.7, the True value has be tested each time.
I'm not talking about 2.7. 2.7 is old and on its way out. It is hobbled by
the requirement of backwards compatibility.
Since you have a user-base of exactly one person, yourself, you don't have
to care about backwards compatibility. You can change your mind and remove
features or change them any time you like. Python cannot. For historical
reasons, there are probably a million lines of code out there which assume
that True and False are ordinary variables that may be assigned to. Even if
it is only a thousand, or a hundred, we still could not change that in the
2.x series. It's only in 3.x that we can make True and False constants.
But in 2.7, you can write:
while 1:
or even:
while "forever and ever, never stopping until the sun goes out":
to get the same effect.
[...]
>>> But dedicated forms (even if they just map to 'while' or 'for') wouldn't
>>> hurt. Syntax is free after all, and it's about expressing exactly what
>>> you mean.
>>
>> Syntax is not free!
>>
>> Syntax requires more code in the compiler. Somebody has to write it,
>> somebody has to maintain it, somebody has to test it, somebody has to
>> document it.
>
> For language implementations, dedicated syntax is by far the easiest
> thing to code. Far easier that trying to detect certain patterns in the
> code later on.
*shrug*
The whole point of an optimizing compiler is that you don't have to detect
patterns yourself. The compiler does it. There's a whole science to writing
optimizing compilers these days, and they don't do it by hard-coding
dedicated syntax for each thing you want to optimize. That's very 1970s.
>> Every little feature increases the size of the compiler, both the source
>> and binary, and increases the chances of compiler bugs.
>
> Support for dedicated endless loops is around 20 lines in my compiler:
>
> http://pastebin.com/wXXVQFkJ
>
> (Plus 3 or 4 more lines distributed elsewhere.)
That's 25 lines that you don't need. Plus of course another 50 or 60 lines
of tests (if you have tests), plus ten or thirty lines of documentation (if
you have documentation), plus a dozen or two discussions on StackOverflow
from people asking whether they should use "repeat forever" or "repeat
while True" (if you had any users, which you don't).
Bart, I'm not putting you down for having no users. But your judgement of
the pros and cons of a feature is biased one way because you only have to
please yourself. Python's philosophy is biased another way because Guido is
a strong (although sometimes a little inconsistent) believer in simplicity
of implementation and design.
And you know what? That's fine. It's *good* that there are language
designers with different ideas of what's valuable. That gives us a rich
eco-system of languages to pick and choose from. Can you imagine if
everyone thought the same way and valued the same things? We have *one*
language, and it would probably be COBOL.
> The first function is to parse the loop. The second to generate code,
> which is more complex because it supports extra loop controls which
> don't exist in Python.
>
>> There are already
>> situations where compilers are too big (e.g. on embedded devices, or
>> memory- and storage-constrained machines like the RaspberryPy).
>
> Are you serious? The Pi (even the first one that I've got lying around
> somewhere) has hundreds of MB of memory, a clock speed of 700MHz, and
> storage measured in GB.
>
> My entire bytecode compiler is less than 0.3MB (and that includes all
> sorts of crap).
If you removed some of the crap maybe you could get it down to 0.1MB and be
able to run it on an embedded device with 200K of memory.
Does your 0.3MB include a library that provides as much functionality as
Python's std lib does? If not, you're comparing chalk and cheese.
The full Python installation is over 100MB and that's really a problem for
some people:
https://mail.python.org/pipermail/python-ideas/2016-July/041230.html
In that same thread, one of the lead Python devs Victor Stinner talks about
some of his work on embedded devices where he has a hard limit of 128MB for
*everything*: boot loader, kernel, OS, applications, etc.
Some years ago, the company I work for did some work for a Highly Praised
calculator manufacturer that was looking to fit a full Linux-based
installation onto a hand-held device. We were literally looking to shave a
few K off applications to get everything to fit. I'm told that after
spending heroic efforts to squeeze everything into the space provided and
still have everything work correctly *and fast*, and *after* having built
tens of thousands of the devices (complete with printed manuals and
packaging), a new manager took over and ordered the project canned and the
devices crushed and turned into landfill.
Capitalism at its finest.
> (Not quite so easy in an existing, established language, but that's
> another matter. But it does sound as though, even if we were discussing
> a totally new language, you still wouldn't be interested in such
> features.)
Not so. I've already told you that I was perfectly happy with Hypertalk,
which takes the opposite philosophy to Python. It has a plethora of syntax,
and is very verbose. I miss it terribly, I loved that language and the IDE
it came with.
But I wouldn't try to put syntax features from it into Python.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-07-31 12:39 -0400 |
| Message-ID | <mailman.79.1469983161.6033.python-list@python.org> |
| In reply to | #112139 |
On Mon, 01 Aug 2016 01:31:42 +1000, Steven D'Aprano <steve@pearwood.info>
declaimed the following:
>
>And you know what? That's fine. It's *good* that there are language
>designers with different ideas of what's valuable. That gives us a rich
>eco-system of languages to pick and choose from. Can you imagine if
>everyone thought the same way and valued the same things? We have *one*
>language, and it would probably be COBOL.
>
FORTRAN
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web