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 1 of 13 [1] 2 3 … 13 Next page →
| From | Kent Tong <kent.tong.mo@gmail.com> |
|---|---|
| Date | 2016-07-22 08:33 -0700 |
| Subject | Why not allow empty code blocks? |
| Message-ID | <b80ae0ca-d8b2-4430-96a1-7a6768b177ef@googlegroups.com> |
Hi 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? thanks in advance
[toc] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2016-07-22 16:44 +0000 |
| Message-ID | <nmtiht$sh7$1@dont-email.me> |
| In reply to | #111760 |
Kent Tong wrote: > Hi > > 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? > > thanks in advance Because it's more likely that you have an indentation error than an intentional need for an empty code block, and Python's trying to prevent you shooting yourself in the foot. If you actually needed an empty code block, the langugage provides a way of marking that emptyness as intentional. That way is the pass statement. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-23 11:49 +1000 |
| Message-ID | <5792cd34$0$1587$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111760 |
On Sat, 23 Jul 2016 01:33 am, Kent Tong wrote:
> Hi
>
> 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?
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. 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.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Kent Tong <kent.tong.mo@gmail.com> |
|---|---|
| Date | 2016-07-22 19:06 -0700 |
| Message-ID | <af094321-817e-4c7e-b885-3b9b69c32448@googlegroups.com> |
| In reply to | #111778 |
On Saturday, July 23, 2016 at 9:49:51 AM UTC+8, Steven D'Aprano wrote:
> Because it cannot tell the difference between an empty code block and
> failing to indent the code block:
>
> for x in sequence:
> print('loop')
Thanks for the excellent answer!
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-23 14:13 +0300 |
| Message-ID | <87vazwppxx.fsf@elektro.pacujo.net> |
| In reply to | #111778 |
Steven D'Aprano <steve@pearwood.info>:
> 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.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-23 21:34 +1000 |
| Message-ID | <mailman.74.1469273692.22221.python-list@python.org> |
| In reply to | #111782 |
On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> 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. How often do you actually need empty statements, adding stuff, removing stuff, like that? Possibly there's a code smell here. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-23 14:49 +0300 |
| Message-ID | <87r3akpob2.fsf@elektro.pacujo.net> |
| In reply to | #111783 |
Chris Angelico <rosuav@gmail.com>:
> On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> 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.
>
> How often do you actually need empty statements, adding stuff,
> removing stuff, like that? Possibly there's a code smell here.
Quite often. For example:
class ItHitFan(Exception): pass
==>
class ItHitFan(Exception):
def __init__(self, huh):
super().__init__()
self.huh = huh
Marko
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-23 15:00 +0100 |
| Message-ID | <nmvt9g$nj6$1@dont-email.me> |
| In reply to | #111783 |
On 23/07/2016 12:34, Chris Angelico wrote: > On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >>> 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. > > How often do you actually need empty statements, adding stuff, > removing stuff, like that? Possibly there's a code smell here. All the time? For example when creating a set of empty functions to be populated later, or empty branches of if and so on to be filled in as so you go. Or, for debugging or other reasons, when you need to comment out the contents of a block. Then pass needs to be added. However in the absence of a strong end-of-block indicator and having to infer the end of the block from what may or may not follow, then pass is useful when the block is empty. But I don't think it needed to be mandatory. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-24 00:19 +1000 |
| Message-ID | <mailman.81.1469283564.22221.python-list@python.org> |
| In reply to | #111789 |
On Sun, Jul 24, 2016 at 12:00 AM, BartC <bc@freeuk.com> wrote: > On 23/07/2016 12:34, Chris Angelico wrote: >> >> On Sat, Jul 23, 2016 at 9:13 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >>>> >>>> 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. >> >> >> How often do you actually need empty statements, adding stuff, >> removing stuff, like that? Possibly there's a code smell here. > > > All the time? No, or I wouldn't have qualified it with the very weak "possibly". > For example when creating a set of empty functions to be populated later, or > empty branches of if and so on to be filled in as so you go. Forget 'pass' - just give each function a docstring. That syntactically defines the block, and it's useful. > Or, for debugging or other reasons, when you need to comment out the > contents of a block. Then pass needs to be added. How often do you comment out an entire block and not its header? I don't remember the last time I did that. It's certainly not so common that adding 'pass' takes up a significant part of a debugging session. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-29 10:58 +0200 |
| Message-ID | <mailman.18.1469782758.6033.python-list@python.org> |
| In reply to | #111789 |
Op 23-07-16 om 16:19 schreef Chris Angelico: > On Sun, Jul 24, 2016 at 12:00 AM, BartC <bc@freeuk.com> wrote: >> Or, for debugging or other reasons, when you need to comment out the >> contents of a block. Then pass needs to be added. > How often do you comment out an entire block and not its header? I > don't remember the last time I did that. It's certainly not so common > that adding 'pass' takes up a significant part of a debugging session. > > ChrisA As BartC already mentions it happens fairly often during debugging. Something like. try: Some code except Some_Exception: # Commented code for when I am debugging <Some code> pass
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-29 07:14 -0400 |
| Message-ID | <mailman.21.1469790913.6033.python-list@python.org> |
| In reply to | #111789 |
On Fri, 29 Jul 2016 10:58:35 +0200 Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote: > As BartC already mentions it happens fairly often during debugging. > Something like. > > try: > Some code > except Some_Exception: > # Commented code for when I am debugging <Some code> > pass I realize that that's a simplified example but really, isn't this just as easy? try: Some code # except Some_Exception: # Commented code for when I am debugging <Some code> If your code block really is one line is "pass #" really so much more of a hardship than "#"? If it is a large block use "pass #@#" which is easy to remove with a search and replace. In any case, the rule about premature optimization for programs can probably be applied to developers too. Is saving a "pass" once in a while really where you need to focus your debugging efforts? -- 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-29 14:15 +0100 |
| Message-ID | <nnfkss$2c8$1@dont-email.me> |
| In reply to | #112012 |
On 29/07/2016 12:14, D'Arcy J.M. Cain wrote: > On Fri, 29 Jul 2016 10:58:35 +0200 > Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote: >> As BartC already mentions it happens fairly often during debugging. >> Something like. >> >> try: >> Some code >> except Some_Exception: >> # Commented code for when I am debugging <Some code> >> pass > > I realize that that's a simplified example but really, isn't this just > as easy? > > try: > Some code > # except Some_Exception: > # Commented code for when I am debugging <Some code> Will it behave the same way when there is a Some_Exception exception? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2016-07-29 07:41 -0600 |
| Message-ID | <mailman.24.1469799713.6033.python-list@python.org> |
| In reply to | #112014 |
On Jul 29, 2016 7:22 AM, "BartC" <bc@freeuk.com> wrote: > > On 29/07/2016 12:14, D'Arcy J.M. Cain wrote: >> >> On Fri, 29 Jul 2016 10:58:35 +0200 >> Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote: >>> >>> As BartC already mentions it happens fairly often during debugging. >>> Something like. >>> >>> try: >>> Some code >>> except Some_Exception: >>> # Commented code for when I am debugging <Some code> >>> pass >> >> >> I realize that that's a simplified example but really, isn't this just >> as easy? >> >> try: >> Some code >> # except Some_Exception: >> # Commented code for when I am debugging <Some code> > > > Will it behave the same way when there is a Some_Exception exception? Besides that, a try block on its own with no dependents blocks isn't even legal syntax. You'd have to comment the try as well and replace it with "if 1" or similar.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-29 23:43 +1000 |
| Message-ID | <579b5d8c$0$1615$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112014 |
On Fri, 29 Jul 2016 11:15 pm, BartC wrote:
> On 29/07/2016 12:14, D'Arcy J.M. Cain wrote:
>> On Fri, 29 Jul 2016 10:58:35 +0200
>> Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
>>> As BartC already mentions it happens fairly often during debugging.
>>> Something like.
>>>
>>> try:
>>> Some code
>>> except Some_Exception:
>>> # Commented code for when I am debugging <Some code>
>>> pass
>>
>> I realize that that's a simplified example but really, isn't this just
>> as easy?
>>
>> try:
>> Some code
>> # except Some_Exception:
>> # Commented code for when I am debugging <Some code>
>
> Will it behave the same way when there is a Some_Exception exception?
Of course it won't, which is why I don't believe all these folks who claim
that they regularly ("all the time", "fairly often") replace except blocks
with `pass`. I call shenanigans -- perhaps you do it *occasionally*, but as
a general rule, you can rarely replace the exception handler with a
do-nothing clause and expect your code to work:
try:
block
except SomeException:
handle error
process
If you remove the error handling block, replacing it with `pass`, in general
your code will just break again as soon as it continues processing.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-29 15:55 +0200 |
| Message-ID | <mailman.26.1469800552.6033.python-list@python.org> |
| In reply to | #112016 |
Op 29-07-16 om 15:43 schreef Steven D'Aprano:
> Of course it won't, which is why I don't believe all these folks who claim
> that they regularly ("all the time", "fairly often") replace except blocks
> with `pass`. I call shenanigans -- perhaps you do it *occasionally*, but as
> a general rule, you can rarely replace the exception handler with a
> do-nothing clause and expect your code to work:
>
> try:
> block
> except SomeException:
> handle error
> process
>
> If you remove the error handling block, replacing it with `pass`, in general
> your code will just break again as soon as it continues processing.
I think the case where you just want to ignore the exception, but it can
at times be useful to get some extra logging information for debuging
purposes, is not that rare as you seem to suggest.
--
Antoon Pardon
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-30 00:38 +1000 |
| Message-ID | <579b6a68$0$1612$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112018 |
On Fri, 29 Jul 2016 11:55 pm, Antoon Pardon wrote:
> Op 29-07-16 om 15:43 schreef Steven D'Aprano:
>> Of course it won't, which is why I don't believe all these folks who
>> claim that they regularly ("all the time", "fairly often") replace except
>> blocks with `pass`. I call shenanigans -- perhaps you do it
>> *occasionally*, but as a general rule, you can rarely replace the
>> exception handler with a do-nothing clause and expect your code to work:
>>
>> try:
>> block
>> except SomeException:
>> handle error
>> process
>>
>> If you remove the error handling block, replacing it with `pass`, in
>> general your code will just break again as soon as it continues
>> processing.
>
> I think the case where you just want to ignore the exception, but it can
> at times be useful to get some extra logging information for debuging
> purposes, is not that rare as you seem to suggest.
I think I can count the number of times I've wanted to ignore an exception
on the fingers of one hand. And when I did, there was no need to debug it,
because I only ignore expected failures. There's nothing to debug.
But even if you do it all the time, how do you "get some extra logging
information" by replacing the "except" block with `pass`? If you replaced
the "except" block with a call to the logger, that would be one thing.
But "pass", that won't do the job.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-29 20:32 +0200 |
| Message-ID | <mailman.33.1469817261.6033.python-list@python.org> |
| In reply to | #112020 |
Op 29-07-16 om 16:38 schreef Steven D'Aprano:
> On Fri, 29 Jul 2016 11:55 pm, Antoon Pardon wrote:
>
>> Op 29-07-16 om 15:43 schreef Steven D'Aprano:
>>> Of course it won't, which is why I don't believe all these folks who
>>> claim that they regularly ("all the time", "fairly often") replace except
>>> blocks with `pass`. I call shenanigans -- perhaps you do it
>>> *occasionally*, but as a general rule, you can rarely replace the
>>> exception handler with a do-nothing clause and expect your code to work:
>>>
>>> try:
>>> block
>>> except SomeException:
>>> handle error
>>> process
>>>
>>> If you remove the error handling block, replacing it with `pass`, in
>>> general your code will just break again as soon as it continues
>>> processing.
>>
>> I think the case where you just want to ignore the exception, but it can
>> at times be useful to get some extra logging information for debuging
>> purposes, is not that rare as you seem to suggest.
>
> I think I can count the number of times I've wanted to ignore an exception
> on the fingers of one hand. And when I did, there was no need to debug it,
> because I only ignore expected failures. There's nothing to debug.
You really should stop, generalising your own situation.
> But even if you do it all the time, how do you "get some extra logging
> information" by replacing the "except" block with `pass`? If you replaced
> the "except" block with a call to the logger, that would be one thing.
> But "pass", that won't do the job.
You don't seem to understand. There is no real except block to be replaced
by pass. There is sometime an except block added (or uncommented) to get
logging information.
--
Antoon Pardon.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-30 13:49 +1000 |
| Message-ID | <579c23de$0$1596$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112025 |
On Sat, 30 Jul 2016 04:32 am, Antoon Pardon wrote:
> Op 29-07-16 om 16:38 schreef Steven D'Aprano:
>> On Fri, 29 Jul 2016 11:55 pm, Antoon Pardon wrote:
>>
>>> Op 29-07-16 om 15:43 schreef Steven D'Aprano:
>>>> Of course it won't, which is why I don't believe all these folks who
>>>> claim that they regularly ("all the time", "fairly often") replace
>>>> except blocks with `pass`. I call shenanigans -- perhaps you do it
>>>> *occasionally*, but as a general rule, you can rarely replace the
>>>> exception handler with a do-nothing clause and expect your code to
>>>> work:
>>>>
>>>> try:
>>>> block
>>>> except SomeException:
>>>> handle error
>>>> process
>>>>
>>>> If you remove the error handling block, replacing it with `pass`, in
>>>> general your code will just break again as soon as it continues
>>>> processing.
>>>
>>> I think the case where you just want to ignore the exception, but it can
>>> at times be useful to get some extra logging information for debuging
>>> purposes, is not that rare as you seem to suggest.
>>
>> I think I can count the number of times I've wanted to ignore an
>> exception on the fingers of one hand. And when I did, there was no need
>> to debug it, because I only ignore expected failures. There's nothing to
>> debug.
>
> You really should stop, generalising your own situation.
I'm not just generalising from code I've written. I'm generalising from code
I've reviewed, code I've read, code I've seen others admire, code I've seen
others mock and laugh at, and best practices I've read about. That's
called "learning to be a better programmer".
>> But even if you do it all the time, how do you "get some extra logging
>> information" by replacing the "except" block with `pass`? If you replaced
>> the "except" block with a call to the logger, that would be one thing.
>> But "pass", that won't do the job.
>
> You don't seem to understand. There is no real except block to be replaced
> by pass. There is sometime an except block added (or uncommented) to get
> logging information.
Perhaps its *you* who doesn't understand. The subject line talks
about "empty code blocks", and Bart has suggested that instead of having to
write
try:
something
except SomeException:
pass
process
(which he considers far too difficult) we should allow empty code blocks:
try:
something
except SomeException:
process
because apparently saving that one indented line with "pass" makes all the
difference in language usability. That lead to Chris asking how common it
was to do this. That's when Bart said that he frequently *replaced* an
existing except block with "pass":
# before
try:
something
except SomeException:
handle error
handle it some more
process
# after
try:
something
except SomeException:
pass
process
At which point *you agreed with him*:
[quote]
As BartC already mentions it happens fairly often during debugging.
Something like.
try:
Some code
except Some_Exception:
# Commented code for when I am debugging <Some code>
pass
[end quote]
So now you're changing your story, and claiming that you're not actually
replacing an existing except block with pass (because I think any
experienced Python developer, which Bart is not, realises that's not likely
to work). Now you've got a use-case where we start with:
# before
some code
more processing
and add an entire try...except around it:
# step 1
try:
some code
except SomeException:
debugging code
more processing
*and then* comment out the debugging code and replace it with pass:
# after, as stated by you
try:
some code
except SomeException:
# debugging code
pass
more processing
Of course it's legitimate to wrap some failing code in a temporary
try...except block for debugging purposes. But that's not an empty code
block, and its not "pass", and it's not relevant to Chris' question.
And what happens once you have finished debugging the code? According to
your post, you comment out the debugging code, replacing it by "pass". And
you do this *frequently*.
Okay, if you say you do that, I have to believe you. If we take you at your
word, then we can only conclude that your code is littered with the
detritus of old debugging code and unnecessary try...except blocks which do
nothing. That's practically the definition of *poor programming*, leaving
old code commented out to rot, but if you say that's what you do, who am I
to argue that you don't?
Since I don't actually believe you are that poor a programmer, I suspect
that what you actually do is not replace the debugging code with "pass",
like you claim, but that once you have finished debugging that section of
the code you remove the unneeded try...except block and dead, unused
debugging code, returning it to the "before" state.
D'Arcy's suggestion of leaving the debugging code in with a runtime switch
to turn it on and off also makes sense. I'm partial to switching on the
special __debug__ global. But we're getting further and further away from
Bart's scenario, of a bare "pass". *That's* what I don't believe in: this
supposed scenario where people have existing code blocks that they have to
replace with "pass", and that happens *frequently enough to matter*.
And of course as D'Arcy has pointed out, these two are not the same:
# before
some code
# after
try:
some code
except SomeException:
pass
To make the second one equivalent to the first, one should use *raise*, not
pass. In which case you could even leave your debugging code in there,
uncommented out:
try:
some code
except SomeException:
raise
debugging code
all the better to confuse those who have to maintain the program in your
absence.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-08-02 09:31 +0200 |
| Message-ID | <mailman.108.1470123135.6033.python-list@python.org> |
| In reply to | #112041 |
Op 30-07-16 om 05:49 schreef Steven D'Aprano: > On Sat, 30 Jul 2016 04:32 am, Antoon Pardon wrote: > > > Perhaps its *you* who doesn't understand. The subject line talks > about "empty code blocks", and Bart has suggested that instead of having to > write > > ... > > So now you're changing your story, and claiming that you're not actually > replacing an existing except block with pass (because I think any > experienced Python developer, which Bart is not, realises that's not likely > to work). Now you've got a use-case where we start with: I am not changing my story, I am describing it from a different view point. > # before > some code > more processing > > and add an entire try...except around it: > > # step 1 > try: > some code > except SomeException: > debugging code > more processing > > *and then* comment out the debugging code and replace it with pass: > > # after, as stated by you > try: > some code > except SomeException: > # debugging code > pass > more processing No I start with writing the above code and the debugging code uncommented. > Of course it's legitimate to wrap some failing code in a temporary > try...except block for debugging purposes. But that's not an empty code > block, and its not "pass", and it's not relevant to Chris' question. You still don't seem to understand. This code doesn't fail. SomeException can normally safely be ignored. However some of the called functions might throw it wrongly. > And what happens once you have finished debugging the code? According to > your post, you comment out the debugging code, replacing it by "pass". And > you do this *frequently*. That depends what you mean with *frequently*. It depends on the nastyness of the bug I am chasing. > Okay, if you say you do that, I have to believe you. If we take you at your > word, then we can only conclude that your code is littered with the > detritus of old debugging code and unnecessary try...except blocks which do > nothing. That's practically the definition of *poor programming*, leaving > old code commented out to rot, but if you say that's what you do, who am I > to argue that you don't? You are not taking my word for it, you are jumping to conclusions. The fact that I do this at some point, doesn't mean I leave it in indefenatly. > Since I don't actually believe you are that poor a programmer, I suspect > that what you actually do is not replace the debugging code with "pass", > like you claim, but that once you have finished debugging that section of > the code you remove the unneeded try...except block and dead, unused > debugging code, returning it to the "before" state. But it isn't an unneeded try ... except block. I need the try ... except block to ignore an exception that should be harmless at that point. > D'Arcy's suggestion of leaving the debugging code in with a runtime switch > to turn it on and off also makes sense. Yes that makes sense. However if I think that is worth the while I usally just start using the logging module. -- Antoon
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-29 12:28 -0400 |
| Message-ID | <mailman.31.1469809737.6033.python-list@python.org> |
| In reply to | #112016 |
On Fri, 29 Jul 2016 15:55:07 +0200
Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
> I think the case where you just want to ignore the exception, but it
> can at times be useful to get some extra logging information for
> debuging purposes, is not that rare as you seem to suggest.
The way I handle that is:
DEBUG = False # near top of file
...
try:
block
except SomeException:
if DEBUG: log("Blah blah blah")
Usually it's in a class so it would be "self.DEBUG". You can also get
fancy with debug levels instead of True and False.
My theory is that if I need to log it today there's a more than zero
chance I might need to log it again one day.
--
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]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web