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 | 18 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 13 of 13 — ← Prev page 1 … 11 12 [13]
| From | alister <alister.ware@ntlworld.com> |
|---|---|
| Date | 2016-07-24 18:52 +0000 |
| Message-ID | <p78lz.885019$CF.748673@fx41.am4> |
| In reply to | #111816 |
On Sun, 24 Jul 2016 19:14:10 +0100, BartC 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 whichever language you use regardless of editor, there will have been design decisions made that could (by your logic) be considered flaws because an error made is not picked up by the compiler. apple were recently bitten by "Goto Fail" an error that could not have happened in the same way with pythons indentation rules. correct the design of your compiler for one type of error & you will find that you are now open to another. IMHO typing pass to signify a deliberately empty block is a minor nuisance (at worst) making it optional is more likely to lead to bugs either way my opinion is nut important because the decision has already been made. -- I sat laughing snidely into my notebook until they showed me a PC running Linux... And oh! It was as though the heavens opened and God handed down a client-side OS so beautiful, so graceful, and so elegant that a million Microsoft developers couldn't have invented it even if they had a hundred years and a thousand crates of Jolt cola. -- Polly Sprenger, LAN Times
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-25 05:00 +1000 |
| Message-ID | <mailman.96.1469386837.22221.python-list@python.org> |
| In reply to | #111816 |
On Mon, Jul 25, 2016 at 4:14 AM, BartC <bc@freeuk.com> wrote:
> 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..
Obscure? I guess - it's not like it's listed in the --help screen. Oh
wait. And of course, all you need to do is upgrade to Python 3 and it
becomes the default.
Wait, you lump "use a VCS" into the category of "stuff people tell you
that you're not really willing to do"? Are you saying you don't use
git, Mercurial, etc, etc, to track your projects? Then start using
one. Now. "Now-now", as Princess Anna says in the Italian dub.
> 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.
Yes, that's exactly right. Tell me, is this part of a linter or a
language compiler/interpreter?
rosuav@sikorsky:~$ cat 1.c
#include <stdio.h>
int main()
{
int months[12] = {31,28,31,30,31,30,31,31,30,31,30,31};
printf("The array is at %p.\n", months);
printf("There are %d days in December.\n", months[12]);
printf("And this is what 28 looks like: %s\n", months[1]);
}
rosuav@sikorsky:~$ gcc -Wall -O2 1.c
1.c: In function ‘main’:
1.c:7:9: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
printf("And this is what 28 looks like: %s\n", months[1]);
^
1.c:6:2: warning: array subscript is above array bounds [-Warray-bounds]
printf("There are %d days in December.\n", months[12]);
^
rosuav@sikorsky:~$
Today's C compilers emit warnings for things that yesterday's
third-party linters did. Is there virtue in running gcc with all
warnings disabled? Equally, is there a valid reason for choosing to
use a "plain editor" when you could use one that helps you?
A skilled craftsman in any field will choose to use quality tools.
They save time, and time is money. Are there any carpenters who
restrict themselves to hand tools? (Stylistic choice aside.
KirkwoodWorking has "hand tools Sunday" where he avoids all power
tools, and it's taking him months and months to finish one cabinet.
But the rest of the week, power tools win.) Would you, if given the
choice, use an ancient 80386 running MS-DOS in 4MB of RAM, or a modern
system running a modern OS in 16GB? Would you type your code on a
tablet computer or something with a real keyboard? So why do you use
"dumb editor" as a line of argument, rather than getting a smarter
editor?
I don't have a lot of sympathy for people who use suboptimal tools and
expect everything to work for them. Sure, sometimes you're forced to
use something less than ideal (maybe you're stuck on someone else's
Windows box and good tools simply aren't there, and you can't go
installing a ton of stuff just to get started), but then you KNOW
you're working in bad conditions. You don't make that your normal
life.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 21:03 +0100 |
| Message-ID | <nn36uo$k0r$1@dont-email.me> |
| In reply to | #111821 |
On 24/07/2016 20:00, Chris Angelico wrote: > On Mon, Jul 25, 2016 at 4:14 AM, BartC <bc@freeuk.com> wrote: > A skilled craftsman in any field will choose to use quality tools. Materials (ie. languages) are important too. > So why do you use > "dumb editor" as a line of argument, rather than getting a smarter > editor? Perhaps because I prefer to use my own languages and I don't have anyone writing the specialist tools for me that would be necessary. > I don't have a lot of sympathy for people who use suboptimal tools and > expect everything to work for them. Sure, sometimes you're forced to > use something less than ideal (maybe you're stuck on someone else's > Windows box and good tools simply aren't there, and you can't go > installing a ton of stuff just to get started), but then you KNOW > you're working in bad conditions. You don't make that your normal > life. Some of us are used to working with minimalist tools and can be extremely productive with them. But since you used some C, let me give an example of poor design from that language (there are plenty; I've written up quite a big collection of them). You might know that type declarations in C, as soon as you go beyond the basics, become completely impossible and convoluted. I've never managed to get my head around them. There are utilities such as 'Cdecl' that are used to convert a C declaration to English, and vice versa. That's how good a feature they are! So what would have been a better solution here: to have fixed the language, or to have grafted on a simpler type declaration scheme that could co-exist with the old one; or to have ignored the problem and depended on using external tools? Or just insisted that everyone learns that arcane aspect of C, despite it being unreadable and error-prone. (My own solution is that I use a home-made language in place of C, which has fixed most such problems. So my main 'tool' is a custom-made language. And for block delimiting, it uses neither tabbed indents or braces!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-25 07:08 +1000 |
| Message-ID | <mailman.100.1469394529.22221.python-list@python.org> |
| In reply to | #111834 |
On Mon, Jul 25, 2016 at 6:03 AM, BartC <bc@freeuk.com> wrote: > On 24/07/2016 20:00, Chris Angelico wrote: >> >> On Mon, Jul 25, 2016 at 4:14 AM, BartC <bc@freeuk.com> wrote: > > >> A skilled craftsman in any field will choose to use quality tools. > > Materials (ie. languages) are important too. Materials, tools, same difference. (Not sure I could even draw the line in software, and ultimately, my line of argument applies equally to both.) >> So why do you use >> "dumb editor" as a line of argument, rather than getting a smarter >> editor? > > > Perhaps because I prefer to use my own languages and I don't have anyone > writing the specialist tools for me that would be necessary. So because you've chosen to use your own languages, you are frustrated at Python because you're not using a decent editor? Get yourself something nice and configurable, so that when you open a Python file it gives you the features you need. I use SciTE, and it quite happily is currently working with text, Pike, Pike Module, reStructuredText, HTML, SRT, and Python files, and that's counting only the ones that I have loaded in it right at this instant. Had some C files up recently (both .c and .h - was editing CPython), and various other things. SciTE doesn't recognize .srt files, so it treats them as plain text - as in, like a dumb editor would. Even if your own language can't be parsed using any existing parser (adding language support usually isn't that hard, if the same parser can be reused), you can still make use of smart editor features for all other languages you work with. Why is this such a problem? Why is it so hard? >> I don't have a lot of sympathy for people who use suboptimal tools and >> expect everything to work for them. Sure, sometimes you're forced to >> use something less than ideal (maybe you're stuck on someone else's >> Windows box and good tools simply aren't there, and you can't go >> installing a ton of stuff just to get started), but then you KNOW >> you're working in bad conditions. You don't make that your normal >> life. > > Some of us are used to working with minimalist tools and can be extremely > productive with them. And then you complain that the language is "fragile" or in some way frustrating to you. Because you've restricted yourself to minimalist tools. Go ahead! Be productive. I'm sure there are people out there saying "I'm used to working with C and can be extremely productive with it". Let 'em. Me, I'll use high level languages and be even more productive. Thanks. > But since you used some C, let me give an example of poor design from that > language (there are plenty; I've written up quite a big collection of them). > > You might know that type declarations in C, as soon as you go beyond the > basics, become completely impossible and convoluted. I've never managed to > get my head around them. > > There are utilities such as 'Cdecl' that are used to convert a C declaration > to English, and vice versa. That's how good a feature they are! > > So what would have been a better solution here: to have fixed the language, > or to have grafted on a simpler type declaration scheme that could co-exist > with the old one; or to have ignored the problem and depended on using > external tools? > > Or just insisted that everyone learns that arcane aspect of C, despite it > being unreadable and error-prone. When do you get those uber-convoluted declarations in C? Sure, they come up in C++ (which is why the language grew some features to manage that complexity), but outside of demonstration code, when do you get actual declarations of massively-nested constructs? I've literally *never* seen them - not rarely, NEVER - in production code. > (My own solution is that I use a home-made language in place of C, which has > fixed most such problems. So my main 'tool' is a custom-made language. > > And for block delimiting, it uses neither tabbed indents or braces!) Sure. You're most welcome to use that. But it doesn't mean that Python is unusable. Plus, I'd much rather trust Python in production than something custom-made, even by me. The performance, reliability, and security of a well-respected language far outstrip anything I could build. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-24 23:13 +0100 |
| Message-ID | <nn3eib$fv2$1@dont-email.me> |
| In reply to | #111838 |
On 24/07/2016 22:08, Chris Angelico wrote: > On Mon, Jul 25, 2016 at 6:03 AM, BartC <bc@freeuk.com> wrote: >> Perhaps because I prefer to use my own languages and I don't have anyone >> writing the specialist tools for me that would be necessary. > > So because you've chosen to use your own languages, you are frustrated > at Python because you're not using a decent editor? My point is that with a bit more thought into the design of a language, clever tools would be less important. A language should stand by itself and not lean on specialist tools to be make it more usable. A solid end-of-block symbol (as you get with 'else' and 'except' because then you KNOW that's the end of that block) would have been welcome with the Python indent scheme. > Get yourself > something nice and configurable, so that when you open a Python file > it gives you the features you need. I use SciTE, I have one big problem with most editors (including SciTE): they are not properly line-oriented. If you hold down Backspace in the middle of a line, it won't just delete until it hits the beginning of the line; it keeps going! I can't live with that: editing would be like walking on eggshells. I need hard line stops. (I can't touch type; I need to look at the keyboard a lot.) (And SciTE won't support a custom language for highlighting and stuff. Maybe it's configurable, but there seems to be a lexer module that needs to be provided. Suddenly it seems a lot of work to do.) > Why is this such a problem? Why is it so hard? Who says it's a problem? I'm quite happy with the screen editors I use that are little changed since the early 80s (and before that I used line editors; now those /were/ horrible). >> You might know that type declarations in C, as soon as you go beyond the >> basics, become completely impossible and convoluted. > When do you get those uber-convoluted declarations in C? (They don't need to be elaborate to start being confusing. Take 'int *a[]' and 'int (*a)[]'; one of these is an array of pointers, the other a pointer to an array. Quite different! But which is which? And when you start dealing with pointers to functions, now you're talking! And yes C++ takes this to a whole new dimension. What a language...) >> And for block delimiting, it uses neither tabbed indents or braces!) > > Sure. You're most welcome to use that. But it doesn't mean that Python > is unusable. It's not unusable. Just a minor nuisance (working with Python using my editor). And troublesome pasting Python code from elsewhere which is always full of spaces rather than tabs. (Sometimes uneven mixes of spaces too.) The Python indent thing isn't a big deal. But having 'end' after each (final) block would have made life just a bit simpler. The whole topic is a trivial point of syntax. (My only issue with 'pass' is that, for some inexplicable reason, my fingers always type it is '#pass'.) > Plus, I'd much rather trust Python in production than something > custom-made, even by me. The performance, reliability, and security of > a well-respected language far outstrip anything I could build. Well, performance is where I usually have an edge at the minute (with my own interpreted language). But if I had to recommend a language, it would have to be Python (I can't be dealing with users and support and all that...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-25 13:04 +1200 |
| Message-ID | <dvl6tdFaum3U1@mid.individual.net> |
| In reply to | #111840 |
BartC wrote: > (They don't need to be elaborate to start being confusing. Take 'int > *a[]' and 'int (*a)[]'; one of these is an array of pointers, the other > a pointer to an array. Quite different! But which is which? Where have you seen 'int (*a)[]' used? I don't think I've ever seen any real-life C code that used a pointer to an array, as opposed to a pointer to the first element of the array. Usually it would just be declared either 'int a[]' or 'int *a'. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 10:44 +0100 |
| Message-ID | <nn4n2l$gdo$1@dont-email.me> |
| In reply to | #111846 |
On 25/07/2016 02:04, Gregory Ewing wrote: > BartC wrote: >> (They don't need to be elaborate to start being confusing. Take 'int >> *a[]' and 'int (*a)[]'; one of these is an array of pointers, the >> other a pointer to an array. Quite different! But which is which? > > Where have you seen 'int (*a)[]' used? I don't think I've > ever seen any real-life C code that used a pointer to an > array, as opposed to a pointer to the first element of the > array. (Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to array of T), because, thanks to how C mixes up deferencing and indexing, the former can be accessed as a[i] instead of (*a)[i]. But it's wrong, and leads to errors that the language can't detect. Such as when a points to a single element not a block: define ANY combination such as 'pointer to pointer to array'; you need to access an element using (deref, deref, index), but C also allows (index, deref, deref) or (deref, index, deref), or (index, index, index). Provided the right number of deref/index ops are provided, C can't tell the difference because derefs and index ops are interchangeable! But only one combination is correct. I came across T(*a)[] when translating from a language that handles this properly, into C. In fact I use the translator to convert type-specs from straightforward format into C. Another tool to get around a flaw.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-26 19:21 +1200 |
| Message-ID | <dvohbaF4t41U1@mid.individual.net> |
| In reply to | #111860 |
BartC wrote: > (Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to > array of T), because, thanks to how C mixes up deferencing and indexing, > the former can be accessed as a[i] instead of (*a)[i]. > > But it's wrong, and leads to errors that the language can't detect. Such > as when a points to a single element not a block: This is an implementation issue, not a language issue. A sufficiently pedantic implementation could and would detect this kind of error at run time. Most implementations of C are not that pedantic, but you can't blame the language for that. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-26 10:56 +0300 |
| Message-ID | <87h9bcltnl.fsf@elektro.pacujo.net> |
| In reply to | #111881 |
Gregory Ewing <greg.ewing@canterbury.ac.nz>: > BartC wrote: >> (Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to >> array of T), because, thanks to how C mixes up deferencing and >> indexing, the former can be accessed as a[i] instead of (*a)[i]. >> >> But it's wrong, and leads to errors that the language can't detect. >> Such as when a points to a single element not a block: > > This is an implementation issue, not a language issue. A sufficiently > pedantic implementation could and would detect this kind of error at > run time. Most implementations of C are not that pedantic, but you > can't blame the language for that. Well, one of the novelties in C was the intentional blurring of the lines between arrays and sequences of elements in memory. The notation: int a[3]; declares a as an array. However, the expression: a does not produce an array; instead, it produces a pointer to the first element of the array. Even: *&a produces a pointer to the array's first element. Marko
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-26 20:35 +1200 |
| Message-ID | <dvoln7F6060U1@mid.individual.net> |
| In reply to | #111883 |
Marko Rauhamaa wrote: > int a[3]; > > a > > produces a pointer to the array's first element. Yes, and that makes using true pointer-to-array types in C really awkward. You're fighting against the way the language was designed to be used. If you use a language in an un-idiomatic way, you can't really complain when you have difficulties as a result. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-26 11:11 +0100 |
| Message-ID | <nn7d0b$ues$1@dont-email.me> |
| In reply to | #111881 |
On 26/07/2016 08:21, Gregory Ewing wrote: > BartC wrote: >> (Yes everyone uses T*a (pointer to T) instead of T(*a)[] (pointer to >> array of T), because, thanks to how C mixes up deferencing and >> indexing, the former can be accessed as a[i] instead of (*a)[i]. >> >> But it's wrong, and leads to errors that the language can't detect. >> Such as when a points to a single element not a block: > > This is an implementation issue, not a language issue. > A sufficiently pedantic implementation could and would > detect this kind of error at run time. Most implementations > of C are not that pedantic, but you can't blame the > language for that. (No, it's a language issue. Yes you might be able to have a sufficiently complex (and slow) implementation that at best could detect errors at runtime, but that's not much help. It boils down to this: if you have a pointer type T*, does it point to a standalone T object, or to an array or block of T objects? The language allows a pointer P of type T* pointing to a single T object to be accessed as P[i]. Apparently this is not seen as a problem... (More observations about C here: https://github.com/bartg/langs/blob/master/C%20Problems.md)) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-25 12:37 +1000 |
| Message-ID | <57957b65$0$1584$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #111840 |
On Mon, 25 Jul 2016 08:13 am, BartC wrote: > A solid end-of-block symbol (as you get with 'else' and 'except' because > then you KNOW that's the end of that block) would have been welcome with > the Python indent scheme. A solid end-of-block symbol would have been entire redundant and unnecessary. You know when the block ends: it ends when one of two things happen: - you dedent out a level; - you reach the end of file; whichever happens next. Requiring an otherwise pointless end of block delimiter to protect against your cat walking over your keyboard, or clumsy programmers who accidentally hit keys and don't notice, is not a virtue. It doesn't make the language better. It just increases friction when writing code. There are approximately a million billion trillion zillion things that can go wrong if you randomly hit keys without paying attention to what you are doing, and regardless of whether you have a static or dynamic language, only a tiny fraction of them can be detected ahead of time. When you're typing plain English paragraphs like this, why don't you end each sentence with "END", just in case you accidentally delete the punctuation mark and don't notice? END That way, you have less fragile text. END The reader can easily tell when you have the end of a sentence, even if you accidentally delete the full stop, because of the special end marker. END And two end markers could represent the end of a paragraph, just in case you accidentally delete the break between paragraphs? END END Actually, COMMA now that I think about it, COMMA I'm starting to come around to your way of thinking. END We can tag other punctuation marks too, COMMA like commas, COMMA to ensure that our language is less fragile. END No more will you have to fear the ambiguity of accidentally dropping a comma: COLON END END "We invited the strippers, JFK, and Stalin." "We invited the strippers, JFK and Stalin." http://i.imgur.com/fycHx.jpg Instead, COMNA the error becomes obvious: COLON EMD END " QUOTE We invited the strippers, COMMA JFK COMMA and Stalin. END " QUOTE END END -- DASH DASH SPACE END END Steven END END “ QUOTE Cheer up, COMMA ” END they said, COMMA “ QUOTE things could be worse. END ” QUOTE So I cheered up, COMMA and sure enough, COMMA things got worse. END END
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 11:39 +0100 |
| Message-ID | <nn4q8p$qho$1@dont-email.me> |
| In reply to | #111849 |
On 25/07/2016 03:37, Steven D'Aprano wrote:
> On Mon, 25 Jul 2016 08:13 am, BartC wrote:
>
>> A solid end-of-block symbol (as you get with 'else' and 'except' because
>> then you KNOW that's the end of that block) would have been welcome with
>> the Python indent scheme.
>
> A solid end-of-block symbol would have been entire redundant and
> unnecessary. You know when the block ends: it ends when one of two things
> happen:
>
> - you dedent out a level;
> - you reach the end of file;
> whichever happens next. Requiring an otherwise pointless end of block
> delimiter to protect against your cat walking over your keyboard, or clumsy
> programmers who accidentally hit keys and don't notice, is not a virtue. It
> doesn't make the language better. It just increases friction when writing
> code.
Remember when movies used to finish with "The End"? I wonder what that
was all about? After all you can tell when it's finished when you see
the opening titles of the next movie! Or when the lights come back up in
the cinema ('theater').
If you've ever watched Monty Python (on topic!) and the Holy Grail at
the cinema, you will have appreciated it even more. You just get a black
screen and nothing more happens. People were waiting for several
minutes, eventually starting to get up and leave.
END may seem redundant, but it's just very handy. You know FOR SURE you
are at a particular point, instead of having to infer it from what may
or may not come next, which might not be visible off the bottom of the
screen.
> When you're typing plain English paragraphs like this, why don't you end
> each sentence with "END"
The period is more the equivalent of C's semicolon. That nearly always
coincides with end-or-line so also lends itself to be inferred, as
horizontally source code tends to be a limited width.
But otherwise free-flowing English text is not a good comparison with a
programming language syntax.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-26 19:23 +1200 |
| Message-ID | <dvohgaF4t41U2@mid.individual.net> |
| In reply to | #111861 |
BartC wrote: > But otherwise free-flowing English text is not a good comparison with a > programming language syntax. I think Python is more like poetry. -- roses are red violets are blue is this the end of the poem no-one can tell because there is no end marker thus spake the bdfl
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-25 10:36 -0400 |
| Message-ID | <mailman.111.1469457804.22221.python-list@python.org> |
| In reply to | #111840 |
On Sun, Jul 24, 2016, at 18:13, BartC wrote: > (They don't need to be elaborate to start being confusing. Take 'int > *a[]' and 'int (*a)[]'; one of these is an array of pointers, the other > a pointer to an array. Quite different! But which is which? int (*a)[]; === int x[]; where x is (*a). To work out the other one you need to know operator precedence, but you need to know operator precedence to understand a _lot_ of things. C type _casts_ are slightly harder, since you have to work out where the identifier belongs in a token sequence that has had it removed. But it's usually not hard [look for the sequence "*)", which is otherwise illegal and appears in most complicated type casts].
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-25 18:33 +0100 |
| Message-ID | <nn5ii8$ga2$1@dont-email.me> |
| In reply to | #111864 |
On 25/07/2016 15:36, Random832 wrote: > On Sun, Jul 24, 2016, at 18:13, BartC wrote: [About C type specs] I've replied briefly here as this is off-topic now: http://pastebin.com/ZfcHqpXK -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-24 17:56 -0700 |
| Message-ID | <c6570a1d-cf89-4d4c-b0e0-b9698563e379@googlegroups.com> |
| In reply to | #111834 |
On Monday, July 25, 2016 at 1:33:48 AM UTC+5:30, BartC wrote: > On 24/07/2016 20:00, Chris Angelico wrote: > > On Mon, Jul 25, 2016 at 4:14 AM, BartC wrote: > > > A skilled craftsman in any field will choose to use quality tools. > > Materials (ie. languages) are important too. > > > So why do you use > > "dumb editor" as a line of argument, rather than getting a smarter > > editor? > > Perhaps because I prefer to use my own languages and I don't have anyone > writing the specialist tools for me that would be necessary. This language-vs-IDE divide has been recogized: http://blog.osteele.com/posts/2004/11/ides/
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-26 16:31 +0200 |
| Message-ID | <mailman.128.1469543604.22221.python-list@python.org> |
| In reply to | #111816 |
Op 24-07-16 om 21:00 schreef Chris Angelico: > A skilled craftsman in any field will choose to use quality tools. > They save time, and time is money.[/quote] Sure, but sometimes there is a flaw somewhere. A flaw whose consequences can be reduced by using an extra tool. If that is the case the real solution seems to get rid of the flaw and not to use the tool. So if someone argues there is a flaw somewhere, pointing to tools doesn't contradict that. -- Antoon.
[toc] | [prev] | [standalone]
Page 13 of 13 — ← Prev page 1 … 11 12 [13]
Back to top | Article view | comp.lang.python
csiph-web