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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-04 19:39 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.160.1470303553.6033.python-list@python.org> |
| In reply to | #112320 |
On Thu, Aug 4, 2016 at 7:13 PM, BartC <bc@freeuk.com> wrote:
> On 04/08/2016 04:23, Steven D'Aprano wrote:
>>
>> On Wed, 3 Aug 2016 08:16 pm, BartC wrote:
>
>
>>> So the idea that remembering 'repeat N' is a cognitive burden, and the
>>> myriad string operations for example are not, is ridiculous.
>>
>>
>> Who says it isn't a cognitive burden? Of course it is.
>>
>> The difference is that most of the string methods carry their own weight
>> in
>> usefulness versus burden, and "repeat N" doesn't (according to the core
>> developers). You have weighed "repeat N" high on the usefulness side and
>
>
> OK, let's look at some string features.
Be careful: you're looking at two different things here (the 'string'
module, and methods/attributes on the 'str' type).
> First, you have string.ascii_uppercase, which is just
> "ABCDEFGHIJKLMNOPQRSTUVWXYZ".
>
> Is that really so indispensable that it has to be built-in to the language?
> Is it that much of a hardship to assign it once and for all to some
> variable?
Once and for all? You mean like in a module?
> Now you have string str.lower, str.upper, and str.swapcase. Clearly one of
> those first two is redundant, as you can implement str.upper by writing
> str.lower().swapcase() for example.
"Clearly" only if you're thinking ASCII. You can't actually fudge this
either direction:
>>> s = "\u1e9e"
>>> s.lower().swapcase(), s.upper()
('SS', 'ẞ')
>>> s = "\u00df"
>>> s.upper().swapcase(), s.lower()
('ss', 'ß')
> Then these miss a trick by not having an optional length parameter, so that
> you can operate on the first N characters.
>
> Then you can dispense with str.capitalise by writing str.upper(1). (Or
> str.lower().upper(1) if the current case is unknown.)
You have to use the longer form for true equivalence, and then you run
into the same problem as above.
> (And what about str.reverse()? (The comments here about the readability of
> Python code, and who is entitled to express an opinion about it, are
> amusing:
> http://stackoverflow.com/questions/931092/reverse-a-string-in-python))
Slice it backwards. No need for a method, any more than there is need
of a str.charAt() method to get individual characters.
> Compare all that (and I'm sure there's tons more) with, for example, just
> leaving out the 'i in' in 'for range(N):')
If you want to push for a shorter syntax for simple repeat loops, this
has far better chances of landing than "repeat N" has - "for
<iterable>" is simply an extension of "for <var> in <iterable>" that
discards rather than binding. No new keywords introduced, no
fundamentally new looping structure, just the exact same thing as an
existing 'for' loop. The difference between "for thing in collection"
and "for collection" would then be:
# for thing in collection
_it = iter(collection)
while "moar stuff":
try: thing = next(_it)
except StopIteration: break
# loop body goes here
# for collection
_it = iter(collection)
while "moar stuff":
try: next(_it)
except StopIteration: break
# loop body goes here
That wouldn't be a bad thing, IMO. Whether it's worth the various
costs I still don't know, but its costs would be *way* lower than
adding a new keyword to the language, adding a new control flow form,
etc. Less magic. Just the removal of a name binding.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-08-04 19:38 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <57a30d18$0$1505$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112320 |
On Thursday 04 August 2016 19:13, BartC wrote: > On 04/08/2016 04:23, Steven D'Aprano wrote: >> On Wed, 3 Aug 2016 08:16 pm, BartC wrote: > >>> So the idea that remembering 'repeat N' is a cognitive burden, and the >>> myriad string operations for example are not, is ridiculous. >> >> Who says it isn't a cognitive burden? Of course it is. >> >> The difference is that most of the string methods carry their own weight in >> usefulness versus burden, and "repeat N" doesn't (according to the core >> developers). You have weighed "repeat N" high on the usefulness side and > > OK, let's look at some string features. > > First, you have string.ascii_uppercase, which is just > "ABCDEFGHIJKLMNOPQRSTUVWXYZ". > > Is that really so indispensable that it has to be built-in to the > language? Is it that much of a hardship to assign it once and for all to > some variable? /facepalm It *is* assigned once and for all to some variable. It's a variable in the "string" module. It is neither a built-in value (like None, True or False) nor a language feature. > And 'string.ascii_uppercase' is not that much more concise than just > writing out the alphabet! In the case of "0123456789", the constant name > is longer. The reason for giving constant values a fixed name is not to save keystrokes, but to have a consistent, readily understandable, self-descriptive name. If you say: from string import digits that's only 26 keystrokes, including a newline. Compared to: digits = '1234567890' which is 22 keystrokes. So it costs you four keystrokes over defining it yourself. Big deal. > Now you have string str.lower, str.upper, and str.swapcase. Clearly one > of those first two is redundant, as you can implement str.upper by > writing str.lower().swapcase() for example. I've already suggested that swapcase() is not very useful, and that it still exists only for backwards compatibility. But are you serious about suggesting that Python should drop str.upper() in favour of having the user write str.lower().swapcase()? At least put a wink or a smiley there, so we know you aren't a total idiot. > Then these miss a trick by not having an optional length parameter, so > that you can operate on the first N characters. That's actually a nice feature. I might request it. It's too late for Python 3.6, but maybe 3.7. It would have to take a start and end position, but that's actually quite clever. > Then you can dispense with str.capitalise by writing str.upper(1). (Or > str.lower().upper(1) if the current case is unknown.) Backwards compatibility would require it stays even if it became redundant. > (And what about str.reverse()? What about it? The canonical way to spell "reverse a string" is with a slice: mystring[::-1] > (The comments here about the readability > of Python code, and who is entitled to express an opinion about it, are > amusing: > http://stackoverflow.com/questions/931092/reverse-a-string-in-python)) Ah, well, Stackoverflow. What did you expect? -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-08-04 14:37 -0400 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.169.1470335883.6033.python-list@python.org> |
| In reply to | #112320 |
Making repeat a keyword would have such an extremely high cost
that it is out of the question and not a sane proposal.
To start with, it is used in two major, widely used APIs.
itertools.repeat + 50 uses in other itertools and tests
+ all the imports and and uses of repeat()
in code all over the world.
timeit command line option
timeit.timeit(..., repeat=3) parameter name
timeit.repeat() function + tests
+ all the scripts (some in other languages) using 'repeat'
as a command line option and all the python code using
the parameter or function.
There are other C-coded public APIs that use repeat. One in xml.etree
was revealed by the grep hit for the Python-coded test.
Other places in the *Python-coded* stdlib that would break.
distutils\fancy_getopt.py: 141: self.repeat = {}
lib2to3\fixes\fix_operator.py: 8: operator.repeat(obj, n) ...
lib2to3\patcomp.py: 105: repeat = None
lib2to3\patcomp.py: 139: def compile_basic(self, nodes, repeat=None):
lib2to3\tests\test_fixers.py: 4494: b = "operator.repeat(x, n)"
test\test_faulthandler.py: 533: repeat = {repeat}
test\test_faulthandler.py: 539: def func(timeout, repeat, ...
test\test_xml_etree.py: 1784: for dumper, loader in
product(self.modules, repeat=2):
typing.py: 373: def repeat(x: T, n: int) -> Sequence[T]:
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-05 04:54 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.172.1470336860.6033.python-list@python.org> |
| In reply to | #112320 |
On Fri, Aug 5, 2016 at 4:37 AM, Terry Reedy <tjreedy@udel.edu> wrote: > Making repeat a keyword would have such an extremely high cost > that it is out of the question and not a sane proposal. > To start with, it is used in two major, widely used APIs. > > itertools.repeat + 50 uses in other itertools and tests > timeit.repeat() function + tests Ooh, time to break out the thesaurus! rerun, rehash, reiterate [1], replicate, reproduce, recount, reprise, retread, relive, vamp_till_ready I'm sure we can come up with something! ChrisA [1] included mainly to troll the people who want some definition of "reiterable"
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 05:18 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.125.1470165533.6033.python-list@python.org> |
| In reply to | #112241 |
On Wed, Aug 3, 2016 at 3:57 AM, Steven D'Aprano
<steve+python@pearwood.info> wrote:
> On Wed, 3 Aug 2016 03:12 am, BartC wrote:
>
>> That's not a fundamental language feature. Repeat-N is. And if properly
>> designed, isn't an extra feature at all but a special case of a generic
>> loop.
>
> Which means it is NOT a fundamental language feature.
>
> "Repeat N without tracking the loop variable" is just a special case
> of "repeat N with tracking the loop variable", where you don't actually
> care what the loop variable is.
To be fair, that can be an important distinction. I don't like seeing
code like this:
def f():
x = g()
y = h(x)
return 5 + x
What's y for? Why not just call h(x) and ignore its return value?
Should the last line say "5 + y"? It looks _wrong_ to have a local
variable that's never used. It's still not a consideration strong
enough to demand new loop syntax, though.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2016-08-02 21:55 +0200 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnqtqo$5l4$1@dont-email.me> |
| In reply to | #112228 |
Am 02.08.16 um 16:58 schrieb Chris Angelico: > - A more free-form declarative syntax for laying out GUI code Actually, the Tkinter wrapper misses one feature of grid in Tcl/Tk: You can write something like grid .a .b grid .c .d to lay out a GUI 2x2 grid using "ASCII-art". There is a package in Tcl, gridplus2 (http://www.satisoft.com/tcltk/gridplus2/example1.html) which allows the design of quite complex screens from such ASCII-art - a Python translation should not be that difficult (but nobody does it) > - Arbitrary-precision non-integers https://pypi.python.org/pypi/bigfloat/ ? > - Convenient syntax for a few array/list manipulations Huh? Slices and list comprehensions go a long way. What syntax can you imagine that goes beyond that? Christian
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 06:50 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.128.1470171006.6033.python-list@python.org> |
| In reply to | #112251 |
On Wed, Aug 3, 2016 at 5:55 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
>> - Arbitrary-precision non-integers
>
>
> https://pypi.python.org/pypi/bigfloat/
>
> ?
Wasn't aware of that. Cool. Not that I need it very often (and when I
do, I can use Pike, which has MPFR support built-in). Or I can use
decimal.Decimal, which isn't exactly the same, but often accomplishes
the same thing.
>> - Convenient syntax for a few array/list manipulations
>
>
> Huh? Slices and list comprehensions go a long way. What syntax can you
> imagine that goes beyond that?
Imagine you have a list (or array, depending on language) of objects,
some of which may be None (or null). Call the foo method on every
object, ignoring the null/None ones.
# Python - creates a useless list
[obj.foo() for obj in objects if obj]
# Python - a bit clunky
for obj in objects:
if obj:
obj.foo()
//Pike
objects->foo();
But my point wasn't "hey, Python sucks", but "look what is *not* on my
list". Other people's lists of stuff they miss will differ (either
because they know of third-party solutions, like bigfloat, or because
they just don't need them... like bigfloat), and that's fine and
correct.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-08-02 17:27 -0400 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.129.1470173244.6033.python-list@python.org> |
| In reply to | #112214 |
On 8/2/2016 7:05 AM, BartC wrote: > On 31/07/2016 19:58, Terry Reedy wrote: >> On 7/31/2016 6:18 AM, BartC wrote: > >>> repeat N: > >>> The benefit is not so much performance, but being able to express >>> something very easily and quickly. >> >> The cost of the 'repeat' contraction is that one cannot use the loop >> variable, either as part of a modified computation or for monitoring or >> debugging purposes. >> print(i, for_body_result) >> Beginners are often atrocious at debugging, and it seems not to be >> taught hardly at all. 'repeat n' erects a barrier to debugging. > >> Debugging: probing a computation to see what actually happens, as >> opposed to what one wanted and expected to happen. (Me, just now ;-) >> >> One major way of debugging is printing values as they are computed. >> Naming values (objects) allows them to be printed without recomputing >> the value. In the 'repeat n' context, recomputing would mean adding 3 >> lines of debugging code instead of 1. >> >> i = 0 >> repeat n: >> a = f(a) >> print(i, a) >> n += 1 > > Your objection to a feature such as 'repeat N' doesn't really stack up. My objection is that there is a real cost that MUST be stacked up against the benefit. ... > Anyway, if that was a valid objection, it would apply throughout the > language. In list-comps for example (there is an index, but where do you > stick the print?). In the expression. Given 'f(i) for i in range(n)', a careful debug version might be '(f(i), print(i))[0] for i in range(n)'. If the loop does not finish, the extra None component does not matter. and the subscripting could be omitted. > Or in a for-loop iterating over values: > > a=[10,20,30,40,50] > for x in a: > print (x) > > This will print the element, but what's the index? Irrelevant. The end of the sequence of prints says where the loop stopped. > According to you, > every such for-loop needs to be written in a form that provides the > index of a loop Don't pretend that I said that. It is not nice. > I get that people here don't want such a feature, but I don't think this > is the reason. > > I think the real reason is not willing to admit that the language lacks > something that could actually be useful, I think it is you who is unwilling to admit that nearly everything that would be useful also has a cost, and that the ultimate cost of adding every useful feature, especially syntax features, would be to make python less unusable. Some time around last August to October, I think, someone posted to python-ideas that he had produced a children's Python environment that accepted 'repeat n' statements and translated them to equivalent for loops before running. His idea was that 'repeat n' should be added to python itself so translation would not be needed. The main use of the statement in this context is for logo/turtle code with many side-effect-only calls. I though the idea plausible, at first, and noted that one could add an extension to IDLE to experiment further with the idea. An extension could add a menu ited such as 'de-repeat'. One could also, with about the same effort, *patch* IDLE to do the translation just before it calls compile(code, ...). Leaving IDLE aside, one could write a pyre.whatever script to translate a .pyre file to a .py file and run the latter. Any of these methods could be applied to experimenting with other 'improvement' ideas. Anyway, *after thinking about the idea for at least a week*, I became less enthusiastic about hiding the loop counter. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-08-02 14:54 -0700 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <871t266dlm.fsf@jester.gateway.pace.com> |
| In reply to | #112254 |
Terry Reedy <tjreedy@udel.edu> writes:
> I think it is you who is unwilling to admit that nearly everything
> that would be useful also has a cost, and that the ultimate cost of
> adding every useful feature, especially syntax features, would be to
> make python less unusable.
I think you meant "usable" ;). Some of this results from Python's
statement-vs-expression distinction. I'm not going to claim that's a
broken feature of Python, since it has its supporters; but languages
that don't make the distinction have more flexibility in implementing
such features as ordinary functions rather than syntax features.
Ruby: 17.times| code |
Haskell: replicateM_ 17 code
Lisp: (dotimes (i 17) code...)
etc.
The Lisp example binds 'i' to the loop index, but that's just a choice
made in how the dotimes macro was implemented. The scope of i is
limited to the dotimes construct, unlike in Python.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 23:38 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnr7e7$8qg$1@dont-email.me> |
| In reply to | #112254 |
On 02/08/2016 22:27, Terry Reedy wrote:
> On 8/2/2016 7:05 AM, BartC wrote:
>> Your objection to a feature such as 'repeat N' doesn't really stack up.
>
> My objection is that there is a real cost that MUST be stacked up
> against the benefit.
>
> ...
>> Anyway, if that was a valid objection, it would apply throughout the
>> language. In list-comps for example (there is an index, but where do you
>> stick the print?).
>
> In the expression. Given 'f(i) for i in range(n)', a careful debug
> version might be '(f(i), print(i))[0] for i in range(n)'. If the loop
> does not finish, the extra None component does not matter. and the
> subscripting could be omitted.
That's quite a big edit to the original code. I would duplicate the
line, comment out the original, and add the print code to the copy. Then
I can revert to the original without bugs creeping in. (Unless the rest
of the line has to change anyway.)
Same method is used with repeats:
for N: # or whatever syntax is used
If a loop index /has/ to be printed, comment out the above and extend a
copy of it to:
for i in range(N):
But only /if/ that value is needed; most won't. (I suspect that loops
repeated a set number of times might be simpler anyway.)
>> Or in a for-loop iterating over values:
>>
>> a=[10,20,30,40,50]
>> for x in a:
>> print (x)
>>
>> This will print the element, but what's the index?
>
> Irrelevant. The end of the sequence of prints says where the loop stopped.
But it might go wrong before it gets to the end. You need the index to
know how far along the list it's at.
>> I think the real reason is not willing to admit that the language lacks
>> something that could actually be useful,
>
> I think it is you who is unwilling to admit that nearly everything that
> would be useful also has a cost, and that the ultimate cost of adding
> every useful feature, especially syntax features, would be to make
> python less unusable.
[Did you mean 'less usable' here?]
I'm only concerned here with basic syntax. And most ideas already exist
in other languages (not just mine). But here's one I idea I think I
mentioned last year: having separators in numeric literals.
Now I look and see that PEP 515 describes it! (I think some versions of
Python will already have it).
Do people think that makes Python top-heavy in features and less usable?
I *know* that actually implementing most of this stuff is trivial
because I've done it a dozen times. And I appreciate that doing it in a
very large, existing 'live' language with millions of users has
administrative problems.
But the technical side of it is nothing compared to the 50Mloc tools
that have been mentioned.
>
> Some time around last August to October, I think, someone posted to
> python-ideas that he had produced a children's Python environment that
> accepted 'repeat n' statements and translated them to equivalent for
> loops before running. His idea was that 'repeat n' should be added to
> python itself so translation would not be needed. The main use of the
> statement in this context is for logo/turtle code with many
> side-effect-only calls.
Apparently 'repeat N' is a Logo statement so it makes sense to try and
emulate that within Python (to simplify porting Logo algorithms for
example).
> Leaving IDLE aside, one could write a pyre.whatever script to translate
> a .pyre file to a .py file and run the latter. Any of these methods
> could be applied to experimenting with other 'improvement' ideas.
Yes, I've experimented with that approach myself. Using a
source-to-source translator with Python as output. But the input was an
entirely different syntax (example: http://pastebin.com/Zj89YfTN).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-01 05:03 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.83.1469991805.6033.python-list@python.org> |
| In reply to | #112133 |
On Mon, Aug 1, 2016 at 4:58 AM, Terry Reedy <tjreedy@udel.edu> wrote: > > As for the original topic: Guido judged that a uniform rule "Compound > statement headers end with ':' and the next line has an additional indent" > would make correct code easier to write and parse and make it visually more > obvious. Some Python aware editors like IDLE automatically add the indent. Quite a few editors do, and even when that doesn't come into play (eg if you type code in piecemeal and don't take advantage of "press enter, indent automatically"), it's easy to say "Check line seventeen - remember, after a colon, you indent". It's a great policy. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-31 15:12 +1200 |
| Message-ID | <e058llFakgqU2@mid.individual.net> |
| In reply to | #112067 |
Chris Angelico wrote: > I mean, "for i in 3.5" should start half way down the loop body, complete that loop, and > then do three complete loops. +1, this is the best idea for a "loop-and-a-half" construct I've ever seen. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 14:07 +1000 |
| Message-ID | <mailman.67.1469938064.6033.python-list@python.org> |
| In reply to | #112110 |
On Sun, Jul 31, 2016 at 1:12 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> I mean, "for i in 3.5" should start half way down the loop body, complete >> that loop, and >> then do three complete loops. > > > +1, this is the best idea for a "loop-and-a-half" > construct I've ever seen. It was inspired by Duff's Device, which could then be implemented very easily by simply true-dividing by eight. :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 15:16 +0100 |
| Message-ID | <nnicr3$cn3$1@dont-email.me> |
| In reply to | #112066 |
On 30/07/2016 14:06, Steven D'Aprano wrote:
> End of story. As far as I am concerned, the 97% of languages which allow the
> visual structure of the code to differ from their logical structure are BAD
> LANGUAGES.
You mean languages that allow code like this:
a = (
b
+c *
d)
?
Another category is where code is written predominantly side-ways rather
than vertically. (Multiple chained method calls for example, or trying
to express something as a 'one-liner'.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 02:08 +1000 |
| Message-ID | <579cd0f2$0$1599$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112071 |
On Sun, 31 Jul 2016 12:16 am, BartC wrote:
> On 30/07/2016 14:06, Steven D'Aprano wrote:
>
>> End of story. As far as I am concerned, the 97% of languages which allow
>> the visual structure of the code to differ from their logical structure
>> are BAD LANGUAGES.
>
> You mean languages that allow code like this:
>
> a = (
> b
> +c *
>
>
> d)
>
> ?
Touché :-)
But the layout of an expression is not really what I'm referring to. The
whitespace between terms in an expression is meaningless. Yes, the example
you give is particularly ugly, but it's no different from:
a = ( b +c * d)
on one line. Allowing parentheses to cross over line boundaries is a case of
Practicality Over Purity: there are simply far too many cases where we
want, *need*, a single expression to go over two or more lines, and the
original solution (use a line continuation backslash) wasn't good enough.
I'm referring to flow control elements (if...else, for, while, try...except,
etc), plus a handful of other grouping elements (def, class, with). That's
what I call "logical structure" of the code, not incidental whitespace
between terms of a single expression.
Unfortunately, there's sometimes a conflict between these disparate wants. I
want the logical structure to be obvious; I want the freedom to arrange
expressions over multiple lines. Sometimes they conflict, in which case, I
do my best not to write ugly code. I'd be reluctant to prohibit expressions
from starting at the left of the current indent:
# This should always be allowed
def func():
# current indent aligns here
result = (
long expression
over multiple lines
)
return result
# But this moves to the left of the current indent
def func():
# current indent aligns here
result = (
long expression
over multiple lines
)
return result
I don't like that second case very much at all, but I wouldn't prohibit it,
because I've found too many real world cases where I have big expressions
(say, a table of values) where I need all the space I can get and need to
visually outdent it without logically outdenting it. Its an ugly compromise
between my otherwise very strict view, but that's life for you.
> Another category is where code is written predominantly side-ways rather
> than vertically. (Multiple chained method calls for example, or trying
> to express something as a 'one-liner'.)
I don't see the relevance. If you are writing a chain of method calls, its a
single expression. There's no structure to express.
As for one-liners, Python simply doesn't consider it important or necessary
to support writing arbitrary one-liners. There's some limited support for
the simple cases:
python -c "for x in range(100): print(x**2)"
but beyond that, you have to use multiple lines.
--
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 02:10 +1000 |
| Message-ID | <579cd16f$0$1599$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112066 |
On Sat, 30 Jul 2016 11:06 pm, Steven D'Aprano wrote: > If it a sign of a poor programmer that > ignores the common idioms of a language and writes in another > language's "grammar". /face-palm "If it a sign..." Of course that was not intentional. What's the law that says that any post complaining about somebody else's spelling or grammatical errors will contain an even worse example of the same? Sod's Law, or a special case of such. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-31 15:10 +1200 |
| Message-ID | <e058hgFakgqU1@mid.individual.net> |
| In reply to | #112066 |
Steven D'Aprano wrote: > In English, > we can talk about having a quick meal of fast food, but not a fast meal of > quick food. If you interpret "quick" in its original sense of "alive" then it's theoretically possible, although not practised much in civilised society these days. Yoghurt might qualify, though. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-30 10:39 -0400 |
| Message-ID | <mailman.53.1469889592.6033.python-list@python.org> |
| In reply to | #112048 |
On Sat, 30 Jul 2016 11:15:12 +0100 BartC <bc@freeuk.com> wrote: >> Doesn't it look like there's something missing in the Python? Both > the 'fi' or 'end', and the possibility of an 'h' statement. > > Note the Algol68-style style is more free-format where indents are > not significant. > > Anyway, if you're going to talk about annoying things forced upon you > by the language, what about: > > ":" after "else" > > "()" in "def fn():" > > "()" in "print (x)" for Python 3 > > "for i in range(N):" just to repeat a block N times... > > That's apart from the obligatory indents which, with an > 'end'-delimited scheme, are not always necessary. Has it occurred to you (as it has occurred to some of us) that Python just isn't your language? By the way, the last time I replied to you it went to the list but your address bounced. Was that a glitch or are you using an invalid address in a mailing list? -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:darcy@Vex.Net VoIP: sip:darcy@Vex.Net
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 16:14 +0100 |
| Message-ID | <nnig8c$nab$1@dont-email.me> |
| In reply to | #112072 |
On 30/07/2016 15:39, D'Arcy J.M. Cain wrote: > By the way, the last time I replied to you it went to the list but your > address bounced. Was that a glitch or are you using an invalid address > in a mailing list? Do you mean my email address? That was valid once but no longer. (If you want to send an email replace "bc" with "bcas".) I'm not using a mailing list; I'm posting to usenet. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-30 13:11 -0400 |
| Message-ID | <mailman.57.1469898675.6033.python-list@python.org> |
| In reply to | #112078 |
On Sat, 30 Jul 2016 16:14:18 +0100 BartC <bc@freeuk.com> wrote: > > By the way, the last time I replied to you it went to the list but > > your address bounced. Was that a glitch or are you using an > > invalid address in a mailing list? > > Do you mean my email address? That was valid once but no longer. (If > you want to send an email replace "bc" with "bcas".) Are you kidding me? It's not our job to replace things in your email address, it's yours. Fix your client. > I'm not using a mailing list; I'm posting to usenet. I don't care if you are using carrier pigeon. If you send an email address, make it a valid one. Maybe you should just change it to I_Am_a_Troll@nowhere. It's becoming increasingly obvious that you have absolutely no interest in Python and are just trying to get a rise out of people. *plonk* -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:darcy@Vex.Net VoIP: sip:darcy@Vex.Net
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web