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 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-29 12:20 -0400 |
| Message-ID | <mailman.30.1469809220.6033.python-list@python.org> |
| In reply to | #112014 |
On Fri, 29 Jul 2016 14:15:01 +0100 BartC <bc@freeuk.com> wrote: > > try: > > Some code > > # except Some_Exception: > > # Commented code for when I am debugging <Some code> > > Will it behave the same way when there is a Some_Exception exception? Of course not. The person writing that was an idiot. Oh wait - I wrote that. Damn! There must have been a reasonable excuse then. Naturally that part of my message was the only thing commented on. I suppose people stopped reading after that flub and missed my insightful comment on premature developer optimization. Getting more coffee now. -- 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 | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-07-29 15:46 +0200 |
| Message-ID | <mailman.25.1469800041.6033.python-list@python.org> |
| In reply to | #111789 |
Op 29-07-16 om 13:14 schreef D'Arcy J.M. Cain: > On Fri, 29 Jul 2016 10:58:35 +0200 > Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote: >> As BartC already mentions it happens fairly often during debugging. >> Something like. >> >> try: >> Some code >> except Some_Exception: >> # Commented code for when I am debugging <Some code> >> pass > I realize that that's a simplified example but really, isn't this just > as easy? > > try: > Some code > # except Some_Exception: > # Commented code for when I am debugging <Some code> That code doesn't behave the same. > If your code block really is one line is "pass #" really so much more > of a hardship than "#"? If it is a large block use "pass #@#" which is > easy to remove with a search and replace. Whose talking about hardschip? I don't trouble my self with removing the pass statement when the debugging code is active. But Chris seemed to suggest a situation like above was really rare, so I answered his question. -- Antoon.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2016-07-29 15:43 -0400 |
| Message-ID | <mailman.36.1469821397.6033.python-list@python.org> |
| In reply to | #111789 |
On 7/29/2016 4:58 AM, Antoon Pardon wrote: > Op 23-07-16 om 16:19 schreef Chris Angelico: >> On Sun, Jul 24, 2016 at 12:00 AM, BartC <bc@freeuk.com> wrote: >>> Or, for debugging or other reasons, when you need to comment out the >>> contents of a block. Then pass needs to be added. >> How often do you comment out an entire block and not its header? I >> don't remember the last time I did that. It's certainly not so common >> that adding 'pass' takes up a significant part of a debugging session. >> >> ChrisA > > As BartC already mentions it happens fairly often during debugging. > Something like. > > try: > Some code > except Some_Exception: > # Commented code for when I am debugging <Some code> > pass So put in 'pass' whether or not there is no debugging code, commented-out debugging code, or debugging code that runs, or whatever. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-29 21:19 +0100 |
| Message-ID | <nngdns$um1$1@dont-email.me> |
| In reply to | #112028 |
On 29/07/2016 20:43, Terry Reedy wrote: > On 7/29/2016 4:58 AM, Antoon Pardon wrote: >> Something like. >> >> try: >> Some code >> except Some_Exception: >> # Commented code for when I am debugging <Some code> >> pass > > So put in 'pass' whether or not there is no debugging code, > commented-out debugging code, or debugging code that runs, or whatever. But that's inelegant. The language requires that blocks always contains 1 or more statements. Fair enough, except that 0 statements are often needed so that a dummy statement - 'pass' - is required just to keep the code legal. That's untidy, as is your suggestion to keep the dummy statement lying around anyway so that the number of statements will always be N+1 and can never reach 0 as N changes. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-07-30 01:01 +0300 |
| Message-ID | <871t2cf6iv.fsf@elektro.pacujo.net> |
| In reply to | #112029 |
BartC <bc@freeuk.com>:
> On 29/07/2016 20:43, Terry Reedy wrote:
>> So put in 'pass' whether or not there is no debugging code,
>> commented-out debugging code, or debugging code that runs, or whatever.
>
> But that's inelegant.
>
> The language requires that blocks always contains 1 or more
> statements. Fair enough, except that 0 statements are often needed so
> that a dummy statement - 'pass' - is required just to keep the code
> legal.
>
> That's untidy, as is your suggestion to keep the dummy statement lying
> around anyway so that the number of statements will always be N+1 and
> can never reach 0 as N changes.
Yes, untidy, albeit only slightly. What you gain is visible blocks.
The gods have spoken and have decided for visibility over philosophical
elegance.
I *have* been hit with analogous untidiness in classic C, which didn't
accept empty structs or empty arrays. I was generating C arrays from a
compiler and--annoyingly--had to place special checks in the compiler to
place a dummy element in an array where none would be generated
naturally.
I have also had to spend some time debugging some segmentation faults
caused by #ifdef's and surprising sizeof calculations in (classic) C and
(modern) C++. Look at this structure:
struct S {
int x[0];
};
Gcc claims sizeof(struct S) == 0 in C and C++.
Well, that's natural, right?
How about:
struct S {
};
Now gcc claims sizeof(struct S) == 0 if the language is C but
sizeof(struct S) == 1 if the language is C++.
That's because Stroustrup is allergic to 0-size data structures the way
GvR is allergic to 0-size blocks.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-30 13:35 +1000 |
| Message-ID | <579c2095$0$22142$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112029 |
On Sat, 30 Jul 2016 06:19 am, BartC wrote: > The language requires that blocks always contains 1 or more statements. > Fair enough, except that 0 statements are often needed They really aren't. The standard library uses more "pass" statements than most code I've seen, because of the large number of abstract methods and tests that use dummy classes or methods. If you are writing library code, or a framework, with lots of "do nothing" blocks that the caller is supposed to override, you may find yourself doing the same. Even so, the number of "pass" statements is a tiny proportion of code, less than one percent for Python 3.6: [steve@ando Lib]$ wc -l *.py */*.py | tail -n 1 541022 total [steve@ando Lib]$ grep "pass$" *.py */*.py | wc -l 3286 Over two thirds of them are from the test suite: [steve@ando Lib]$ grep "pass$" test/*.py | wc -l 2270 I feel confident in saying that if you find yourself writing "pass" in application code (as opposed to writing a framework or unit tests for a library) more than one time in a 500 lines of code, you're doing something wrong. But even if it were as high as one time in 100 lines, it is still not an onerous requirement. You should see how many times Ruby programmers have to write "end", 99.9% of which are unneeded but forced on them by the language. -- Steven “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-07-30 11:15 +0100 |
| Message-ID | <nnhuni$op$1@dont-email.me> |
| In reply to | #112040 |
On 30/07/2016 04:35, Steven D'Aprano wrote:
> On Sat, 30 Jul 2016 06:19 am, BartC wrote:
>
>> The language requires that blocks always contains 1 or more statements.
>> Fair enough, except that 0 statements are often needed
>
> They really aren't.
>
> The standard library uses more "pass" statements than most code I've seen,
> because of the large number of abstract methods and tests that use dummy
> classes or methods. If you are writing library code, or a framework, with
> lots of "do nothing" blocks that the caller is supposed to override, you
> may find yourself doing the same. Even so, the number of "pass" statements
> is a tiny proportion of code, less than one percent for Python 3.6:
>
> [steve@ando Lib]$ wc -l *.py */*.py | tail -n 1
> 541022 total
> [steve@ando Lib]$ grep "pass$" *.py */*.py | wc -l
> 3286
>
>
> Over two thirds of them are from the test suite:
>
> [steve@ando Lib]$ grep "pass$" test/*.py | wc -l
> 2270
Interesting use of 'pass' in this example:
http://pastebin.com/aYJdgEL4
(I do believe he's using 'pass' as 'end'! Although he misses some out in
that case.)
>
> I feel confident in saying that if you find yourself writing "pass" in
> application code (as opposed to writing a framework or unit tests for a
> library) more than one time in a 500 lines of code, you're doing something
> wrong. But even if it were as high as one time in 100 lines, it is still
> not an onerous requirement.
>
> You should see how many times Ruby programmers have to write "end", 99.9% of
> which are unneeded but forced on them by the language.
Think of it as a pattern. In one language, I used (Algol68-style), a
simple if was:
if a then b else c fi
which could also be written more compactly, as suits an expression:
( a | b | c )
Then the 'fi' (that is, 'end' or 'end if') is just closing the construct
started with 'fi', in the same way that ')' closes the opening '('.
As I've mentioned, Python also uses explicit block delimiters in the
form of else, elif, except, finally (and whichever ones I've misssed):
if x: a; b elif y: c; d elif z: e; f else: g
In the above syntax, it would be:
if x then a; b elsif y then c; d elsif z then e; f else g fi
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.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 21:25 +1000 |
| Message-ID | <mailman.43.1469877947.6033.python-list@python.org> |
| In reply to | #112048 |
On Sat, Jul 30, 2016 at 8:15 PM, BartC <bc@freeuk.com> wrote: > Anyway, if you're going to talk about annoying things forced upon you by the > language, what about: > > "()" in "print (x)" for Python 3 Why are you singling out print? It's just a function like any other. Are you complaining about the way function calls need parentheses? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 04:39 -0700 |
| Message-ID | <c6df24e3-3f4f-43be-be18-bc9eaa91606b@googlegroups.com> |
| In reply to | #112052 |
On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote: > On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote: > > Anyway, if you're going to talk about annoying things forced upon you by the > > language, what about: > > > > "()" in "print (x)" for Python 3 > > Why are you singling out print? It's just a function like any other. > Are you complaining about the way function calls need parentheses? Its a function… ok. Its ‘just’ a function… Arguable For example: - Prior Art: Its builtin and special in Fortran, Pascal, Basic - More immediate : It was a special in python2 - Poorer error catching: What was a straight syntax error is now a lint-catch (at best) [print (x) for x in range(20)]
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 21:49 +1000 |
| Message-ID | <mailman.44.1469879353.6033.python-list@python.org> |
| In reply to | #112053 |
On Sat, Jul 30, 2016 at 9:39 PM, Rustom Mody <rustompmody@gmail.com> wrote: > On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote: >> On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote: >> > Anyway, if you're going to talk about annoying things forced upon you by the >> > language, what about: >> > >> > "()" in "print (x)" for Python 3the modulo operator >> >> Why are you singling out print? It's just a function like any other. >> Are you complaining about the way function calls need parentheses? > > Its a function… ok. > Its ‘just’ a function… Arguable > > For example: > > - Prior Art: Its builtin and special in Fortran, Pascal, Basic And it's not built-in or special in C, or a bunch of other languages. > - More immediate : It was a special in python2 Which resulted in unmitigatable problems, such as that you can't mock it for testing or redirection purposes, and it demands syntactic magic to do its work - for instance, the only option is a "soft space" in place of a newline, where the print function allows full customization of both end= and sep=. The print function is DEFINITELY an improvement. I would also posit that an sprintf() built-in function instead of str.__mod__ would have meant there was less kickback against printf-style formatting, because it wouldn't have had the strange behaviour around single-argument use. (It's pretty simple to write, of course, but built-ins are extremely significant to perception. def sprintf(fmt, *args): return fmt % args) Syntax is NOT always an improvement. > - Poorer error catching: What was a straight syntax error is now a lint-catch (at best) > [print (x) for x in range(20)] Huh? Aside from the fact that you're constructing a useless list of Nones, what's the error? Also: Why is print special here? Maybe you accidentally called frobnicate on those x's and you shouldn't have. How is Python supposed to know that that's an error? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 05:11 -0700 |
| Message-ID | <b6d430d4-4a20-48ad-925e-1a530b54e281@googlegroups.com> |
| In reply to | #112055 |
On Saturday, July 30, 2016 at 5:19:25 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Jul 30, 2016 at 9:39 PM, Rustom Mody wrote:
> > On Saturday, July 30, 2016 at 4:56:01 PM UTC+5:30, Chris Angelico wrote:
> >> On Sat, Jul 30, 2016 at 8:15 PM, BartC wrote:
> >> > Anyway, if you're going to talk about annoying things forced upon you by the
> >> > language, what about:
> >> >
> >> > "()" in "print (x)" for Python 3the modulo operator
> >>
> >> Why are you singling out print? It's just a function like any other.
> >> Are you complaining about the way function calls need parentheses?
> >
> > Its a function… ok.
> > Its ‘just’ a function… Arguable
> >
> > For example:
> >
> > - Prior Art: Its builtin and special in Fortran, Pascal, Basic
>
> And it's not built-in or special in C, or a bunch of other languages.
>
> > - More immediate : It was a special in python2
>
> Which resulted in unmitigatable problems, such as that you can't mock
> it for testing or redirection purposes, and it demands syntactic magic
> to do its work - for instance, the only option is a "soft space" in
> place of a newline, where the print function allows full customization
> of both end= and sep=. The print function is DEFINITELY an
> improvement. I would also posit that an sprintf() built-in function
> instead of str.__mod__ would have meant there was less kickback
> against printf-style formatting, because it wouldn't have had the
> strange behaviour around single-argument use. (It's pretty simple to
> write, of course, but built-ins are extremely significant to
> perception. def sprintf(fmt, *args): return fmt % args) Syntax is NOT
> always an improvement.
>
> > - Poorer error catching: What was a straight syntax error is now a lint-catch (at best)
> > [print (x) for x in range(20)]
>
> Huh? Aside from the fact that you're constructing a useless list of
> Nones, what's the error?
Huh²
Are you seriously suggesting that python-3’s behavior below is better IN
THIS INSTANCE than python-2’s?
[That there may be other reasons that outweigh this one for print-as-function
is not something I am disputing. I was solely disputing your ‘just’]
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
>>> [print(x) for x in range(10)]
File "<stdin>", line 1
[print(x) for x in range(10)]
^
SyntaxError: invalid syntax
>>>
Python 3.5.2 (default, Jul 5 2016, 12:43:10)
>>> [print(x) for x in range(10)]
0
1
2
3
4
5
6
7
8
9
[None, None, None, None, None, None, None, None, None, None]
>>>
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 22:22 +1000 |
| Message-ID | <mailman.46.1469881381.6033.python-list@python.org> |
| In reply to | #112057 |
On Sat, Jul 30, 2016 at 10:11 PM, Rustom Mody <rustompmody@gmail.com> wrote: >> > - Poorer error catching: What was a straight syntax error is now a lint-catch (at best) >> > [print (x) for x in range(20)] >> >> Huh? Aside from the fact that you're constructing a useless list of >> Nones, what's the error? > > Huh² > > Are you seriously suggesting that python-3’s behavior below is better IN > THIS INSTANCE than python-2’s? > > [That there may be other reasons that outweigh this one for print-as-function > is not something I am disputing. I was solely disputing your ‘just’] > > Python 2.7.12 (default, Jul 1 2016, 15:12:24) >>>> [print(x) for x in range(10)] > File "<stdin>", line 1 > [print(x) for x in range(10)] > ^ > SyntaxError: invalid syntax >>>> > > Python 3.5.2 (default, Jul 5 2016, 12:43:10) > >>>> [print(x) for x in range(10)] > 0 > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > [None, None, None, None, None, None, None, None, None, None] >>>> I still don't understand your complaint. How is this "better/worse error checking"? All you're showing me is the same line of code you showed above, plus what it does in Py2 and Py3, which I know already. You haven't explained why this is such a great feature in Py2 that got lost in Py3. And hey. If you want to print out the numbers 0 through 9, Py3 offers a pretty concise way to spell that: >>> print(*range(10), sep='\n') 0 1 2 3 4 5 6 7 8 9 >>> Beat that, print statement. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 05:31 -0700 |
| Message-ID | <72e60c1c-801a-4a39-a13f-ba8e25d4e870@googlegroups.com> |
| In reply to | #112058 |
On Saturday, July 30, 2016 at 5:53:12 PM UTC+5:30, Chris Angelico wrote: > On Sat, Jul 30, 2016 at 10:11 PM, Rustom Mody wrote: > >> > - Poorer error catching: What was a straight syntax error is now a lint-catch (at best) > >> > [print (x) for x in range(20)] > >> > >> Huh? Aside from the fact that you're constructing a useless list of > >> Nones, what's the error? > > > > Huh² > > > > Are you seriously suggesting that python-3’s behavior below is better IN > > THIS INSTANCE than python-2’s? > > > > [That there may be other reasons that outweigh this one for print-as-function > > is not something I am disputing. I was solely disputing your ‘just’] > > > > Python 2.7.12 (default, Jul 1 2016, 15:12:24) > >>>> [print(x) for x in range(10)] > > File "<stdin>", line 1 > > [print(x) for x in range(10)] > > ^ > > SyntaxError: invalid syntax > >>>> > > > > Python 3.5.2 (default, Jul 5 2016, 12:43:10) > > > >>>> [print(x) for x in range(10)] > > 0 > > 1 > > 2 > > 3 > > 4 > > 5 > > 6 > > 7 > > 8 > > 9 > > [None, None, None, None, None, None, None, None, None, None] > >>>> > > I still don't understand your complaint. How is this "better/worse > error checking"? All you're showing me is the same line of code you > showed above, plus what it does in Py2 and Py3, which I know already. > You haven't explained why this is such a great feature in Py2 that got > lost in Py3. > > And hey. If you want to print out the numbers 0 through 9, Py3 offers > a pretty concise way to spell that: > > >>> print(*range(10), sep='\n') Heh Cute! Thanks!! > 0 > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 > >>> > > Beat that, print statement. What makes you think I wanted to print those numbers?? Maybe I wanted a list of 10 None-s?? Point being that when one mixes up 2 things like that its anybody’s guess which is the primary (central) effect and which the ‘side’ effect
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 22:44 +1000 |
| Message-ID | <mailman.49.1469882708.6033.python-list@python.org> |
| In reply to | #112060 |
On Sat, Jul 30, 2016 at 10:31 PM, Rustom Mody <rustompmody@gmail.com> wrote: > What makes you think I wanted to print those numbers?? > Maybe I wanted a list of 10 None-s?? Because you NEVER SAID what you wanted! How can you talk about error detection if you won't say what the programmer's intention was? You're forcing us to guess, and then complaining that I guessed wrongly. > Point being that when one mixes up 2 things like that its anybody’s guess > which is the primary (central) effect and which the ‘side’ effect Okay, so my revised guess is: Console output is a primary effect and should not have a secondary effect of returning None. Great. Now please go and build yourself a language in which list.append is a statement (because it shouldn't return None either), etc, etc, just in case someone uses them wrongly. I'll keep using Python, where it's normal for a side-effect-y function to return None - it's much simpler. And even in Pike, where void functions are a real thing, it's possible to recast the function so you can call it in an expression context - and the same thing happens. Truly void functions are nothing but parser convenience. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 01:07 +1000 |
| Message-ID | <579cc2b1$0$1611$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112060 |
On Sat, 30 Jul 2016 10:31 pm, Rustom Mody wrote: > What makes you think I wanted to print those numbers?? The fact that you called print. > Maybe I wanted a list of 10 None-s?? The idiomatic Python way of doing it would be: [None]*10 The beginner's way of doing it would be: [None, None, None, None, None, None, None, None, None, None] The premature optimizer would do the same as the beginner. Somebody who thinks of list comprehensions as the only hammer in their toolbox would write: [None for i in range(10)] Confused Lisp programmers would write: list(map(lambda ignore_me: None, range(10))) But the idea that somebody might call print(i), and put up with its HIGHLY VISIBLE side-effects, just for the return result of None, instead of just writing None, is too implausible to take seriously. If I saw such code, I'd immediately submit it to The Daily WTF. -- Steven “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-07-30 13:39 +0100 |
| Message-ID | <nni76u$qo8$1@dont-email.me> |
| In reply to | #112058 |
On 30/07/2016 13:22, Chris Angelico wrote: >>>> print(*range(10), sep='\n') > 0 > 1 > 2 > 3 > 4 > 5 > 6 > 7 > 8 > 9 >>>> > > Beat that, print statement. for i in range(10): print i Same number of characters, but a lot less punctuation! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 22:47 +1000 |
| Message-ID | <mailman.50.1469882843.6033.python-list@python.org> |
| In reply to | #112062 |
On Sat, Jul 30, 2016 at 10:39 PM, BartC <bc@freeuk.com> wrote: > On 30/07/2016 13:22, Chris Angelico wrote: > >>>>> print(*range(10), sep='\n') >> >> 0 >> 1 >> 2 >> 3 >> 4 >> 5 >> 6 >> 7 >> 8 >> 9 >>>>> >>>>> >> >> Beat that, print statement. > > > for i in range(10): print i > > Same number of characters, but a lot less punctuation! So, no improvement - exactly equal. And no longer a single expression, ergo no longer valid in as many contexts. (Also, it requires the use and damage of some iterator variable, which may be significant in some contexts.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 22:47 +1000 |
| Message-ID | <mailman.51.1469882872.6033.python-list@python.org> |
| In reply to | #112062 |
On Sat, Jul 30, 2016 at 10:47 PM, Chris Angelico <rosuav@gmail.com> wrote: > So, no improvement - exactly equal. And no longer a single expression, > ergo no longer valid in as many contexts. (Also, it requires the use > and damage of some iterator variable, which may be significant in some > contexts.) In case it's not clear: </tongue_in_cheek> ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 13:27 +0100 |
| Message-ID | <nni6f6$odh$1@dont-email.me> |
| In reply to | #112055 |
On 30/07/2016 12:49, Chris Angelico wrote: > On Sat, Jul 30, 2016 at 9:39 PM, Rustom Mody <rustompmody@gmail.com> wrote: >> Its a function… ok. >> Its ‘just’ a function… Arguable >> >> For example: >> >> - Prior Art: Its builtin and special in Fortran, Pascal, Basic > > And it's not built-in or special in C, or a bunch of other languages. The parentheses are a nuisance in C too, as are obligatory format codes. And C created a lot of bad precedences (literally in the case of binary operators!) For an informal, rapid development language, the less formality about these things the better. >> - More immediate : It was a special in python2 > > Which resulted in unmitigatable problems, such as that you can't mock > it for testing or redirection purposes, The language finds other solutions so that programs using "print A" don't need changing. Perhaps 'print <list>' is syntactic sugar for '_print (<list>' or something. and it demands syntactic magic > to do its work - for instance, the only option is a "soft space" in > place of a newline, where the print function allows full customization > of both end= and sep=. This is one thing I can never get right in Python: controlling when a newline is or isn't generated and what happens with separators. (In fact when I used Python as a target language, I had to generate calls to sys.stdout.write instead as it had more predictable behaviour.) So if it's the advantage of using () then it's one I never benefit from! Newline control should be one of the simplest things in the language, part of the very first programs you write. (Some languages use 'write' or 'writeln', or 'print' or 'println'; what could be simpler? Or you just explicitly output a "\n" string.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-30 22:34 +1000 |
| Message-ID | <mailman.48.1469882068.6033.python-list@python.org> |
| In reply to | #112059 |
On Sat, Jul 30, 2016 at 10:27 PM, BartC <bc@freeuk.com> wrote: >> where the print function allows full customization >> of both end= and sep=. > > > This is one thing I can never get right in Python: controlling when a > newline is or isn't generated and what happens with separators. > > (In fact when I used Python as a target language, I had to generate calls to > sys.stdout.write instead as it had more predictable behaviour.) > > So if it's the advantage of using () then it's one I never benefit from! > > Newline control should be one of the simplest things in the language, part > of the very first programs you write. > > (Some languages use 'write' or 'writeln', or 'print' or 'println'; what > could be simpler? Or you just explicitly output a "\n" string.) Here, look: print(obj) # with newline print(obj, end="") # without newline Easy, isn't it? Start playing to the language's strengths instead of fighting against them. Keyword arguments are a Python feature that I frequently yearn for in other languages. Use them! ChrisA
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web