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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-07-31 10:32 -0700 |
| Message-ID | <87h9b57lxe.fsf@jester.gateway.pace.com> |
| In reply to | #112146 |
Steven D'Aprano <steve@pearwood.info> writes: > There's a real mystery why concatenative/postfix languages have > received so little attention from the academic community compared to > prefix languages. There's a wiki with lots of info: http://www.concatenative.org This LTU thread and the article it links to is kind of interesting: http://lambda-the-ultimate.org/node/4448
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 02:37 +1000 |
| Message-ID | <mailman.56.1469896666.6033.python-list@python.org> |
| In reply to | #112083 |
On Sun, Jul 31, 2016 at 2:15 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Diff between
> print "x"
> and
> print("x")
> is one char — the closing ‘)’
>
> To make a dispute about that — I’ll leave to BartC!
>
> The more general baby that is significant is that beginners should have
> it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being
> absent is a much more significant problem (for beginners) than print.
But Py2's print is not just a procedure. It's magical syntax. You
can't create your own procedures.
Why SHOULD they be special? Ultimately, a procedure is simply a
function that has no useful return value; and there are myriad times
when I've called a function or method for its side effects and ignored
the return value. So do I need to be able to "call a function as if it
were a procedure", or is there a stark difference between the two
types of callable?
Where, in any useful production code, is the difference between
functions and procedures actually helpful? Or where, in student code,
would it be useful to distinguish? I've been teaching Python to
students with a variety of backgrounds, and nobody has yet been
bothered by this. Not a single one.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 09:58 -0700 |
| Message-ID | <aae6cba4-65cb-4bcb-a55c-a19f722cc060@googlegroups.com> |
| In reply to | #112088 |
On Saturday, July 30, 2016 at 10:07:59 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Jul 31, 2016 at 2:15 AM, Rustom Mody wrote:
> > Diff between
> > print "x"
> > and
> > print("x")
> > is one char — the closing ‘)’
> >
> > To make a dispute about that — I’ll leave to BartC!
> >
> > The more general baby that is significant is that beginners should have
> > it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being
> > absent is a much more significant problem (for beginners) than print.
>
> But Py2's print is not just a procedure. It's magical syntax. You
> can't create your own procedures.
>
> Why SHOULD they be special? Ultimately, a procedure is simply a
> function that has no useful return value; and there are myriad times
> when I've called a function or method for its side effects and ignored
> the return value. So do I need to be able to "call a function as if it
> were a procedure", or is there a stark difference between the two
> types of callable?
>
> Where, in any useful production code, is the difference between
> functions and procedures actually helpful? Or where, in student code,
> would it be useful to distinguish? I've been teaching Python to
> students with a variety of backgrounds, and nobody has yet been
> bothered by this. Not a single one.
>
> ChrisA
In English — and all Indo-European¹ languages — there are two moods
“It is raining” is in declarative mood
“Come in!” is in imperative mood
Now there is a realm in which they are not distinct
“It is raining!” said Harry Potter to Hermione and it started raining
“Come in!” said Harry, And the chair walked hoppety-hop into the room
So sure if you want to teach magic to your kids, all power to you.
Myself, I’ll stick to what I know better than magic — programming
¹ Benjamin Lee Whorf pointed out that fundamental categories — in this example,
imperative and declarative moods — determine the form of thinking of the
people/race that use that language.
In particular the native American language Hopi, is not so ruined with
time-as-space metaphors. And therefore ‘advanced’ ideas like quantum physics
turn out not so advanced in Hopi [I am told]
But this is all way too far afield
Pragmatically not distinguishing imperative and declarative — or ‘do’ vs ‘is’
— is unrealistic
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 03:15 +1000 |
| Message-ID | <mailman.58.1469898910.6033.python-list@python.org> |
| In reply to | #112090 |
On Sun, Jul 31, 2016 at 2:58 AM, Rustom Mody <rustompmody@gmail.com> wrote: >> Where, in any useful production code, is the difference between >> functions and procedures actually helpful? Or where, in student code, >> would it be useful to distinguish? I've been teaching Python to >> students with a variety of backgrounds, and nobody has yet been >> bothered by this. Not a single one. >> >> ChrisA > > In English — and all Indo-European¹ languages — there are two moods > “It is raining” is in declarative mood > “Come in!” is in imperative mood > > Now there is a realm in which they are not distinct > > “It is raining!” said Harry Potter to Hermione and it started raining > “Come in!” said Harry, And the chair walked hoppety-hop into the room > > So sure if you want to teach magic to your kids, all power to you. > Myself, I’ll stick to what I know better than magic — programming Answer the question, maybe... when *in programming* is this distinction important? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 10:48 -0700 |
| Message-ID | <ba2144ae-3969-4c30-85bd-32942d28e371@googlegroups.com> |
| In reply to | #112092 |
On Saturday, July 30, 2016 at 10:45:23 PM UTC+5:30, Chris Angelico wrote: > On Sun, Jul 31, 2016 at 2:58 AM, Rustom Mody wrote: > >> Where, in any useful production code, is the difference between > >> functions and procedures actually helpful? Or where, in student code, > >> would it be useful to distinguish? I've been teaching Python to > >> students with a variety of backgrounds, and nobody has yet been > >> bothered by this. Not a single one. > >> > >> ChrisA > > > > In English — and all Indo-European¹ languages — there are two moods > > “It is raining” is in declarative mood > > “Come in!” is in imperative mood > > > > Now there is a realm in which they are not distinct > > > > “It is raining!” said Harry Potter to Hermione and it started raining > > “Come in!” said Harry, And the chair walked hoppety-hop into the room > > > > So sure if you want to teach magic to your kids, all power to you. > > Myself, I’ll stick to what I know better than magic — programming > > Answer the question, maybe... when *in programming* is this > distinction important? eg 1 We can write am assignment in a loop Can we write a loop in an assignment like? x = while x ... Less interesting answer — No we cannot More pertinent — In our zany new language we are inventing we are going to allow this. Ok... What will it mean? eg 2 A function can - return a constant - a variable - more generally an expression How about returning a while loop? In short you use the imperative-declarative distinction every day all the time every line of code that you write. Some languages reify that as an expression/statement function/procedure division — Pascal. But even if your language does not support that reification you would not be able to write a single line of correct code without it. Broadly (and simplistically): - When you ask a question — condition of if or while — you need a declarative entity - When you do an action — assignment, body of if/loop — you need an imperative entity
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-07-31 13:45 +1200 |
| Message-ID | <e053i3F9kf6U1@mid.individual.net> |
| In reply to | #112088 |
Chris Angelico wrote: > So do I need to be able to "call a function as if it > were a procedure", or is there a stark difference between the two > types of callable? Well, Pascal makes a stark distinction between them -- it's a compile-time error to call a procedure as though it were a function or vice versa in Pascal -- and it didn't seem to cause any great problems. So it's at least possible to write useful code under such circumstances, and it might even help to catch certain classes of errors. But the ability to ignore return values can be useful as well. Most languages since have decided not to make the distinction, and don't seem to have suffered noticeably as a result. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 12:17 +1000 |
| Message-ID | <mailman.62.1469931427.6033.python-list@python.org> |
| In reply to | #112105 |
On Sun, Jul 31, 2016 at 11:45 AM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> So do I need to be able to "call a function as if it >> were a procedure", or is there a stark difference between the two >> types of callable? > > > Well, Pascal makes a stark distinction between them -- it's > a compile-time error to call a procedure as though it were > a function or vice versa in Pascal -- and it didn't seem to > cause any great problems. > > So it's at least possible to write useful code under such > circumstances, and it might even help to catch certain > classes of errors. But the ability to ignore return values > can be useful as well. Most languages since have decided > not to make the distinction, and don't seem to have > suffered noticeably as a result. Yeah. The distinction means you have a fundamental API difference between the procedures (which don't return anything) and the functions (whose return values you mightn't care about). It means you can't upgrade something from "always returns None" to "returns the number of objects frobbed" without breaking compat. Conversely, if you decide that any function can be called "as a procedure" (this is what REXX does, for instance), then you've just merged the two types of callable and distinguished them only in usage. Personally, I don't see any value to the distinction at all. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 13:32 +1000 |
| Subject | Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <579d7141$0$1606$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112107 |
On Sun, 31 Jul 2016 12:17 pm, Chris Angelico wrote: > Yeah. The distinction means you have a fundamental API difference > between the procedures (which don't return anything) and the functions > (whose return values you mightn't care about). Correct. > It means you can't > upgrade something from "always returns None" to "returns the number of > objects frobbed" without breaking compat. You shouldn't ever need to. At least that's the theory. In practice its not quite cut and dried. Procedures are for things which purely operate by side-effect: they're verbs, doing words: sleep print run mangle append delete Functions, on the other hand, are transformations. Functions should never have side-effects, they should take at least one argument and return a new value. length of ... cosine of ... the date of [this instant] That's a fairly important conceptual difference, although as I acknowledge in practice there's more overlap than one might like. > Conversely, if you decide > that any function can be called "as a procedure" (this is what REXX > does, for instance), then you've just merged the two types of callable > and distinguished them only in usage. > > Personally, I don't see any value to the distinction at all. Oh, there's definitely value. I'm just not sure whether the value is worth the cost of making the distinction. Many beginners make the mistake of writing: mylist = mylist.sort() or try to write: mylist.sort().reverse() If we had procedures, that would be an obvious error (possibly even a compile-time syntax error) instead of a perplexing source of mystery bugs. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | "D'Arcy J.M. Cain" <darcy@Vex.Net> |
|---|---|
| Date | 2016-07-31 00:01 -0400 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <mailman.65.1469937703.6033.python-list@python.org> |
| In reply to | #112113 |
On Sun, 31 Jul 2016 13:32:16 +1000 Steven D'Aprano <steve@pearwood.info> wrote: > Many beginners make the mistake of writing: > > mylist = mylist.sort() > > or try to write: > > mylist.sort().reverse() > > If we had procedures, that would be an obvious error (possibly even a > compile-time syntax error) instead of a perplexing source of mystery > bugs. While neither is a syntax error, the latter is definitely a run-time error: >>> mylist.sort().reverse() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'NoneType' object has no attribute 'reverse' -- 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 | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-07-31 16:40 +1000 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <579d9d53$0$1619$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #112117 |
On Sun, 31 Jul 2016 02:01 pm, D'Arcy J.M. Cain wrote: > On Sun, 31 Jul 2016 13:32:16 +1000 > Steven D'Aprano <steve@pearwood.info> wrote: >> Many beginners make the mistake of writing: >> >> mylist = mylist.sort() >> >> or try to write: >> >> mylist.sort().reverse() >> >> If we had procedures, that would be an obvious error (possibly even a >> compile-time syntax error) instead of a perplexing source of mystery >> bugs. > > While neither is a syntax error, the latter is definitely a run-time > error: > >>>> mylist.sort().reverse() > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: 'NoneType' object has no attribute 'reverse' Hence my description of it as a perplexing source of mystery bugs. How did mylist suddenly turn into None? Well, it didn't, but it sure looks like it did, for those who didn't realise that sort() is intended to be used *as if* it were a procedure with no return value. If it *actually* had no return value, Python could give a more useful error message: ProcedureError: list.sort() has no return value as soon as the interpreter tries to push the non-existent return value onto the stack. Python can't do that, because None is an ordinary object line any other. There's no practical way for Python to distinguish (whether at compile-time or run-time) None as an ordinary object from None as a stand-in for "no object at all". In practice, for moderately experienced programmers, the difference is minor and most people quickly learn how to debug "None object has no attribute" exceptions. But for a teaching language where we want to be stricter about the dichotomy of: - subroutines that transform values (functions); and - subroutines with side-effects (procedures) its a little sub-optimal. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-07-30 23:47 -0700 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <30bd7bd9-2184-4fb3-8387-e4bf0e3e6e28@googlegroups.com> |
| In reply to | #112124 |
On Sunday, July 31, 2016 at 12:10:33 PM UTC+5:30, Steven D'Aprano wrote: > On Sun, 31 Jul 2016 02:01 pm, D'Arcy J.M. Cain wrote: > > > On Sun, 31 Jul 2016 13:32:16 +1000 > > Steven D'Aprano wrote: > >> Many beginners make the mistake of writing: > >> > >> mylist = mylist.sort() > >> > >> or try to write: > >> > >> mylist.sort().reverse() > >> > >> If we had procedures, that would be an obvious error (possibly even a > >> compile-time syntax error) instead of a perplexing source of mystery > >> bugs. > > > > While neither is a syntax error, the latter is definitely a run-time > > error: > > > >>>> mylist.sort().reverse() > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > AttributeError: 'NoneType' object has no attribute 'reverse' > > Hence my description of it as a perplexing source of mystery bugs. How did > mylist suddenly turn into None? > > Well, it didn't, but it sure looks like it did, for those who didn't realise > that sort() is intended to be used *as if* it were a procedure with no > return value. If it *actually* had no return value, Python could give a > more useful error message: > > ProcedureError: list.sort() has no return value > > as soon as the interpreter tries to push the non-existent return value onto > the stack. Python can't do that, because None is an ordinary object line > any other. There's no practical way for Python to distinguish (whether at > compile-time or run-time) None as an ordinary object from None as a > stand-in for "no object at all". > > In practice, for moderately experienced programmers, the difference is minor > and most people quickly learn how to debug "None object has no attribute" > exceptions. But for a teaching language where we want to be stricter about > the dichotomy of: > > - subroutines that transform values (functions); and > - subroutines with side-effects (procedures) > > its a little sub-optimal. That’s a nice summary of my position — tnx. Not that python as a production language with a fundamentally dynamic DNA needs to change. Rather that beginners not having procedure←→function as abstractions of effect←→value are subjected to a more than necessarily arduous learning curve
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 16:55 +1000 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <mailman.71.1469948112.6033.python-list@python.org> |
| In reply to | #112124 |
On Sun, Jul 31, 2016 at 4:40 PM, Steven D'Aprano <steve@pearwood.info> wrote: >> While neither is a syntax error, the latter is definitely a run-time >> error: >> >>>>> mylist.sort().reverse() >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> AttributeError: 'NoneType' object has no attribute 'reverse' > > Hence my description of it as a perplexing source of mystery bugs. How did > mylist suddenly turn into None? > > Well, it didn't, but it sure looks like it did, for those who didn't realise > that sort() is intended to be used *as if* it were a procedure with no > return value. If it *actually* had no return value, Python could give a > more useful error message: > > ProcedureError: list.sort() has no return value Fortunately, a linter can pick this up (maybe even right in your editor, before you move off the line of code). Particularly if type hints are available, a linter can say "Hey, this function always returns None, and you're assigning it to something - that looks wrong". ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 14:05 +1000 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <mailman.66.1469937961.6033.python-list@python.org> |
| In reply to | #112113 |
On Sun, Jul 31, 2016 at 1:32 PM, Steven D'Aprano <steve@pearwood.info> wrote: >> It means you can't >> upgrade something from "always returns None" to "returns the number of >> objects frobbed" without breaking compat. > > You shouldn't ever need to. At least that's the theory. In practice its not > quite cut and dried. Procedures are for things which purely operate by > side-effect: they're verbs, doing words: That's all very well in theory, but as you say, it's far from cut and dried. Taking the example that started all this off, Python 2 had 'print' as a statement (no return value), but the write method of I/O streams (eg sys.stdout.write) has a definite and important return value (the amount written). As another example, the 'gc' module allows you to trigger garbage collection immediately. (All examples from CPython. I don't know how other Pythons handle things, but the specifics don't matter anyway.) That's very definitely a verb - "go and take out the trash, now" - but it's a function that returns the number of unreachable objects. More or less the same concept as write(), in that it does some work and then returns how much work it did. So while I agree with Python's decision to make list.sort() return None rather than the mutated list, I think there's not a dichotomy here but a spectrum, from "procedure-like" to "function-like". At the one extreme are control flow statements - it doesn't make any sense whatsoever to ask about the return value of a "while" statement. (Though you could define it as the value of the condition expression, but that's something you want _inside_ the while block, not outside.) Then you have things that Python has as statements, but which plausibly could have return values, eg "def" and "class" could return the function/class. Somewhere toward the middle are gc.collect() and friends, where you mainly call them for their functionality, not their return values. Leaning toward functional are the mutators-with-return-values like list.pop() - there are times when you don't care about the element, you just want to pop and discard. And then the most functional of functions would be pure functions like math.sin(), where they have no side effects whatsoever, just a return value. Which ones would you define as procedures and which as functions? Or can you just define _everything_ as a function, and give them valid, if meaningless, return values? Yeah. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-31 00:26 -0400 |
| Subject | Re: Procedures and functions [was Re: Why not allow empty code blocks?] |
| Message-ID | <mailman.70.1469939179.6033.python-list@python.org> |
| In reply to | #112113 |
On Sun, Jul 31, 2016, at 00:01, D'Arcy J.M. Cain wrote: > On Sun, 31 Jul 2016 13:32:16 +1000 > Steven D'Aprano <steve@pearwood.info> wrote: > > Many beginners make the mistake of writing: > > > > mylist = mylist.sort() > > > > or try to write: > > > > mylist.sort().reverse() > > > > If we had procedures, that would be an obvious error (possibly even a > > compile-time syntax error) instead of a perplexing source of mystery > > bugs. > > While neither is a syntax error, the latter is definitely a run-time > error: The only way to make it a syntax error would be to have a different syntax for *calling* procedures. Barring that, all you can do is make the first one a run-time error. As Python is a dynamic language, mylist.sort is an object which is resolved at runtime. When you call this object, its __call__ method is called and returns the None object. This object is valid for very few operations (it can be assigned to a variable [or returned], treated as a boolean, compared for equality, or converted to a string). In some other languages, procedures have a static return type (often called "void") which is valid for even fewer operations. You can use it as a statement expression or within certain contexts (the left side of C's comma operator, for example) where the value of an expression is always discarded. In a hypothetical Python with procedures but no separate syntax for calling them, you would need to define the __call__ protocol in a way that it can indicate that the called object is a procedure. Though, it could probably be handled at the python level by just allowing "return" or running off the end to do this, requiring "return None" for the explicit return of a None object.. The real cost is, it would require that any operation (such as assigning as a variable, checking it as a boolean, etc) other than discarding it (including returning it, so you'd need extra bytecode to check rather than merely leaving tail returns on the stack) check immediately raise an error. This would add extra processing to nearly all call sites.
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-07-30 23:51 -0400 |
| Message-ID | <mailman.64.1469937095.6033.python-list@python.org> |
| In reply to | #112105 |
On Sat, Jul 30, 2016, at 22:17, Chris Angelico wrote: > Yeah. The distinction means you have a fundamental API difference > between the procedures (which don't return anything) and the functions > (whose return values you mightn't care about). Not really any more than between functions returning different types - which python doesn't distinguish in general. That some languages may spell it with a different keyword rather than a special type [such as C's void] doesn't mean the fundamental API difference is of a different kind. > It means you can't > upgrade something from "always returns None" to "returns the number of > objects frobbed" without breaking compat. Well, that's something you can't do in general in statically typed languages. (Once upon a time, C had a default return type of int, and allowed functions returning it to fall off the end or have a "return;" statement, but not anymore). This is ultimately just the static typing argument in miniature, confused by the fact that some languages declare them with a different syntax from other functions. > Conversely, if you decide > that any function can be called "as a procedure" (this is what REXX > does, for instance), then you've just merged the two types of callable > and distinguished them only in usage. > > Personally, I don't see any value to the distinction at all. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-07-31 14:21 +1000 |
| Message-ID | <mailman.69.1469938879.6033.python-list@python.org> |
| In reply to | #112105 |
On Sun, Jul 31, 2016 at 1:51 PM, Random832 <random832@fastmail.com> wrote: > On Sat, Jul 30, 2016, at 22:17, Chris Angelico wrote: >> Yeah. The distinction means you have a fundamental API difference >> between the procedures (which don't return anything) and the functions >> (whose return values you mightn't care about). > > Not really any more than between functions returning different types - > which python doesn't distinguish in general. That some languages may > spell it with a different keyword rather than a special type [such as > C's void] doesn't mean the fundamental API difference is of a different > kind. In C, you can treat any function as a procedure by simply ignoring its return value, as in Python. So all functions, whether they return int or float or void, are functions - there's no fundamental difference. What I'm talking about is having two types of callables: a = function(x, y) call procedure x, y REXX has this distinction at the call site (because of other API considerations regarding loose expressions), but it's not fundamental; the second form will ignore any return value, ergo a procedure can be upgraded to a function without breaking anything. Python has no distinction whatsoever, requiring all functions to return *something*, even if it's None. Pike has a concept of void functions, but deep in the internals, they just return zero, so if you mess with the type checker and get around the compile-time checks, you'll get zero back. C... I dunno for sure, and it probably depends on the compiler, but I just tried it on my gcc, and it looks like it basically takes whatever happened to be sitting in the accumulator. In all cases, anyone who wasn't expecting a return value will be fine with a version of the function that returns something. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-30 21:22 +0100 |
| Message-ID | <nnj2ap$o80$1@dont-email.me> |
| In reply to | #112083 |
On 30/07/2016 17:15, Rustom Mody wrote:
> On Saturday, July 30, 2016 at 8:17:19 PM UTC+5:30, Steven D'Aprano wrote:
>> On Sat, 30 Jul 2016 09: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 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
>>
>> "Granny Weatherwax, you are a natural-born disputant."
>> "I ain't!"
>
> Heh I really aint :D
> At least not for this dispute — its not my baby
> Or rather its a stepbaby of stepbaby
>
> Diff between
> print "x"
> and
> print("x")
> is one char — the closing ‘)’
>
> To make a dispute about that — I’ll leave to BartC!
I'll try to oblige...
The difference between the space and "(" is significant to those who
can't type! (Or have some difficulty in using a keyboard for any reason.
Or are trying to eat lunch at the same time.)
A space bar is nice and fat, and doesn't need shifting.
Yes you have to make the effort in most code to type shifted
punctuation, but there it's worth doing. With 'print', you might be
adding and removing such statements hundreds of times so that extra
effort is wasted.
(The situation is worse in C however, where, if you want to even
temporarily print out two labelled values, it's:
printf("A= %d, B= %d\n", a, b);
for something that might have a half-life of 20 seconds (it might take
longer to type it out!). In Python 3 it would be:
print ("A=", a, "B=", b)
so it's much nicer even with parentheses. So the point I'm making is
minor. On the other hand, elsewhere I normally type:
cpl =a, =b
('cpl' is an alias for 'println'. The '=' operator is a gimmick which
automatically produces a label prefix, so this is equivalent to:
println "A=", a, "B=", b
))
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-08-02 12:30 +0200 |
| Message-ID | <mailman.110.1470133871.6033.python-list@python.org> |
| In reply to | #112083 |
Op 30-07-16 om 18:15 schreef Rustom Mody: > > The more general baby that is significant is that beginners should have > it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being > absent is a much more significant problem (for beginners) than print. > > ... > > Ok Python is better than Java is better than C++ > But it cannot stand up to scheme as a teaching language > [The MIT Profs who replaced scheme by python admit to as much viz. But AFAIK scheme doesn't aid in distinguishing procedure from function either. -- Antoon.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-08-02 05:29 -0700 |
| Message-ID | <f66a1b3d-cb55-48e3-9a34-c236c84407a1@googlegroups.com> |
| In reply to | #112213 |
On Tuesday, August 2, 2016 at 4:01:25 PM UTC+5:30, Antoon Pardon wrote:
> Op 30-07-16 om 18:15 schreef Rustom Mody:
> >
> > The more general baby that is significant is that beginners should have
> > it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being
> > absent is a much more significant problem (for beginners) than print.
> >
> > ...
> >
> > Ok Python is better than Java is better than C++
> > But it cannot stand up to scheme as a teaching language
> > [The MIT Profs who replaced scheme by python admit to as much viz.
>
> But AFAIK scheme doesn't aid in distinguishing procedure from function either.
True. And my words above seem to say that. However let me restore some more context:
On Saturday, July 30, 2016 at 9:45:34 PM UTC+5:30, Rustom Mody wrote:
> On Saturday, July 30, 2016 at 8:17:19 PM UTC+5:30, Steven D'Aprano wrote:
<snipped>
> > On Sat, 30 Jul 2016 09:39 pm, Rustom Mody wrote:
> > > Its a function… ok.
> > > Its ‘just’ a function… Arguable
> >
> > "Granny Weatherwax, you are a natural-born disputant."
> > "I ain't!"
>
> Heh I really aint :D
> At least not for this dispute — its not my baby
> Or rather its a stepbaby of stepbaby
>
> Diff between
> print "x"
> and
> print("x")
> is one char — the closing ‘)’
>
> To make a dispute about that — I’ll leave to BartC!
>
> The more general baby that is significant is that beginners should have
> it easy to distinguish procedure and function and python does not naturally aid that. print was something procedure-ish in python2 but the general notion being
> absent is a much more significant problem (for beginners) than print.
>
> Brings me to the even more general baby
<snipped>
> But I studied in the 80s and there was greater clarity (about some matters
> of course) than now.
> eg It was completely natural that in ‘school’ one studied
> ‘nice’ things like Pascal, Lisp, Prolog, Snobol, APL etc
> And in a professional context used ‘real’ things like
> Fortran, Cobol, PL-1 and a little later C.
>
> Once omnibus languages like C++, Java, C# and Python became popular
> the academic vs real-world division has disappeared.
> So beginners start with these ‘real-world’
> And get their brains scrambled
> And think it wonderful
>
> Ok Python is better than Java is better than C++
> But it cannot stand up to scheme as a teaching language
> [The MIT Profs who replaced scheme by python admit to as much viz.
<wrong send pressed>
> MIT on practical reasons for python over scheme:
> https://www.wisdomandwonder.com/link/2110/why-mit-switched-from-scheme-to-python
> Berkeley on fundamental reasons for the opposite choice:
> https://people.eecs.berkeley.edu/~bh/proglang.html
So I was talking of 3 very different levels:
1. print x vs print(x)
— a difference too petty for me to waste my time with
2. Procedure vs Function as something very necessary for beginner
thinking-ontology which Pascal gets right
3. The fact that the gap between a mainly-for-teaching language and a serious
software-engineering-real-world language is not closable
And that saying that the same language could be used for both purposes is
like arguing that both these delightful ladies are pianists:
Martha: https://www.youtube.com/watch?v=YLZLp6AcAi4
Rose : https://www.youtube.com/watch?v=_bjKDJD-CLc
Scheme and Pascal happen to be two well-known well-crafted but quite different
for-teaching languages
[toc] | [prev] | [next] | [standalone]
| From | Antoon Pardon <antoon.pardon@rece.vub.ac.be> |
|---|---|
| Date | 2016-08-03 10:26 +0200 |
| Message-ID | <mailman.133.1470212850.6033.python-list@python.org> |
| In reply to | #112217 |
Op 02-08-16 om 14:29 schreef Rustom Mody: > So I was talking of 3 very different levels: > > 1. print x vs print(x) > — a difference too petty for me to waste my time with > > 2. Procedure vs Function as something very necessary for beginner > thinking-ontology which Pascal gets right > > 3. The fact that the gap between a mainly-for-teaching language and a serious > software-engineering-real-world language is not closable > And that saying that the same language could be used for both purposes is > like arguing that both these delightful ladies are pianists: > > > Martha: https://www.youtube.com/watch?v=YLZLp6AcAi4 > Rose : https://www.youtube.com/watch?v=_bjKDJD-CLc > > > Scheme and Pascal happen to be two well-known well-crafted but quite different > for-teaching languages But on what ground is scheme a well-crafted for-teaching language? It is not because it gets the Procedure vs Function ontology right. As far as I know scheme has about the same data structures as python, they are just called differently and there are some limitations. So when putting scheme and python next to each other we should choose scheme for teaching and python for production. -- Antoon Pardon
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.python
csiph-web