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 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-23 05:28 -0700 |
| Subject | Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) |
| Message-ID | <116a5c2b-01cc-4ed3-a82c-1ee0a94200dc@googlegroups.com> |
| In reply to | #111782 |
On Saturday, July 23, 2016 at 4:44:00 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
> > On Sat, 23 Jul 2016 01:33 am, Kent Tong wrote:
> >> I'm aware that we can use 'pass' as an empty code block. But why
> >> doesn't python allow a code block to be empty and thus eliminate the
> >> need for this null statement?
> >
> > Because it cannot tell the difference between an empty code block and
> > failing to indent the code block:
> >
> > for x in sequence:
> > print('loop')
> >
> > Is that meant to print 'loop' each time around the loop, or just once, at
> > the end of the loop?
>
> I don't see an ambiguity: obviously the print call takes place after
> finishing the loop.
>
> > There are cases where the interpreter could tell:
> >
> > if flag:
> > else:
> > block
> >
> > Obviously the "if" block is empty. But for consistency, and
> > simplicity, the interpreter requires a pass there too.
>
> I wonder if there is any true case of ambiguity. I guess this is all
> about an enforced aesthetic principle: GvR doesn't like the looks of an
> empty block.
>
> > One less thing to be programmed, one less thing for the user to
> > remember. Just require pass any time you have an empty block, rather
> > than try to remember where it is required and were it is optional.
>
> Actually, the requirement of a dummy statement is a slight annoyance for
> the programmer. After deleting a statement, you must see if you have to
> put in a pass statement. And after adding a statement, you may feel the
> urge to remove the redundant pass statement.
Tsk Tsk…
The Europeans took 500 years to appreciate that zero is a necessity
https://en.wikipedia.org/wiki/Arabic_numerals#Adoption_in_Europe
Do you seriously suppose that they did not have the asymptotic/limiting case of:
There are 3 apples in the basket
There are 2 apples in the basket
There are 1 apples in the basket
Now you can (and they probably did) replace the ‘1’ by ‘no’
But that’s not a number
You can have nothing there:
There are apples in the basket
Is it visible?
Problem is more evident if we use a ‘base-1’ system
There are XXX apples in the basket
There are XX apples in the basket
There are X apples in the basket
There are apples in the basket
IOW the notion of zero is trivial enough (in hindsight)
First-classing it as a notation is not at all trivial
This question is analogous – maybe almost identical – to the question of
the most trivial automata/regex etc.
For a long time the re → dfa transformation went and was taught the laborious
route:
re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa
https://en.wikipedia.org/wiki/Thompson's_construction
https://en.wikipedia.org/wiki/Powerset_construction
Now there is a direct, straightforward method which only becomes available
(thinkable) when we have a null regular expression:
https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf
Coming back to zero:
While it is true that European civilization knew of and ignored the zero for
500 years and science-advances happened only after adopting zero, and today
we take it for granted. Still it remains true that zero is a bit anomalous.
Some evidences of this:
Lets say that a numeral is in normal form if it has no leading zeros.
So 0025 normalizes to 25.
Is 0 a normal form?
Likewise: Early versions of Fortran had loops that could not execute zero times:
http://www-pnp.physics.ox.ac.uk/~gronbech/intfor/node18.html
In the same vein «pass» (Dijkstra called it «skip») and «abort» (roughly «raise Exception» in python-speak) correspond to 1 and 0 in numbers
And IMHO anyone who rejects the search/formalization for the trivial case as a
useless activity is effectively pushing us back to the dark ages.
And if one finds it hard to believe that humans can be incredibly resistant
to learning from mistakes, here's a list of long-lasting errors like rejecting zero:
http://blog.languager.org/2016/01/how-long.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-07-24 11:15 +0100 |
| Subject | Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) |
| Message-ID | <878twrs5oj.fsf@bsb.me.uk> |
| In reply to | #111785 |
Rustom Mody <rustompmody@gmail.com> writes: <snip> > For a long time the re → dfa transformation went and was taught the laborious > route: > re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa > > https://en.wikipedia.org/wiki/Thompson's_construction > https://en.wikipedia.org/wiki/Powerset_construction > > Now there is a direct, straightforward method which only becomes available > (thinkable) when we have a null regular expression: > https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf "Now" seems an odd thing to say since the technique is quite old. It would be better to say that it has been re-discovered. But thanks for the link -- I was unaware of the idea. Unfortunately the material is not well presented there (lower-case phi for the empty set?) but in trying to understand what it was saying I found: https://www.cl.cam.ac.uk/~so294/documents/jfp09.pdf which, in my opinion, does it very much better. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-24 07:49 -0700 |
| Subject | Re: Detecting the trivial can be non-trivial (was Why not allow empty code blocks?) |
| Message-ID | <f771df57-fd6a-4d61-8385-91840a5767d4@googlegroups.com> |
| In reply to | #111799 |
On Sunday, July 24, 2016 at 3:45:40 PM UTC+5:30, Ben Bacarisse wrote: > Rustom Mody writes: > <snip> > > For a long time the re → dfa transformation went and was taught the laborious > > route: > > re → nfa-with-ε-transitions → nfa-without-ε-transitions → dfa > > > > https://en.wikipedia.org/wiki/Thompson's_construction > > https://en.wikipedia.org/wiki/Powerset_construction > > > > Now there is a direct, straightforward method which only becomes available > > (thinkable) when we have a null regular expression: > > https://drona.csa.iisc.ernet.in/~deepakd/fmcs-06/seminars/presentation.pdf > > "Now" seems an odd thing to say since the technique is quite old. It > would be better to say that it has been re-discovered. The “Now” was not meant time-ly! > > But thanks for the link -- I was unaware of the idea. Unfortunately the > material is not well presented there (lower-case phi for the empty set?) > but in trying to understand what it was saying I found: > > https://www.cl.cam.ac.uk/~so294/documents/jfp09.pdf > > which, in my opinion, does it very much better. Yeah I think the one used when I was studying was this one http://www2.in.tum.de/hp/file?fid=571 Anyway my main point was that getting trivial cases right is damn hard And eliding the trivial case from a notation — because its too trivial to be useful is damn stupid
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-23 08:29 -0400 |
| Message-ID | <mailman.77.1469276992.22221.python-list@python.org> |
| In reply to | #111782 |
On Sat, 23 Jul 2016 14:13:46 +0300
Marko Rauhamaa <marko@pacujo.net> wrote:
> > for x in sequence:
> > print('loop')
> >
> > Is that meant to print 'loop' each time around the loop, or just
> > once, at the end of the loop?
>
> I don't see an ambiguity: obviously the print call takes place after
> finishing the loop.
It's ambiguous to the reader what was actually meant. Forcing a "pass"
there shows the reader that the empty block was not a mistake.
Explicit is better than implicit.
> I wonder if there is any true case of ambiguity. I guess this is all
> about an enforced aesthetic principle: GvR doesn't like the looks of
> an empty block.
I don't think that he would be alone.
> Actually, the requirement of a dummy statement is a slight annoyance
> for the programmer. After deleting a statement, you must see if you
> have to put in a pass statement. And after adding a statement, you
> may feel the urge to remove the redundant pass statement.
If you allow empty blocks and you use it I hope that you would add a
comment so that the reader knows that you meant it.
for x in sequence: # this is an empty block
Is that better than "pass"?
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:darcy@Vex.Net
VoIP: sip:darcy@Vex.Net
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-23 16:13 +0300 |
| Message-ID | <87fur0a44p.fsf@elektro.pacujo.net> |
| In reply to | #111786 |
"D'Arcy J.M. Cain" <darcy@Vex.Net>:
> On Sat, 23 Jul 2016 14:13:46 +0300
> Marko Rauhamaa <marko@pacujo.net> wrote:
>> I don't see an ambiguity: obviously the print call takes place after
>> finishing the loop.
>
> It's ambiguous to the reader what was actually meant. Forcing a "pass"
> there shows the reader that the empty block was not a mistake.
Just let the syntax speak for itself. The code means what the language
definition says it means.
>> I wonder if there is any true case of ambiguity. I guess this is all
>> about an enforced aesthetic principle: GvR doesn't like the looks of
>> an empty block.
>
> I don't think that he would be alone.
Then just appeal to that subjective preference instead of some objective
necessity.
BTW, the standard shell requires a dummy statement in a block even
though the block boundaries are clearly marked:
while not quit; do
done
is a syntax error. This works:
while not quit; do
:
done
> If you allow empty blocks and you use it I hope that you would add a
> comment so that the reader knows that you meant it.
Once you learn the idioms of a language, you don't need to comment the
obvious.
> for x in sequence: # this is an empty block
>
> Is that better than "pass"?
Er, in that hypothetical world, the right answer would be simply:
for x in sequence:
Note that I'm not arguing for the removal of "pass." I'm just saying
it isn't strictly necessary.
Marko
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-23 09:54 -0400 |
| Message-ID | <mailman.79.1469282085.22221.python-list@python.org> |
| In reply to | #111787 |
On Sat, 23 Jul 2016 16:13:58 +0300
Marko Rauhamaa <marko@pacujo.net> wrote:
> "D'Arcy J.M. Cain" <darcy@Vex.Net>:
> > It's ambiguous to the reader what was actually meant. Forcing a
> > "pass" there shows the reader that the empty block was not a
> > mistake.
>
> Just let the syntax speak for itself. The code means what the language
> definition says it means.
Exactly so given this...
for x in sequence:
print("Something")
If the language allowed that then we know exactly what the programmer
said. What we don't know is what the programmer meant. The above is a
simple and obvious statement but real code is more complicated. Add a
few comments and a little nesting and what used to be obvious isn't.
The interpreter would still know what the programmer said but without
the pass requirement it is easier for it to be not what he meant.
Python has some nice features like this one that protect the programmer
and allow much faster development because there is a safety net. If
you like knives without handles you know where to find Perl.
Gotta go. The metaphor police are at the door.
--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:darcy@Vex.Net
VoIP: sip:darcy@Vex.Net
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-23 15:06 +0100 |
| Message-ID | <nmvtlu$oqu$1@dont-email.me> |
| In reply to | #111788 |
On 23/07/2016 14:54, D'Arcy J.M. Cain wrote:
> On Sat, 23 Jul 2016 16:13:58 +0300
> Marko Rauhamaa <marko@pacujo.net> wrote:
>> "D'Arcy J.M. Cain" <darcy@Vex.Net>:
>>> It's ambiguous to the reader what was actually meant. Forcing a
>>> "pass" there shows the reader that the empty block was not a
>>> mistake.
>>
>> Just let the syntax speak for itself. The code means what the language
>> definition says it means.
>
> Exactly so given this...
>
> for x in sequence:
> print("Something")
>
> If the language allowed that then we know exactly what the programmer
> said. What we don't know is what the programmer meant. The above is a
> simple and obvious statement but real code is more complicated. Add a
> few comments and a little nesting and what used to be obvious isn't.
> The interpreter would still know what the programmer said but without
> the pass requirement it is easier for it to be not what he meant.
>
> Python has some nice features like this one that protect the programmer
> and allow much faster development because there is a safety net. If
> you like knives without handles you know where to find Perl.
pass can only do so much. If doesn't help here:
for x in sequence:
print("Something")
print("Something else")
Was the second print meant to be indented as well or not?
Perhaps rather than 'pass', the language ought to have provided an
optional 'end' keyword to mark the end of a block. Then there would be
less speculation about what was meant:
for x in sequence:
print("Something")
end
print("Something else")
(And no speculation at all if 'end' was mandatory. Python already
provides 'else' (and 'except'?) which can do a similar job in some
circumstances.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-24 01:55 +1000 |
| Message-ID | <57939373$0$1586$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111790 |
On Sun, 24 Jul 2016 12:06 am, BartC wrote:
> pass can only do so much. If doesn't help here:
>
> for x in sequence:
> print("Something")
> print("Something else")
>
> Was the second print meant to be indented as well or not?
True. But once you start wondering about code the programmer *hasn't*
written, you could drive yourself crazy:
...but what if the second print is supposed to follow
an "if" clause, which has been left out...?
*Most* for-loops have non-empty blocks. Only a tiny minority have empty
blocks for any appreciable period of time. (This is not 1970, and we don't
write timing loops like "for x in range(1000): pass".)
*Most* code is correctly indented. So the interpreter should assume that
indentation *is correct*, unless there is a reason to doubt that. What sort
of reasons could there be?
- if the indentation increases when it shouldn't:
print("Hello")
print("World!") # unexpected indent
- if it dedents to a value that doesn't align with a previous block:
for x in sequence:
print(x)
print("dedented") # half-way between current and previous block
- if it doesn't indent when you expect it to:
for x in sequence:
print(x)
Yes, that last one *could* be an empty block. But empty blocks are rare. Its
more likely to be an error. If it's not an error, than the programmer can
just insert a "pass" statement to satisfy the interpreter.
> Perhaps rather than 'pass', the language ought to have provided an
> optional 'end' keyword to mark the end of a block. Then there would be
> less speculation about what was meant:
It can't be optional. If it were optional, we'd be no better off:
for x in sequence:
print(x)
The "end" is missing, but is it missing from the end of the empty block, or
the end of the non-empty block?
for x in sequence:
end
print(x)
for x in sequence:
print(x)
end
In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
needing to use "pass" (say) one time in a thousand when it is needed, you
would need to use "end" 999 times in a thousand when it *isn't* needed.
> for x in sequence:
> print("Something")
> end
> print("Something else")
>
> (And no speculation at all if 'end' was mandatory. Python already
> provides 'else' (and 'except'?) which can do a similar job in some
> circumstances.)
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 11:35 +0100 |
| Message-ID | <nn25m4$4d1$1@dont-email.me> |
| In reply to | #111794 |
On 23/07/2016 16:55, Steven D'Aprano wrote:
> On Sun, 24 Jul 2016 12:06 am, BartC wrote:
>
>> pass can only do so much. If doesn't help here:
>>
>> for x in sequence:
>> print("Something")
>> print("Something else")
>>
>> Was the second print meant to be indented as well or not?
>
> True. But once you start wondering about code the programmer *hasn't*
> written, you could drive yourself crazy:
>
> ...but what if the second print is supposed to follow
> an "if" clause, which has been left out...?
I didn't want to get into this subject again, but Python's indentation
scheme is fragile.
Given an otherwise correctly typed program that compiles with no errors,
then it is very easy (if Backspace or Delete is inadvertently pressed
for example), for an indent to disappear without your noticing, but a
program still compiles. And still runs without execution errors. But
might now be subtly wrong.
Deleting any other character than a leading space or tab I think is more
likely to result in an error that would be noticed, generate a compile
error, or execute error ('variable not initialised'), or that goes wrong
more obviously.
>> Perhaps rather than 'pass', the language ought to have provided an
>> optional 'end' keyword to mark the end of a block. Then there would be
>> less speculation about what was meant:
>
> It can't be optional. If it were optional, we'd be no better off:
>
> for x in sequence:
> print(x)
But that's a choice. Being optional, it means someone /can/ make use of
it...
> The "end" is missing, but is it missing from the end of the empty block, or
> the end of the non-empty block?
>
> for x in sequence:
> end
> print(x)
>
> for x in sequence:
> print(x)
> end
...then it might look like the first example above. The second would be
an error.
>
> In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
> needing to use "pass" (say) one time in a thousand when it is needed, you
> would need to use "end" 999 times in a thousand when it *isn't* needed.
Yes, well, some of us wouldn't mind! But my suggestion is simply that
you can write:
for x in sequence:
end
instead of:
for x in sequence:
pass
The first now allows statements to be added or removed from the body of
the loop without needing to change the 'end'; it wouldn't look out of
place as a trailing 'pass' would.
But thinking about it some more, it wouldn't work. All the blocks that
don't now use 'end' would look odd. I think it would either have to be
all or nothing. I guess nothing.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 11:45 +0100 |
| Message-ID | <nn2683$63f$1@dont-email.me> |
| In reply to | #111800 |
On 24/07/2016 11:35, BartC wrote:
> On 23/07/2016 16:55, Steven D'Aprano wrote:
>> In any case, using "end" instead of "pass" is a poor tradeoff. Instead of
>> needing to use "pass" (say) one time in a thousand when it is needed, you
>> would need to use "end" 999 times in a thousand when it *isn't* needed.
>
> Yes, well, some of us wouldn't mind!
'end' to terminate a block can be emulated of course:
end=0
def fn(a):
if a<=1:
return 1
else:
return fn(a-1)
end
end
And in this example it wouldn't impact on performance as it is not
evaluated.
But although it can make source code look more conventional, it would
not be supported by the language (repeated, out of place or missing
'end' lines are not an error). And an empty block will still need pass.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-24 21:27 +1000 |
| Message-ID | <mailman.87.1469359641.22221.python-list@python.org> |
| In reply to | #111801 |
On Sun, Jul 24, 2016 at 8:45 PM, BartC <bc@freeuk.com> wrote:
> 'end' to terminate a block can be emulated of course:
>
> end=0
>
> def fn(a):
> if a<=1:
> return 1
> else:
> return fn(a-1)
> end
> end
>
> And in this example it wouldn't impact on performance as it is not
> evaluated.
Actually, they would be (you'll have a LOAD_GLOBAL followed by
POP_TOP). Much better to use Python's inbuilt hash-braces support,
available via a hash-future directive.
#from __future__ import braces
def fn(a): #{
if a <= 1: #{
return 1
#}
else: #{
return fn(a-1)
#}
#}
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 14:09 +0100 |
| Message-ID | <nn2em9$vm1$1@dont-email.me> |
| In reply to | #111801 |
On 24/07/2016 11:45, BartC wrote:
> On 24/07/2016 11:35, BartC wrote:
> 'end' to terminate a block can be emulated of course:
>
> end=0
>
> def fn(a):
> if a<=1:
> return 1
> else:
> return fn(a-1)
> end
> end
Actually this is a good example of how tabs can go wrong (and how the
tab system /is/ fragile - sorry but it is).
I almost certainly wrote the above using 4 and 8 spaces for the tabs,
except for the 'return 1' where I must have used an actual tab by
mistake. (And I tested it now by doing just that, and posting in alt.test.)
So the original /looked/ correct in my Thunderbird newsreader before I
posted. But after I posted, that tab somehow got changed to 4 spaces, as
it now looks wrong.
In this instance, the result won't compile. But it's not hard to imagine
a much larger program where that change would go unnoticed, and the
result is still valid code**.
Then anyone copying and pasting the posted code, would have a program
with a bug in it.
Mysteriously however, Chris Angelico's reply which quoted my post,
showed a properly tabbed version! (Unless he fixed it manually.)
(** Where working code has been posted, then Python will have picked up
inconsistencies where tabs and spaces are mixed. However take this code:
def fn():
<tab>if a:
<8 spaces>pass
This looks fine in my editor when <tab> is expanded to 4 spaces:
def fn():
if a:
pass
Python however doesn't like it (Python 2 doesn't anyway), because it
somehow assumes tabs expand to 8 spaces, so that the two indents look
like this to it:
def fn():
if a:
pass
So I can see a lot of problems whenever tabs are expanded differently:
a=1
b=0
if a:
<tab>if b:
<tab><tab>print ("One")
<8 spaces>print ("Two")
In my editor with 4-space tabs, it looks like the code will print
nothing as the two print lines are aligned within the 'if b:' block. But
in Python 2, it will print "Two". Python 3 more wisely reports the
inconsistency.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-24 23:24 +1000 |
| Message-ID | <mailman.90.1469366700.22221.python-list@python.org> |
| In reply to | #111806 |
On Sun, Jul 24, 2016 at 11:09 PM, BartC <bc@freeuk.com> wrote: > Actually this is a good example of how tabs can go wrong (and how the tab > system /is/ fragile - sorry but it is). > > I almost certainly wrote the above using 4 and 8 spaces for the tabs, except > for the 'return 1' where I must have used an actual tab by mistake. (And I > tested it now by doing just that, and posting in alt.test.) > No, it's an example of how *mixing tabs and spaces* can go wrong. And in fact will always go wrong unless you legislate the width of a tab. (Recommendation: A tab is equal to 3.14159 spaces. Now you can't get confused. Use 6.283 spaces if that's too narrow for you.) So don't mix tabs and spaces. Ever. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 15:05 +0100 |
| Message-ID | <nn2hvd$a1o$1@dont-email.me> |
| In reply to | #111807 |
On 24/07/2016 14:24, Chris Angelico wrote: > On Sun, Jul 24, 2016 at 11:09 PM, BartC <bc@freeuk.com> wrote: >> Actually this is a good example of how tabs can go wrong (and how the tab >> system /is/ fragile - sorry but it is). >> >> I almost certainly wrote the above using 4 and 8 spaces for the tabs, except >> for the 'return 1' where I must have used an actual tab by mistake. (And I >> tested it now by doing just that, and posting in alt.test.) >> > > No, it's an example of how *mixing tabs and spaces* can go wrong. And > in fact will always go wrong unless you legislate the width of a tab. That's easy to say. How do you actually ensure that they aren't mixed? The software may not highlight the difference. I use 100% tabs in my editor. While in Thunderbird, I have to use 100% spaces otherwise it will screw up. But what stops me pressing tab out of habit? The code looks right, I post it, and if it then goes wrong, I might not notice. Nor would anyone else. Also, sometimes you want to paste code into Thunderbird that contains tabs; that can be erratic too. And very often I want to post other people's code that is full of spaces (notably from Thunderbird), into mine that is full of tabs. (I have the same problem with other languages, but there it's largely cosmetic.) So I still think it's fragile, meaning you have to take a lot of extra care. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-25 00:32 +1000 |
| Message-ID | <5794d188$0$1618$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111809 |
On Mon, 25 Jul 2016 12:05 am, BartC wrote: >> No, it's an example of how *mixing tabs and spaces* can go wrong. And >> in fact will always go wrong unless you legislate the width of a tab. > > That's easy to say. How do you actually ensure that they aren't mixed? > The software may not highlight the difference. (1) Use a better editor. (2) Use a linter that checks for dodgy indentation. (3) Run the "tabnanny" module on your script: python -m tabnanny myscripy.py (4) Run Python 2.7 with the -t option to warn about inconsistent tab usage, or -tt to raise errors. (5) Or for that matter any version of Python going all the way back to Python 1.5, if not older. There has been no excuse for getting bitten by mixed tabs/spaces since at least 1998. (6) Or upgrade to Python 3, which will automatically enforce the rule about not mixing tabs and spaces. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-25 12:40 +1200 |
| Message-ID | <dvl5f5Fal1qU1@mid.individual.net> |
| In reply to | #111809 |
BartC wrote:
> On 24/07/2016 14:24, Chris Angelico wrote:
>
>> No, it's an example of how *mixing tabs and spaces* can go wrong. And
>> in fact will always go wrong unless you legislate the width of a tab.
>
> That's easy to say. How do you actually ensure that they aren't mixed?
> The software may not highlight the difference.
Python 3 will tell you immediately, since it forbids
mixing tabs and spaces.
>>> def f():
... a
... b
File "<stdin>", line 3
b
^
TabError: inconsistent use of tabs and spaces in indentation
> So I still think it's fragile, meaning you have to take a lot of extra
> care.
The practical experience of a very large number of Python
programmers suggests that it requires very little additional
care over and above that normally required for programming.
What's your experience? How often has this caused you trouble,
and what proportion is it of all the Python programming you've
done?
--
Greg
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 02:14 +0100 |
| Message-ID | <nn3p67$949$1@dont-email.me> |
| In reply to | #111844 |
On 25/07/2016 01:40, Gregory Ewing wrote:
> BartC wrote:
>> So I still think it's fragile, meaning you have to take a lot of extra
>> care.
>
> The practical experience of a very large number of Python
> programmers suggests that it requires very little additional
> care over and above that normally required for programming.
>
> What's your experience? How often has this caused you trouble,
> and what proportion is it of all the Python programming you've
> done?
>
I've done little Python coding but still, having to use kid gloves for
indents does figure quite a bit in that.
I can give some more examples but I'll probably be told that I'm using
the wrong tools! Which suggest there is a problem, but the effort has
gone into working around them using external tools. (But understandable
if the language design was fixed 25 years ago.)
For example:
if cond:
a
b
I want to comment out the if statement temporarily, but I also have to
fix the indents:
#if cond:
a
b
(Or add the comment and insert a dummy 'if 1:'.)
Or I want to add a temporary condition around:
a
b
which again requires me to indent those statements (and unindent them
again later). Or I want to permanently have a commented out #if guard
around some code:
#if cond:
a
b
to be uncommented from time to time (to do with debugging). But it's not
as simple as just uncommenting that one line.
Or I want to have a temporary print statement within a block, but it
needs to be at the right indentation. Not a great imposition, but it's
now less visible as a temporary addition.
Or I need to move or copy code from one location to another, but the
indentation levels are different. This would need fixing in other
languages too, but if this is part of a temporary try out which will
change again a few minutes later, I can dispense with the correct
indentation in another language, until the code is more permanent.
In short, because correct indentation is required at all times, it's
less flexible when you want to do a lot of messing around.
Now, if I was going to do a LOT of Python coding, then I would solve
most of those problems (by having my own tool to superimpose a more
amenable syntax on the language). For casual work though I have to go
along with the indent scheme. (And there are usually other issues with
Python that are more troublesome than getting the layout right.)
I'll leave you with a code fragment that might be pasted from elsewhere
(it's not meant to mean anything):
if cond:
a
b
c
The question is: is this the whole block? We don't know, as we can't see
what came next. But if now I add the next line, and it was this
(anything actually with one less indent):
if cond2:
then yes it was the whole block, IF we assume an indent didn't get
clobbered in the process! But if the line happened to be:
else:
now we know for sure.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-07-25 11:45 +1000 |
| Message-ID | <mailman.105.1469411123.22221.python-list@python.org> |
| In reply to | #111847 |
BartC <bc@freeuk.com> writes: > On 25/07/2016 01:40, Gregory Ewing wrote: > > What's your experience? How often has this caused you trouble, and > > what proportion is it of all the Python programming you've done? > > I've done little Python coding Then you are not in a position to make the prnouncements about Python's effect on coding efficiency that you are pronouncing, in this and other threads. > I can give some more examples but I'll probably be told that I'm using > the wrong tools! You should gain a lot more experience using Python for productive work, before declaring any effects on productive work inherent to the language design. > Which suggest there is a problem Or that the programming tools of 25 years ago compare poorly to today's tools. Even tools that have existed for 25 years have benefited from the intervening time. No-one uses Emacs *as it was 25 years ago* and expects to be as proficient as someone using Emacs as it is today. -- \ “Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-25 09:54 -0700 |
| Message-ID | <436abc76-29e8-4964-859d-b1223a1c7528@googlegroups.com> |
| In reply to | #111848 |
On Monday, July 25, 2016 at 7:15:36 AM UTC+5:30, Ben Finney wrote: > Even tools that have existed for 25 years have benefited from the > intervening time. No-one uses Emacs *as it was 25 years ago* and expects > to be as proficient as someone using Emacs as it is today. As a general comment — fine Your exemplar however is ironic What everyone calls window it calls frame; what everyone calls pane it calls window because its legacy from pre-gui days What everyone calls Alt it calls Meta and shortens it to “M-” because the Sun workstations that have been dead 20 years had a Meta-key And the most annoying bugbear: The whole world uses cua keys: https://en.wikipedia.org/wiki/IBM_Common_User_Access it proudly sticks to what it was doing pre-cua I could go on…
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-26 03:02 +1000 |
| Message-ID | <mailman.112.1469466152.22221.python-list@python.org> |
| In reply to | #111866 |
On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody <rustompmody@gmail.com> wrote: > The whole world uses cua keys: > https://en.wikipedia.org/wiki/IBM_Common_User_Access > [emacs] proudly sticks to what it was doing pre-cua Sadly, the "whole world" doesn't. Windows itself lacks quite a few of the CUA keys (ask a Windows user how to move a window with the keyboard, and s/he won't say "Alt-F7"), and some Windows applications make this even worse (Adobe Reader egregiously so - you can't even use Ctrl-Ins to copy to the clipboard, despite all the rest of Windows supporting it). But hey. MOST of the world uses the CUA keys. And yes, Emacs doesn't. For better or for worse, you have to learn Emacs as its own thing. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web