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 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-25 10:11 -0700 |
| Message-ID | <654dbafd-6ac8-4f96-b7c5-03200454aeca@googlegroups.com> |
| In reply to | #111867 |
On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: > On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody 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). Ok I was speaking in-a-manner-of-speaking -- in two ways All means most Cua means the most common cua-keys — C-x C-c C-v of which the first two specially are so deeply embedded into emacs as prefixes for 100s of other functions that its hard to change without significant upheaval > > 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. Yeah… Just playing around with magit It the tool of choice in emacs world as a git client And in all probability the best git client around So yes emacs is unbeatable and emacs is obsolete And that’s what makes it so annoying — impossible to find a replacement
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-26 03:26 +1000 |
| Message-ID | <mailman.113.1469467588.22221.python-list@python.org> |
| In reply to | #111868 |
On Tue, Jul 26, 2016 at 3:11 AM, Rustom Mody <rustompmody@gmail.com> wrote: > On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: >> On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody 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). > > Ok I was speaking in-a-manner-of-speaking -- in two ways > All means most > Cua means the most common cua-keys — C-x C-c C-v > of which the first two specially are so deeply embedded into emacs as prefixes > for 100s of other functions that its hard to change without significant upheaval Wrong - CUA's standard keys are Shift-Del, Ctrl-Ins, Shift-Ins for the same operations. The alphabetics are not part of the CUA standard. That said, though, most applications support both - primarily because most GUI widgets are built to support both, and applications are taught to respond to signals like 'paste'. This is one of those cases where building your own is both way more work AND way less useful to people; the same thing often happens when a program decides to be "cute" with its UI and get rid of the title bar and regular frame, painting its own window borders and stuff. It's a lot of work to make that look decent, and then you end up with something that doesn't play nicely with the rest of the system. You'd better have a really good justification for that - and no, "it looks pretty" is NOT that justification. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-25 19:43 -0700 |
| Message-ID | <226c0275-fbbf-4cc4-8499-49965ae46f38@googlegroups.com> |
| In reply to | #111869 |
On Monday, July 25, 2016 at 10:56:41 PM UTC+5:30, Chris Angelico wrote: > On Tue, Jul 26, 2016 at 3:11 AM, Rustom Mody wrote: > > On Monday, July 25, 2016 at 10:32:45 PM UTC+5:30, Chris Angelico wrote: > >> On Tue, Jul 26, 2016 at 2:54 AM, Rustom Mody 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). > > > > Ok I was speaking in-a-manner-of-speaking -- in two ways > > All means most > > Cua means the most common cua-keys — C-x C-c C-v > > of which the first two specially are so deeply embedded into emacs as prefixes > > for 100s of other functions that its hard to change without significant upheaval > > Wrong - CUA's standard keys are Shift-Del, Ctrl-Ins, Shift-Ins for the > same operations. The alphabetics are not part of the CUA standard. > That said, though, most applications support both - primarily because > most GUI widgets are built to support both, and applications are > taught to respond to signals like 'paste'. You must be right Ironically I learnt the word cua from emacs’ cua-mode which basically make C-c C-x C-v (dont know which others) behave like the rest of the world expects. Trouble is the first two are so deeply enmeshed into emacs that it does a bad job of it. And conventional wisdom in emacs land is to avoid it and get used to the (30+ year old!) emacs standard
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2016-07-24 20:48 -0600 |
| Message-ID | <mailman.106.1469415288.22221.python-list@python.org> |
| In reply to | #111847 |
On 07/24/2016 07:14 PM, BartC wrote: > 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.) I only code in Python these days and I simply do not find the indenting syntax to be a problem. Far more often I'm bitten by the dynamic nature of Python (would happen in any dynamic language). I'll be using a particular member attribute which I accidentally misspell somewhere and sometimes that results in silent failure. Something doesn't work, but no exception is thrown. Unit tests, and perhaps lint, are required to catch these errors. That is one thing about a dynamic language: comprehensive testing is required as you go along. > > 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 Good example, and I've encountered this one, but honestly fixing the indent is best programming practice anyway. If I want to preserve context, copying the entire block and then commenting it out to preserve it is what I prefer. Anyway, I'd want to fix indenting even if I was using braces. Just to make the code readable and maintainable over time as more often than not temporary becomes permanent. If it's truly a temporary removal, your "if 1:" idiom seems most correct to me, with the original condition commented out. Also there are times when I simply don't worry about commenting things out. I just delete them and fix the indenting and move on with life. I can always revert my changes if I end up barking up the wrong tree. > > (Or add the comment and insert a dummy 'if 1:'.) This is a good idea for temporarily taking out the condition. Sounds like good practice to me. > > 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. With a end statement you'd of course have to comment out both the if and the end lines. Just to nitpick. > > 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. Pretty much all print statements in my code are visible as a temporary addition. There is really little other reason to use it. So every so often I'll search for all my print statements and comment them out or delete them once the code is operational. But even then, using a logging function is probably even better solution. > 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 venerable old ViM I just highlight the block and move it in or out. Not having editor support would make this very painful. But you'd be wanting to adjust the indenting anyway, in any language. So while it would cause an error in Python, in any other language you'd want to do this anyway, just to make the code readable. > In short, because correct indentation is required at all times, it's > less flexible when you want to do a lot of messing around. I guess I just don't find this to be particularly problematic. And Python is great for doing a lot of messing around in for me. > 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 tend to not have a lot of strong opinions about languages I have little experience in. What is it about your experience that leads to such strong opinions about a language you do very little in? I dislike what I see of Ruby but I have no opinions strong enough to voice on the Ruby lists (or even read them). Just curious. > 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. I've never had this problem in Python. I have the source file in front of me. I can scroll down until the block ends. And if the programmer keeps his functions short, it's as readable or more readable than in any other language. I submit you'd have the same readability problem with a very long and deeply blocked C function without the help of something like brace matching in your editor. It's true I can reformat the file to clean up the indenting in a C program, but the author should have done that to begin with. Just because a C function compiles doesn't mean it's correct, and if the indenting is all over the place you can't easily follow the logic and judge its correctness anyway.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-25 13:12 +1000 |
| Message-ID | <mailman.107.1469416330.22221.python-list@python.org> |
| In reply to | #111847 |
On Mon, Jul 25, 2016 at 12:48 PM, Michael Torrie <torriem@gmail.com> wrote: > Far more often I'm bitten by the dynamic nature of Python (would happen > in any dynamic language). I'll be using a particular member attribute > which I accidentally misspell somewhere and sometimes that results in > silent failure. Something doesn't work, but no exception is thrown. > Unit tests, and perhaps lint, are required to catch these errors. That > is one thing about a dynamic language: comprehensive testing is required > as you go along. > To be quite honest, comprehensive testing is needed in more static languages too. There are certain categories of error which can be detected by a compiler/linter, and certain which cannot; a language that forces you to declare variables will catch variable name misspellings, but only if they don't land you on an existing variable, and still won't catch the dynamic places like dict keys (imagine getting a block of JSON from somewhere, converting it into a dictionary, and looking up stuff in it - the compiler can't know whether your incoming data is correct and your code wrong, or the other way around). A language with less dynamism might be able to catch more, but still not everything, so ultimately, it all comes down to testing anyway. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-24 20:20 -0700 |
| Message-ID | <fc2ca7fc-9485-44c5-860b-0a3371c93ad5@googlegroups.com> |
| In reply to | #111852 |
On Monday, July 25, 2016 at 8:42:21 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jul 25, 2016 at 12:48 PM, Michael Torrie wrote: > > Far more often I'm bitten by the dynamic nature of Python (would happen > > in any dynamic language). I'll be using a particular member attribute > > which I accidentally misspell somewhere and sometimes that results in > > silent failure. Something doesn't work, but no exception is thrown. > > Unit tests, and perhaps lint, are required to catch these errors. That > > is one thing about a dynamic language: comprehensive testing is required > > as you go along. > > > > To be quite honest, comprehensive testing is needed in more static > languages too. There are certain categories of error which can be > detected by a compiler/linter, and certain which cannot; a language > that forces you to declare variables will catch variable name > misspellings, but only if they don't land you on an existing variable, > and still won't catch the dynamic places like dict keys (imagine > getting a block of JSON from somewhere, converting it into a > dictionary, and looking up stuff in it - the compiler can't know > whether your incoming data is correct and your code wrong, or the > other way around). A language with less dynamism might be able to > catch more, but still not everything, So far — Fine! > so ultimately, it all comes down to testing anyway. All?? There is a famous quote by Dijkstra: «Testing shows the presence, not the absence of bugs» Or if you prefer things of a more ‘practical’ (so-called_ nature: http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-25 13:28 +1000 |
| Message-ID | <mailman.108.1469417338.22221.python-list@python.org> |
| In reply to | #111853 |
On Mon, Jul 25, 2016 at 1:20 PM, Rustom Mody <rustompmody@gmail.com> wrote: >> so ultimately, it all comes down to testing anyway. > > All?? > > There is a famous quote by Dijkstra: > «Testing shows the presence, not the absence of bugs» > > Or if you prefer things of a more ‘practical’ (so-called_ nature: > http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/ If testing won't find the bugs, what will? By "testing", I don't just mean automated tests, although of course that's one of the most efficient ways. Dogfooding is an important part of testing too. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-24 20:46 -0700 |
| Message-ID | <2ce4424a-89d3-4d56-9cd7-7b3a79076150@googlegroups.com> |
| In reply to | #111854 |
On Monday, July 25, 2016 at 8:59:10 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jul 25, 2016 at 1:20 PM, Rustom Mody wrote: > >> so ultimately, it all comes down to testing anyway. > > > > All?? > > > > There is a famous quote by Dijkstra: > > «Testing shows the presence, not the absence of bugs» > > > > Or if you prefer things of a more ‘practical’ (so-called_ nature: > > http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/ > > If testing won't find the bugs, what will? By "testing", I don't just > mean automated tests, although of course that's one of the most > efficient ways. Dogfooding is an important part of testing too. Dijkstra made that (and such) statements towards advocating formal program proving. Whether we agree/disagree with that line is one thing. The bald fact that tests are finite and the actual search space for cases for anything remotely non-trivial is infinite is undeniable.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-07-25 17:20 +1000 |
| Message-ID | <5795bdb6$0$1526$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111855 |
On Monday 25 July 2016 13:46, Rustom Mody wrote: > The bald fact that tests are finite and the actual search space for cases for > anything remotely non-trivial is infinite is undeniable. I deny it :-P "Infinity" is pretty big. It's *really* big. It's bigger than most people think. You might think your credit card bill last month was big, but infinity is much bigger. Mathematicians deal with numbers which are so unfathomably huge that we can't even talk about them using the ordinary notation we use for ordinary numbers. Take something as unbelievably big as Graham's Number, so big they had to invent specialised notation just to discuss it: http://mathworld.wolfram.com/GrahamsNumber.html http://www.youtube.com/watch?v=XTeJ64KD5cg Let's make it bigger! Square it. No, cube it! Take the factorial! Cube it again! Raise that number to the power of itself! Add one! Compared to infinity, this new number is infinitesimally tiny. Compared to infinity, this new number is barely even there. Compared to infinity, that new number might as well be zero. Given that any actual program has to *exist* in order to be tested, it must be finite in size. Since the observable universe contains "merely" something of the order of 10**89 or so elementary particles (electrons, protons, etc) even with the combinatory explosion of possibilities, the upper bound on the number of test cases will be something like (10**89)**(10**89), which is minuscule compared to Graham's Number, let alone our even Vaster number. Which is so far short of infinity that in one sense we can say that it has barely even taken a single step in the direction of infinity. (Of course I realise you were using "infinite" just as hyperbole. I just couldn't resist bringing Graham's Number into the discussion.) -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-25 14:27 +1000 |
| Message-ID | <57959523$0$1586$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111853 |
On Mon, 25 Jul 2016 01:20 pm, Rustom Mody wrote: >> so ultimately, it all comes down to testing anyway. > > All?? Ultimately, yes. It all comes down to testing. How else do you know that your program to flernge the widget *actually* flernges the widget or not? > There is a famous quote by Dijkstra: > «Testing shows the presence, not the absence of bugs» Correct. And as Knuth said: "Beware of bugs in the above code; I have only proved it correct, not tried it." You cannot *prove* the absence of bugs in a large, complex program, because how do you know your proof is correct? Your automatic prover is a program, which will contain bugs. If you don't use an automatic prover, then how do you know you didn't make a mistake in your manual proof? Ultimately, any program beyond a certain level of complexity can only be *suspected* to be correct. > Or if you prefer things of a more ‘practical’ (so-called_ nature: > http://www.testingexcellence.com/reasons-automated-tests-fail-to-find-regression-bugs/ -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | neceros@gmail.com |
|---|---|
| Date | 2016-07-24 11:27 -0700 |
| Message-ID | <153dbc0e-2b2a-46f6-b05c-5ee98d31ba02@googlegroups.com> |
| In reply to | #111806 |
On Sunday, July 24, 2016 at 6:09:40 AM UTC-7, BartC wrote:
> 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
Don't use tabs. Ever. It's simple.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-24 22:17 +1000 |
| Message-ID | <5794b1d7$0$1620$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111800 |
On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
> I didn't want to get into this subject again, but Python's indentation
> scheme is fragile.
*shrug*
Okay, it's fragile. In 20 (give or take a couple) years of programming in
Python, do you know how many times this fragility has been an *actual*
problem? Why don't you take a guess?
> 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,
Not really. It depends on the editor, but typically you need to have your
text insertion point somewhere in the indent.
And when you do accidentally press Delete, what happens? The high-level
structure of the code changes. Typically things will no longer align:
def f():
for x in seq:
do_this()
do_that()
do_more()
which is a SyntaxError. It requires quite the coincidence before you can
accidentally delete an indent and have the code still run. Far more likely
is that accidentally pressing delete will break the code in a way that
can't be detected until runtime:
def f():
for x in seq:
do_this()
d_that()
do_more()
Conclusion: if you're the sort of person who habitually presses the Delete
or Backspace key without paying attention, you're going to have a bad time.
(Do other professions make arguments like this? Do carpenters, say, argue
against nail guns because "well if you accidentally hold a loaded nail gun
to your head, then press the trigger, bad things will happen"? Or is it
just programmers who make a common practice of arguing that the programming
language should protect the user from sheer carelessness?)
> but a
> program still compiles. And still runs without execution errors. But
> might now be subtly wrong.
That's certainly *theoretically* possible, but its really not likely. The
only way it could happen is:
- you have a block with at least two lines;
- your insertion point is in the indent of the last line of the block;
- but not the actual text part;
- your editor is configured to dedent on Delete/Backspace, not just
delete a single space; or you're using tabs to indent;
- and the block isn't followed by another block (e.g. if...else...)
> 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.
pi = 314159 # oops accidentally hit delete
[...]
> 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.
You know, I suspect that you've probably spent more time talking about the
effort required to delete and insert "pass" than the *actual* effort spent
by a hundred programmers deleting and inserting "pass" in their code.
> 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.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Joel Goldstick <joel.goldstick@gmail.com> |
|---|---|
| Date | 2016-07-24 08:28 -0400 |
| Message-ID | <mailman.88.1469363329.22221.python-list@python.org> |
| In reply to | #111803 |
On Sun, Jul 24, 2016 at 8:17 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
>
>> I didn't want to get into this subject again, but Python's indentation
>> scheme is fragile.
>
> *shrug*
>
> Okay, it's fragile. In 20 (give or take a couple) years of programming in
> Python, do you know how many times this fragility has been an *actual*
> problem? Why don't you take a guess?
>
>
>> 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,
>
> Not really. It depends on the editor, but typically you need to have your
> text insertion point somewhere in the indent.
>
> And when you do accidentally press Delete, what happens? The high-level
> structure of the code changes. Typically things will no longer align:
>
> def f():
> for x in seq:
> do_this()
> do_that()
> do_more()
>
> which is a SyntaxError. It requires quite the coincidence before you can
> accidentally delete an indent and have the code still run. Far more likely
> is that accidentally pressing delete will break the code in a way that
> can't be detected until runtime:
>
> def f():
> for x in seq:
> do_this()
> d_that()
> do_more()
>
> Conclusion: if you're the sort of person who habitually presses the Delete
> or Backspace key without paying attention, you're going to have a bad time.
>
> (Do other professions make arguments like this? Do carpenters, say, argue
> against nail guns because "well if you accidentally hold a loaded nail gun
> to your head, then press the trigger, bad things will happen"? Or is it
> just programmers who make a common practice of arguing that the programming
> language should protect the user from sheer carelessness?)
>
>
>> but a
>> program still compiles. And still runs without execution errors. But
>> might now be subtly wrong.
>
> That's certainly *theoretically* possible, but its really not likely. The
> only way it could happen is:
>
> - you have a block with at least two lines;
> - your insertion point is in the indent of the last line of the block;
> - but not the actual text part;
> - your editor is configured to dedent on Delete/Backspace, not just
> delete a single space; or you're using tabs to indent;
> - and the block isn't followed by another block (e.g. if...else...)
>
>
>
>> 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.
>
> pi = 314159 # oops accidentally hit delete
>
>
> [...]
>> 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.
>
> You know, I suspect that you've probably spent more time talking about the
> effort required to delete and insert "pass" than the *actual* effort spent
> by a hundred programmers deleting and inserting "pass" in their code.
>
>
>> 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.
>
>
>
>
> --
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
This thread is beginning to feel like a dog whistle for people who
like braces. I've been python coding since 2009 I think, and I think
I have used pass less than a handful of times. ... and except for sets
and dicts, I can't remember using a {
--
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-24 22:48 +1000 |
| Message-ID | <mailman.89.1469364508.22221.python-list@python.org> |
| In reply to | #111803 |
On Sun, Jul 24, 2016 at 10:17 PM, Steven D'Aprano <steve@pearwood.info> wrote: > (Do other professions make arguments like this? Do carpenters, say, argue > against nail guns because "well if you accidentally hold a loaded nail gun > to your head, then press the trigger, bad things will happen"? Or is it > just programmers who make a common practice of arguing that the programming > language should protect the user from sheer carelessness?) What about "if you accidentally drop a loaded nailgun, it will fire sharp bits of metal at high velocity in all directions"? I'd say the only difference is that carpentry has been around longer, so they had all these arguments a long time ago and settled on safe ways of doing things. Why has (most of) the programming world advanced from naive text editors to programming editors with syntax highlighting, linters, and other features? Because we are more efficient when our tools protect us from mistakes. Did people argue a few decades ago about the value of syntax highlighting? Personally, I took a long while to get from "well, it'd be nice, but I won't go to any serious effort for it" to "it's my normal way of coding, and anything that DOESN'T have it is for quick tweaks only". Also, why does CPython keep an eye on things like Coverity? If the core devs are competent, they should be able to write code that never dereferences null pointers, mismatch INCREF/DECREF, or any of those other errors - right? But life's better with protection. It's a trade-off. How much effort do you want to go to? Duplicate work in daily operation is a high price to pay, which is why Python doesn't demand "indentation AND 'end' keywords", but protection does have value. Maybe the people who are most worried about this can enact a simple rule: no dedent without a blank line? That can easily be verified by a script, and it'd protect against most of the given examples. It's not too much effort (after any reasonable-sized block you'll probably have a blank anyway, so it's only the tiniest of loops that would be affected). And no language changes are needed :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-24 23:38 +1000 |
| Message-ID | <mailman.91.1469367519.22221.python-list@python.org> |
| In reply to | #111803 |
On Sun, Jul 24, 2016 at 11:11 PM, Marco Sulla
<mail.python.org@marco.sulla.e4ward.com> wrote:
> On 24 July 2016 at 14:48, Chris Angelico <rosuav@gmail.com> wrote:
>> Maybe the people who are most worried about this can enact a
>> simple rule: no dedent without a blank line? That can easily be
>> verified by a script, and it'd protect against most of the given
>> examples. It's not too much effort (after any reasonable-sized block
>> you'll probably have a blank anyway, so it's only the tiniest of loops
>> that would be affected). And no language changes are needed :)
>
> I'm incredibly in favor of such a modification, but maybe this is work
> for a linter.
Sorry if I wasn't clear, but I definitely did mean for this to be the
work of a linter ("verified by a script", and "no language changes are
needed").
> Honestly, I find the "pass" statement very clear and simple. There's
> more misleading problems in Python syntax, like this:
>
> someFunction(
> "param1"
> "param2" # comma missed, there will be only one parameter "param1param2"
> )
That can also be caught by a linter; it can also be caught by a
standard habit of ALWAYS putting trailing commas on anything that gets
wrapped. It's not so common with function calls, but the equivalent
situation with list display is:
colors = [
"red",
"green"
"blue",
"yellow",
"cyan",
"magenta"
]
Same problem with the missed comma, but it's also common enough to put
one after "magenta" too, and it's a great protection. Again, you could
have your linter demand this, if you wanted to (and put the linter
into your pre-commit hook or equivalent), or you could just eyeball it
("nothing at the end of the line? really?").
> and this one too:
>
> class Parent(Base):
> __tablename__ = 'parent'
> id = Column(Integer, primary_key=True)
> children = relationship("Child"), # comma inserted by error.
> children will be a tuple and SQLAlchemy will fail with misleading
> errors
Hmm, that's a bit harder to pin down, but since *none* of the members
will have commas here, I'd be surprised to spot one there. Though part
of the problem here is that SQLAlchemy is such a gigantic package that
its error messages tend to be a bit confusing. But that said, here's
what happened when I tried it:
rosuav@sikorsky:~$ python3
Python 3.6.0a3+ (default:bff31254a0f0, Jul 17 2016, 17:39:49)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sqlalchemy.ext.declarative import declarative_base
>>> from sqlalchemy import Column, Integer
>>> from sqlalchemy.orm import relationship
>>> Base = declarative_base()
>>> class Parent(Base):
... __tablename__ = 'parent'
... id = Column(Integer, primary_key=True)
... children = relationship("Child"),
...
/usr/local/lib/python3.6/site-packages/sqlalchemy/ext/declarative/base.py:297:
SAWarning: Ignoring declarative-like tuple value of attribute
children: possibly a copy-and-paste error with a comma left at the end
of the line?
"left at the end of the line?" % k)
>>> Parent
<class '__main__.Parent'>
>>>
rosuav@sikorsky:~$ python3 -m pip freeze|grep -i alchemy
SQLAlchemy==1.0.11
Maybe enabling warnings is all you need, or maybe it depends on the
version of SQLAlchemy. In any case, nice spot, declarative-base!
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marco Sulla <mail.python.org@marco.sulla.e4ward.com> |
|---|---|
| Date | 2016-07-24 15:11 +0200 |
| Message-ID | <mailman.92.1469369555.22221.python-list@python.org> |
| In reply to | #111803 |
On 24 July 2016 at 14:48, Chris Angelico <rosuav@gmail.com> wrote:
> Maybe the people who are most worried about this can enact a
> simple rule: no dedent without a blank line? That can easily be
> verified by a script, and it'd protect against most of the given
> examples. It's not too much effort (after any reasonable-sized block
> you'll probably have a blank anyway, so it's only the tiniest of loops
> that would be affected). And no language changes are needed :)
I'm incredibly in favor of such a modification, but maybe this is work
for a linter.
Honestly, I find the "pass" statement very clear and simple. There's
more misleading problems in Python syntax, like this:
someFunction(
"param1"
"param2" # comma missed, there will be only one parameter "param1param2"
)
and this one too:
class Parent(Base):
__tablename__ = 'parent'
id = Column(Integer, primary_key=True)
children = relationship("Child"), # comma inserted by error.
children will be a tuple and SQLAlchemy will fail with misleading
errors
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 15:44 +0100 |
| Message-ID | <nn2k8m$hkf$1@dont-email.me> |
| In reply to | #111803 |
On 24/07/2016 13:17, Steven D'Aprano wrote:
> On Sun, 24 Jul 2016 08:35 pm, BartC wrote:
>> 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,
>
> Not really. It depends on the editor, but typically you need to have your
> text insertion point somewhere in the indent.
>
> And when you do accidentally press Delete, what happens? The high-level
> structure of the code changes. Typically things will no longer align:
>
> def f():
> for x in seq:
> do_this()
> do_that()
> do_more()
>
> which is a SyntaxError.
Unless it happened on the do_more() line.
> It requires quite the coincidence before you can
> accidentally delete an indent and have the code still run.
On my editor, if I press the cursor up and down keys, the current column
moves to the left if I pass a blank line and stays there. In Python
code, then the cursor will often end up at the start of an indent.
Far more likely
> is that accidentally pressing delete will break the code in a way that
> can't be detected until runtime:
>
> def f():
> for x in seq:
> do_this()
> d_that()
> do_more()
Yes, I mentioned that; it will cause some exception. But moving
do_more() out of the loop above might not do so.
>
> Conclusion: if you're the sort of person who habitually presses the Delete
> or Backspace key without paying attention, you're going to have a bad time.
It happens in all sorts of ways.
Your attention is diverted, you're doing something on your desk, but you
hit one of the keys by mistake. You might have pressed Delete or you
might not. You look at the screen which has a 5000-line program open,
and you see this (borrowing your example and with the cursor at "_"):
def f():
for x in seq:
do_this()
do_that()
_ do_more()
Did you just unindent do_more(), or is that where it's meant to be? Undo
may or may not help (or it may undo something is needed).
If you see this however:
def f():
for x in seq:
do_this()
_o_that()
do_more()
You can see that o_that() doesn't look like its neighbours, and you can
verify there's no o_that() in scope.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-25 00:51 +1000 |
| Message-ID | <mailman.93.1469371871.22221.python-list@python.org> |
| In reply to | #111812 |
On Mon, Jul 25, 2016 at 12:44 AM, BartC <bc@freeuk.com> wrote: > Your attention is diverted, you're doing something on your desk, but you hit > one of the keys by mistake. You might have pressed Delete or you might not. > You look at the screen which has a 5000-line program open, and you see this > (borrowing your example and with the cursor at "_"): > > def f(): > for x in seq: > do_this() > do_that() > _ do_more() > > Did you just unindent do_more(), or is that where it's meant to be? Undo may > or may not help (or it may undo something is needed). Undo, redo. See what happened. Easy. Also, if you're regularly committing to source control, you can always check the diff. Before you 'git commit', check what 'gitk' shows, or before 'hg commit', have a glance at 'hg diff'. Make sure what you're seeing is what you intend to change. Remember, code doesn't just accidentally change; everything should have purpose, including (especially) any indent/unindent. Source control protects you from everything other than multiple changes since the last commit. So commit often. It'll save you a lot of time - if not coding time, then debating-on-python-list time. :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 19:14 +0100 |
| Message-ID | <nn30hj$sgn$1@dont-email.me> |
| In reply to | #111814 |
On 24/07/2016 15:51, Chris Angelico wrote: > On Mon, Jul 25, 2016 at 12:44 AM, BartC <bc@freeuk.com> wrote: >> Your attention is diverted, you're doing something on your desk, but you hit >> one of the keys by mistake. You might have pressed Delete or you might not. >> You look at the screen which has a 5000-line program open, and you see this >> (borrowing your example and with the cursor at "_"): >> >> def f(): >> for x in seq: >> do_this() >> do_that() >> _ do_more() >> >> Did you just unindent do_more(), or is that where it's meant to be? Undo may >> or may not help (or it may undo something is needed). > > Undo, redo. See what happened. Easy. > > Also, if you're regularly committing to source control, you can always > check the diff. Before you 'git commit', check what 'gitk' shows, or > before 'hg commit', have a glance at 'hg diff'. Make sure what you're > seeing is what you intend to change. Remember, code doesn't just > accidentally change; everything should have purpose, including > (especially) any indent/unindent. > > Source control protects you from everything other than multiple > changes since the last commit. So commit often. It'll save you a lot > of time - if not coding time, then debating-on-python-list time. :) OK. I understand that it is not possible to point out any kind of weakness of a language (any language not just Python!) because the counter-argument is always going to be about: Use syntax highlighting, use a smart editor, use a version control system, use a linter, use 'tabnanny', use tool X, Y or Z to get around the problems, use obscure language options.. The thing is, if everyone does depend more on such tools, then it really doesn't matter exactly what the language does - the tools will take care of such details. So the language could delimit blocks using any scheme it likes, including use 'end', 'else' and so on. It only becomes important to people like me who use plain editors. -- Bartc -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Hayward <jonathan.hayward@pobox.com> |
|---|---|
| Date | 2016-07-24 13:34 -0500 |
| Message-ID | <mailman.94.1469385279.22221.python-list@python.org> |
| In reply to | #111816 |
I might point out something that captures something about pass: it is made to do extra duty in web2py, which is meant to shield students from some of the more preventable complexities of a LUM CLI, and you don't easily indent code the way that Vim and Emacs, let alone a full IDE besides the IDE nature of web2py, forces people to deal with. People getting up to speed with Vim or Emacs, for anything that is usually indented, find and/or seek out how to maintain indentation without hitting the space bar 4/8/12/... times at the beginning of the next line. And it works. It was probably not intended or even anticipated in the design of Python, but my understanding is that the adapted usage works well. And if I may put on asbestos longjohns, there is no reason I am aware of why syntactic sugar, in the style of Python-influenced Coffeescript, could not be modified to make "from __future__ import braces" represent a live and active feature. The net effect of significant whitespace in Python is that it provides one model to "say what you mean and mean what you say", and everybody who understands the language recognizes the beginning and end of a block, the end of a statement, a noop, etc. And this is pretty much the job description of C-family language syntax etc. Now there are advantages, namely no braces and no brace holy wars either, fewer Perlish sigils as even a statement is usually ended by line break, and so on. But Python-style and C-style syntax alike provide an unambiguous tool to specify what you want, and an unambiguous means of interpreting what was actually said. The non-C-style syntax was the biggest "steaming pile of dinosaur dung" hurdle before ESR appreciated the language, but Python syntax and C-style syntax are both adequate. They may or may not be equal, but every instance of code which unambiguous Pythonic syntax is underscored is an effect that should usually be equally easy to implement with C-style syntax. On Sun, Jul 24, 2016 at 1:14 PM, BartC <bc@freeuk.com> wrote: > On 24/07/2016 15:51, Chris Angelico wrote: > >> On Mon, Jul 25, 2016 at 12:44 AM, BartC <bc@freeuk.com> wrote: >> >>> Your attention is diverted, you're doing something on your desk, but you >>> hit >>> one of the keys by mistake. You might have pressed Delete or you might >>> not. >>> You look at the screen which has a 5000-line program open, and you see >>> this >>> (borrowing your example and with the cursor at "_"): >>> >>> def f(): >>> for x in seq: >>> do_this() >>> do_that() >>> _ do_more() >>> >>> Did you just unindent do_more(), or is that where it's meant to be? Undo >>> may >>> or may not help (or it may undo something is needed). >>> >> >> Undo, redo. See what happened. Easy. >> >> Also, if you're regularly committing to source control, you can always >> check the diff. Before you 'git commit', check what 'gitk' shows, or >> before 'hg commit', have a glance at 'hg diff'. Make sure what you're >> seeing is what you intend to change. Remember, code doesn't just >> accidentally change; everything should have purpose, including >> (especially) any indent/unindent. >> >> Source control protects you from everything other than multiple >> changes since the last commit. So commit often. It'll save you a lot >> of time - if not coding time, then debating-on-python-list time. :) >> > > OK. I understand that it is not possible to point out any kind of weakness > of a language (any language not just Python!) because the counter-argument > is always going to be about: > > Use syntax highlighting, use a smart editor, use a version control system, > use a linter, use 'tabnanny', use tool X, Y or Z to get around the > problems, use obscure language options.. > > The thing is, if everyone does depend more on such tools, then it really > doesn't matter exactly what the language does - the tools will take care of > such details. So the language could delimit blocks using any scheme it > likes, including use 'end', 'else' and so on. > > It only becomes important to people like me who use plain editors. > > -- > Bartc > > > -- > Bartc > -- > https://mail.python.org/mailman/listinfo/python-list > -- [image: Christos Jonathan Seth Hayward] <https://cjshayward.com/> *Jonathan Hayward*, a User Experience professional. Email <cjsh@cjshayward.com> • Flagship <https://cjshayward.com/>Website <https://cjshayward.com/> • Github <https://github.com/jonathanhayward> • *LinkedIn <http://www.linkedin.com/in/jonathanhayward>* • Portfolio + More <http://jonathanhayward.com/> • *Recent Title <https://www.packtpub.com/application-development/reactive-programming-javascript>* • Skills <http://jsh.name/> Loads of talent and a thorough grounding in all major academic disciplines supporting User Experience.
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web