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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | bart4858@gmail.com |
|---|---|
| Date | 2016-07-31 17:11 -0700 |
| Message-ID | <7f3efb38-e146-436d-b38e-a0e56427f7dc@googlegroups.com> |
| In reply to | #112139 |
On Sunday, 31 July 2016 16:31:56 UTC+1, Steven D'Aprano wrote: > On Sun, 31 Jul 2016 08:18 pm, BartC wrote: > The whole point of an optimizing compiler is that you don't have to detect > patterns yourself. The compiler does it. There's a whole science to writing > optimizing compilers these days, and they don't do it by hard-coding > dedicated syntax for each thing you want to optimize. That's very 1970s. Leaving out unneeded parts of a statement is not hand-optimising; it's just being sensible. But actually Python is chock-full of dedicated features designed to allow you to be very productive without writing much code. (Which is handy for a bytecode language as it means a lot of things will execute in native code.) Oddly people are much less keen on dedicated bits of syntax, even if it's a cut-down bit of something that's already there! > Bart, I'm not putting you down for having no users. But your judgement of > the pros and cons of a feature is biased one way because you only have to > please yourself. I'm suggesting ideas that originated in Algol68. Not widely used but not a one-person job either, and it is quite well regarded. (I love the syntax but don't care for the rest of it.) > In that same thread, one of the lead Python devs Victor Stinner talks about > some of his work on embedded devices where he has a hard limit of 128MB for > *everything*: boot loader, kernel, OS, applications, etc. (128MB or 128KB? In the 1980s we were all running in 64KB to 640KB of memory. 128MB might be what a well-endowed mainframe might have had!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-01 10:21 +1000 |
| Message-ID | <mailman.86.1470010909.6033.python-list@python.org> |
| In reply to | #112156 |
On Mon, Aug 1, 2016 at 10:11 AM, <bart4858@gmail.com> wrote: >> In that same thread, one of the lead Python devs Victor Stinner talks about >> some of his work on embedded devices where he has a hard limit of 128MB for >> *everything*: boot loader, kernel, OS, applications, etc. > > (128MB or 128KB? In the 1980s we were all running in 64KB to 640KB of memory. 128MB might be what a well-endowed mainframe might have had!) Yes, and we didn't have Python then. When I had a computer with 640KB of memory, my options were (1) BASIC or (2) 8086 assembly language, using DEBUG.EXE and its mini-assembler. Later on (much much later), I added C to the available languages, but it was tedious and annoying, because one tiny change meant minutes of compilation. Also, I had to fit everything inside 20MB of hard disk space, which was shared with my brother. I'm not sure whether 128MB is work memory or total storage, but I would suspect the latter. The idea of a sourceless Python distribution isn't to cut down on RAM usage but storage, if I understand correctly. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 17:55 -0700 |
| Message-ID | <874m7571eq.fsf@jester.gateway.pace.com> |
| In reply to | #112158 |
Chris Angelico <rosuav@gmail.com> writes:
> Yes, and we didn't have Python then. When I had a computer with 640KB
> of memory, my options were (1) BASIC or (2) 8086 assembly language,
> using DEBUG.EXE and its mini-assembler. Later on (much much later), I
> added C to the available languages, but it was tedious and annoying,
> because one tiny change meant minutes of compilation.
1. check this out: http://prog21.dadgum.com/116.html
2. There were also some decent Lisps for the PC. Sort of like Python
but with parentheses as structure instead of indentation:
http://norvig.com/python-lisp.html
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-01 11:10 +1000 |
| Message-ID | <mailman.88.1470013820.6033.python-list@python.org> |
| In reply to | #112160 |
On Mon, Aug 1, 2016 at 10:55 AM, Paul Rubin <no.email@nospam.invalid> wrote: > Chris Angelico <rosuav@gmail.com> writes: >> Yes, and we didn't have Python then. When I had a computer with 640KB >> of memory, my options were (1) BASIC or (2) 8086 assembly language, >> using DEBUG.EXE and its mini-assembler. Later on (much much later), I >> added C to the available languages, but it was tedious and annoying, >> because one tiny change meant minutes of compilation. > > 1. check this out: http://prog21.dadgum.com/116.html > Judge him by his size, do you? But out of 20MB, I easily had *space* for a compiler. The problem was compilation time. I could mess around in BASIC with reasonable turnaround times; I could mess around in DEBUG with excellent turnaround times. Doing even the tiniest work in C meant delays long enough to go do something else. How times have changed. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 19:09 -0700 |
| Message-ID | <87ziox5jg1.fsf@jester.gateway.pace.com> |
| In reply to | #112161 |
Chris Angelico <rosuav@gmail.com> writes: > But out of 20MB, I easily had *space* for a compiler. The problem was > compilation time. I could mess around in BASIC with reasonable > turnaround times; I could mess around in DEBUG with excellent > turnaround times. Doing even the tiniest work in C meant delays long > enough to go do something else. Which compiler did you use? Turbo C was quite fast even on the 8088, and Turbo Pascal was even faster: http://prog21.dadgum.com/47.html explains why Pascal was faster to compile than C. F83 (Forth-83) and later F-PC also ran on the bare bones PC and were also interactive and super responsive. As interpreters they were slower than compiled C, but quite a bit faster than interpreted BASIC, and it was simple to write functions in assembly code (built-in assemblers) if you needed them fast. I never used any of them back then, but more recently have been reading about them out of general interest.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-01 12:14 +1000 |
| Message-ID | <mailman.91.1470017661.6033.python-list@python.org> |
| In reply to | #112164 |
On Mon, Aug 1, 2016 at 12:09 PM, Paul Rubin <no.email@nospam.invalid> wrote: > Chris Angelico <rosuav@gmail.com> writes: >> But out of 20MB, I easily had *space* for a compiler. The problem was >> compilation time. I could mess around in BASIC with reasonable >> turnaround times; I could mess around in DEBUG with excellent >> turnaround times. Doing even the tiniest work in C meant delays long >> enough to go do something else. > > Which compiler did you use? Turbo C was quite fast even on the 8088, > and Turbo Pascal was even faster: > > http://prog21.dadgum.com/47.html > > explains why Pascal was faster to compile than C. Back then? Microsoft Quick C, which disposed of the awkward part in the title and thus didn't need to be quick anywhere else. It was the only compiler I had access to. Later on, I used the Borland C/C++ compiler, a Windows program (which I ran under OS/2) and my first-ever IDE with actual syntax highlighting and stuff. I didn't really appreciate it at the time - thought the coloration and bold and stuff were pretty useless. Took me another few years to come to value that as a feature. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2016-08-01 00:55 -0700 |
| Message-ID | <cc498ff8-a463-4ae1-b5ba-2ad56f8bb8a2@googlegroups.com> |
| In reply to | #112158 |
On Monday, 1 August 2016 01:22:02 UTC+1, Chris Angelico wrote: > On Mon, Aug 1, 2016 at 10:11 AM, <bart4858@gmail.com> wrote: > > (128MB or 128KB? In the 1980s we were all running in 64KB to 640KB of memory. 128MB might be what a well-endowed mainframe might have had!) > > Yes, and we didn't have Python then. When I had a computer with 640KB > of memory, my options were (1) BASIC or (2) 8086 assembly language, > using DEBUG.EXE and its mini-assembler. Later on (much much later), I > added C to the available languages, but it was tedious and annoying, > because one tiny change meant minutes of compilation. This wasn't my experience. I used my own tools and designed them to always be quick enough in use that compilation speed was never really an issue. Not even on 8-bit machines. I was also happily running my interpreters within 640KB (less than that too depending on customers' machines). So that 128MB limit, or *two hundred* times as much memory, was a hardly a limitation! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-07-31 22:08 -0400 |
| Message-ID | <mailman.90.1470017296.6033.python-list@python.org> |
| In reply to | #112156 |
On Mon, 1 Aug 2016 10:21:46 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following:
>
>Yes, and we didn't have Python then. When I had a computer with 640KB
>of memory, my options were (1) BASIC or (2) 8086 assembly language,
>using DEBUG.EXE and its mini-assembler. Later on (much much later), I
Was MS-DOS really that bloated?
My TRS-80 Model III/4 {upgraded circuit board, original power supply}
supported: interpreted BASIC, Pro-MC (Misosys K&R C compiler -- precursor
was LC -- an integer "tiny C") with assembler, Alcor Pascal, and from my
cassette-based original Mod-III -- Supersoft LISP.
That was on 64kB (actually, LISP was on 32kB -- I didn't get 64kB until
adding the first floppy, and bank-swapped 128k with the M-4 upgrade).
I'll confess to using a 2.5MB Amiga A-1000 -- by spending a few minutes
copying the Aztec C system from floppies into a RAM disk on the 2GB
extension box -- and then running compiles using the base 512kB RAM.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Gene Heskett <gheskett@shentel.net> |
|---|---|
| Date | 2016-07-31 21:29 -0400 |
| Message-ID | <mailman.89.1470015986.6033.python-list@python.org> |
| In reply to | #112139 |
On Sunday 31 July 2016 12:39:00 Dennis Lee Bieber wrote: > On Mon, 01 Aug 2016 01:31:42 +1000, Steven D'Aprano > <steve@pearwood.info> > > declaimed the following: > >And you know what? That's fine. It's *good* that there are language > >designers with different ideas of what's valuable. That gives us a > > rich eco-system of languages to pick and choose from. Can you > > imagine if everyone thought the same way and valued the same things? > > We have *one* language, and it would probably be COBOL. > > FORTRAN Nah, Forth. > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/ Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-07-31 14:58 -0400 |
| Subject | Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.81.1469991502.6033.python-list@python.org> |
| In reply to | #112133 |
On 7/31/2016 6:18 AM, BartC wrote:
> The costs are near zero: at minimum, a syntactic construct such as:
>
> repeat N:
>
> that expands to:
>
> for _ in range(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
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.
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 12:05 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnpuqh$mug$1@dont-email.me> |
| In reply to | #112150 |
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.
Debugging code is stuff that you add temporarily to find out what's
going on, then you get rid of it to leave the clean, unfettered lines of
the program.
You don't want people wondering where that loop index may or may not be
used.
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?). 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? According to you,
every such for-loop needs to be written in a form that provides the
index of a loop, on the off-chance that someone might want to print its
value somewhere in the body! ('for (i,x) in enumerate(a):')
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, and especially not to an
upstart on usenet who is not even an expert in that language.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 00:58 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.117.1470149940.6033.python-list@python.org> |
| In reply to | #112214 |
On Tue, Aug 2, 2016 at 9:05 PM, BartC <bc@freeuk.com> wrote: > I think the real reason is not willing to admit that the language lacks > something that could actually be useful, and especially not to an upstart on > usenet who is not even an expert in that language. I know what features I miss from the languages I use most frequently. Here, let me help you out a bit with some examples: Python - Support for live code reloads without restarting the process - A more free-form declarative syntax for laying out GUI code - Arbitrary-precision non-integers - Convenient syntax for a few array/list manipulations - Truly concurrent threads - Extreme short-hand for executing external commands, the way REXX does Pike - Keyword arguments - "obj in collection" syntax for membership testing - Better documentation in places - Out-of-the-box GTK support on OSX - As with Python, external command execution shorthand Notice that I did not put "Bracey syntax" under Python, nor "Braceless syntax" under Pike, despite them not having those options. Notice also that I didn't put "simpler loop syntax" in either; Python's loops you know about, and Pike gives you the C-style "for (int i=0; i<10; ++i)" form and "foreach (collection, item)" like Python's "for item in collection". The only thing I might yearn for - *MIGHT* - would be for Python to gain an "index-and-value" iteration form like Pike's "foreach (collection; index; value)", which for dictionaries would be like iterating over .items(), and for lists would be like using enumerate(). But I've never actually found myself yearning for it while I'm writing Python code - it's a small convenience when I'm working in Pike, is all. Does Python "lack" the simple repeat statement? Well, in the sense that it doesn't have it, sure. But Python also doesn't have a single function to read a line from a gzipped file and strip HTML tags from it before returning it [1]. Not everything that doesn't exist is needed. ChrisA [1] http://php.net/manual/en/function.gzgetss.php
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 18:12 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnqk9h$32k$1@dont-email.me> |
| In reply to | #112228 |
On 02/08/2016 15:58, Chris Angelico wrote: > On Tue, Aug 2, 2016 at 9:05 PM, BartC <bc@freeuk.com> wrote: >> I think the real reason is not willing to admit that the language lacks >> something that could actually be useful, and especially not to an upstart on >> usenet who is not even an expert in that language. > > I know what features I miss from the languages I use most frequently. > Here, let me help you out a bit with some examples: > > Python > - Support for live code reloads without restarting the process If that means what I think it means (ie. effectively re-doing an import statement) then I agree. I think I used a similar feature in the past, but with limitations (the module had one only entry point accessible from the code that imports it). It was used for developing much of an application not only without restarting it, but from inside the application (effectively using it as an IDE). Very, very useful. > that I didn't put "simpler loop syntax" in either; Python's loops you > know about, and Pike gives you the C-style "for (int i=0; i<10; ++i)" You've just hit on another bugbear of mine. I detest that form of loop! > Does Python "lack" the simple repeat statement? Well, in the sense > that it doesn't have it, sure. But Python also doesn't have a single > function to read a line from a gzipped file and strip HTML tags from > it before returning it [1]. Not everything that doesn't exist is > needed. 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+python@pearwood.info> |
|---|---|
| Date | 2016-08-03 03:57 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <57a0def4$0$1603$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112237 |
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. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-02 20:14 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnqre7$sis$1@dont-email.me> |
| In reply to | #112241 |
On 02/08/2016 18:57, Steven D'Aprano 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. It's fundamental in that, when giving instructions or commands in English, it frequently comes up when you want something done a set number of times: "Give me 20 push-ups" "Press space 5 times" "Do 10 laps" Whoever has to execute these may need to keep count somehow, but that is not the concern of the person giving the commands. You wouldn't say, count from 1 to 20, and for each value in turn, do a push-up. You could also say count backwards from 95 to 0 in fives; same effect. There are so many ways of specifying a loop that is executed 20 times, that no one way can be the right one. So that extra information is irrelevant. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-08-03 15:43 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <57a18490$0$1601$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112244 |
On Wednesday 03 August 2016 05:14, BartC wrote:
> It's fundamental in that, when giving instructions or commands in
> English, it frequently comes up when you want something done a set
> number of times:
>
> "Give me 20 push-ups"
At which point the person will invariable drop to the ground and start counting
one...two.....thrrrrrreee.........fooooooourrrr....................fiiiiiive...
Counting is more fundamental than addition. You cannot do 20 push-ups without
in some sense counting.
> "Press space 5 times"
>
> "Do 10 laps"
>
> Whoever has to execute these may need to keep count somehow,
> but that is not the concern of the person giving the commands.
Perhaps not. I don't doubt that there are times where you don't care about the
loop variable. Fine, you don't care.
There are times that I perform an operation which might fail, and I don't care
if it fails. I have to still catch the exception. There's no dedicated syntax
to "run this and ignore exceptions", you just use the general purpose
try...except syntax.
try:
this()
except Exception:
pass
rather than:
this() # may raise
$this() # won't raise
Not everything that is done is worth the cognitive burden of memorising a
special case.
> You wouldn't say, count from 1 to 20, and for each value in turn, do a
> push-up. You could also say count backwards from 95 to 0 in fives; same
> effect. There are so many ways of specifying a loop that is executed 20
> times, that no one way can be the right one. So that extra information
> is irrelevant.
Sure. That's why we have idioms like `for i in range(20)`, rather than have
people consider `for i in [None]*20` or `range(53, 114, 3)`. Even if we had a
dedicated `repeat 20` syntax, it would still be merely a convention that you
use it rather than `for i in range(53, 114, 3)`.
In some ways, Python is a more minimalist language than you like. That's okay,
you're allowed to disagree with some design decisions. I personally think that
new f-strings-that-aren't-actually-strings-but-more-like-eval-in-disguise are a
terrible idea, and I think that some of the rejected ideas were good ones.
That's part of the reason why we have so many different languages: people can
disagree on what things should be features.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-03 11:16 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnsg9v$sol$1@dont-email.me> |
| In reply to | #112262 |
On 03/08/2016 06:43, Steven D'Aprano wrote: > Not everything that is done is worth the cognitive burden of memorising a > special case. .... > In some ways, Python is a more minimalist language than you like. That's okay, > you're allowed to disagree with some design decisions. Well it's minimalist in some ways, and completely the opposite in others! It uses minimal basic syntax (missing a couple of loop forms, loop controls, switch/case, select-expressions... it's just a handful of features). But then you get to the standard library, and the plethora of different data types, methods and options. It's never-ending! So the idea that remembering 'repeat N' is a cognitive burden, and the myriad string operations for example are not, is ridiculous. (Especially when 'repeat N' will have an obvious counterpart in some other languages, but 'str.encode(...)' for example will not.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-08-03 23:18 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <mailman.141.1470230292.6033.python-list@python.org> |
| In reply to | #112270 |
On Wed, Aug 3, 2016 at 8:16 PM, BartC <bc@freeuk.com> wrote:
> On 03/08/2016 06:43, Steven D'Aprano wrote:
>
>> Not everything that is done is worth the cognitive burden of memorising a
>> special case.
>
> ....
>
>> In some ways, Python is a more minimalist language than you like. That's
>> okay,
>> you're allowed to disagree with some design decisions.
>
>
> Well it's minimalist in some ways, and completely the opposite in others!
>
> It uses minimal basic syntax (missing a couple of loop forms, loop controls,
> switch/case, select-expressions... it's just a handful of features).
>
> But then you get to the standard library, and the plethora of different data
> types, methods and options. It's never-ending!
The standard library doesn't have the cognitive burden that the core
language has. For starters, it's all namespaced; for seconds, once
you've mastered language syntax, you can introspect for documentation
(simplest form: help(obj) at the interactive prompt).
> So the idea that remembering 'repeat N' is a cognitive burden, and the
> myriad string operations for example are not, is ridiculous.
>
> (Especially when 'repeat N' will have an obvious counterpart in some other
> languages, but 'str.encode(...)' for example will not.)
Myriad string operations? Let's see.
>>> dir("")
['__add__', '__class__', '__contains__', '__delattr__', '__dir__',
'__doc__', '__eq__', '__format__', '__ge__', '__getattribute__',
'__getitem__', '__getnewargs__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__iter__', '__le__', '__len__', '__lt__',
'__mod__', '__mul__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__rmod__', '__rmul__', '__setattr__',
'__sizeof__', '__str__', '__subclasshook__', 'capitalize', 'casefold',
'center', 'count', 'encode', 'endswith', 'expandtabs', 'find',
'format', 'format_map', 'index', 'isalnum', 'isalpha', 'isdecimal',
'isdigit', 'isidentifier', 'islower', 'isnumeric', 'isprintable',
'isspace', 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip',
'maketrans', 'partition', 'replace', 'rfind', 'rindex', 'rjust',
'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 'startswith',
'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']
We have:
* Dunder methods and attributes, used for implementing other features.
You ignore them in regular code.
* Methods that do what other languages do with stand-alone functions.
It's not much different to do "spam".capitalize() than
capitalize("spam") or "spam".replace("sp","h") than
replace("spam","sp","h"). Likewise the "is*" functions,
startswith/endswith, and other querying functions.
* String formatting (both format and format_map). That probably
belongs in the previous category, but since Python's .format() method
differs from every other string formatting out there, you could say it
takes extra cognitive load. But honestly, what modern language doesn't
have some sort of formatted-string system, at least in its standard
library?
* join(), which most languages have as an array method that takes a
string, but Python has as a string method that takes any iterable.
Yes, that's a bit weird, I know. We can give you that one.
* And, uhh... you specifically mentioned encoding strings to bytes.
Well, Pike doesn't have that as a method. Instead, you have
string_to_utf8() for the most common case (and, naturally,
utf8_to_string() to convert bytes to text), and then has a Charset
module for all other conversions. Cognitive burden? Pretty much
equivalent.
I would say str.encode() has barely more cognitive burden than repeat
N would have. To get your head around "repeat N", you have to
understand that a computer can do things more than once. To get your
head around "spam".encode("utf-8"), you have to understand that bytes
are a means of representing text, and that they're not the same thing.
Yes, that's a bit harder (if you teach algorithms using a pen and
paper, you'll probably conflate data with its representation, since
there's no representation of the representation), but not hugely.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+python@pearwood.info> |
|---|---|
| Date | 2016-08-04 13:23 +1000 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <57a2b532$0$1597$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112270 |
On Wed, 3 Aug 2016 08:16 pm, BartC wrote:
> On 03/08/2016 06:43, Steven D'Aprano wrote:
>
>> Not everything that is done is worth the cognitive burden of memorising a
>> special case.
> ....
>
>> In some ways, Python is a more minimalist language than you like. That's
>> okay, you're allowed to disagree with some design decisions.
>
> Well it's minimalist in some ways, and completely the opposite in others!
>
> It uses minimal basic syntax (missing a couple of loop forms, loop
> controls, switch/case, select-expressions... it's just a handful of
> features).
>
> But then you get to the standard library, and the plethora of different
> data types, methods and options. It's never-ending!
"Never-ending" is a bit of an exaggeration. You should check out the Java
libraries, and how many different kinds of key:value mapping they provide.
They make Python's collection of types look positively anaemic :-)
In general, most types and operations in Python earned their place by
proving their usefulness. They proved that they are useful, hard to program
correctly, easy to get wrong, or some combination of all three. Many of
them have gone through a gruelling process of discussion via a Python
Enhancement Proposal (PEP) before being accepted. Having written two PEPs,
I can tell you that in general the Python core developers attitude to
adding new features, types or operations is to be very conservative and say
No. Most suggestions get rejected even before that point.
For instance, Guido used to reject the idea of having a ternary if operator
for years. Python didn't need it, you can use an if...else statement, or
when you need an if expression, use shortcut bool operators:
result = condition and x or y
gives x if condition is true and y if condition is false.
At least, that's what Guido used to say... until he personally got bitten by
a flaw in the argument. If x is a falsey argument, y is always returned. It
took something in excess of 15 years before anyone publicly noticed this
flaw, and when Guido did, Python pretty quickly got a ternary if operator.
> 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
low on the burden side, and Guido has done the opposite.
This is, of course, a subjective argument. I'm not trying to convince you
that you're wrong and Python is right. I completely accept that different
people have different opinions on the usefulness versus burden of adding a
specific feature. (That's why we have different languages, and some people
like Perl where there are a million ways to do everything and some people
don't.) I'm just trying to get you to understand where Python is coming
from, not necessary to agree with every one of its design decisions, but to
understand why they are the way they are.
Its trivial to perform "repeat N" using the standard "for x in ..." syntax
and built-in range() function, so including a dedicated "repeat N" syntax
doesn't add much to the language. It's a trivial operation easily performed
using a for loop. So the benefit is small. The cost is also small, but
greater than the benefit: there's a new keyword, which means any code
using "repeat" as a variable, function or method will break. Its more code
in the compiler (even if it's only an extra ten bytes, that's still more).
It's another feature that needs to be documented and tested. It's another
decision for users to make, "should I use repeat N, or a for loop?", and
another feature beginners to learn.
Individually these costs are small, but they aren't *zero*. Collectively,
according to the judgement of the people making the decision, they add up
to more cost than the minimal benefit that "repeat N" would bring.
But to take your example of str.encode... if Python didn't provide it, it
would be a dozen kinds of a pain in the arse to provide it yourself.
Especially with any sort of efficiency. Not to mention actually coming up
with the encodings themselves. There are *dozens* of them. Adding one more
string method "encode" to the dozens already there is not much of an
additional burden. It doesn't stop people from using "encode" as a function
name or variable, since the encode method is isolated to the str namespace.
It provides a very important function, one which is critical in the
post-ASCII world, and it is too difficult to expect users to implement
their own. So the benefit is much greater than the cost.
On the other hand, there's also str.swapcase(), which only remains due to a
combination of nostalgia and backwards compatibility. Occasionally people,
including Guido, suggest removing it: its pretty much useless, and hardly
anyone uses it. It isn't hard to write your own version, and its unlikely
to be used in performance-critical code. So removing the feature has very
little cost. But the benefit from removal is also correspondingly tiny.
Even if it only affects ten Python developers in the whole world, forcing
them to write their own swapcase function, that cost is greater than the
benefit from removing it. And so it stays.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-04 10:13 +0100 |
| Subject | Re: Debugging (was Re: Why not allow empty code blocks?) |
| Message-ID | <nnv10s$gng$1@dont-email.me> |
| In reply to | #112317 |
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? 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. 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. 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.) (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)) Compare all that (and I'm sure there's tons more) with, for example, just leaving out the 'i in' in 'for range(N):') -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web