Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #108830 > unrolled thread
| Started by | Herkermer Sherwood <theherk@gmail.com> |
|---|---|
| First post | 2016-05-19 09:31 -0700 |
| Last post | 2016-06-16 11:19 +1000 |
| Articles | 20 on this page of 282 — 43 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
for / while else doesn't make sense Herkermer Sherwood <theherk@gmail.com> - 2016-05-19 09:31 -0700
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-05-19 10:22 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-20 04:02 +1000
Re: for / while else doesn't make sense theherk@gmail.com - 2016-05-19 11:47 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-19 23:28 +0300
Re: for / while else doesn't make sense David Jardine <david@jardine.de> - 2016-05-19 21:49 +0200
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-20 03:46 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-19 17:55 +0000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-20 10:06 +1000
Re: for / while else doesn't make sense gst <g.starck@gmail.com> - 2016-05-19 19:02 -0700
Re: for / while else doesn't make sense Stephen Hansen <me+python@ixokai.io> - 2016-05-19 23:53 -0700
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-20 11:55 +0000
Re: for / while else doesn't make sense Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-05-20 19:57 -0400
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 21:26 +1000
Re: for / while else doesn't make sense Ethan Furman <ethan@stoneleaf.us> - 2016-05-20 16:58 -0700
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-21 00:24 +0000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 13:50 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 14:01 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 19:56 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 20:08 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 20:55 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 21:10 +1000
Re: for / while else doesn't make sense Erik <python@lucidity.plus.com> - 2016-05-21 08:20 +0100
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-21 11:37 +0300
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 20:39 +1000
Re: for / while else doesn't make sense Erik <python@lucidity.plus.com> - 2016-05-21 21:48 +0100
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-22 12:57 +1000
Re: for / while else doesn't make sense Michael Selik <michael.selik@gmail.com> - 2016-05-22 02:55 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 17:29 +1000
Re: for / while else doesn't make sense Bob Martin <bob.martin@excite.com> - 2016-05-20 07:45 +0100
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-20 06:01 +1000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-19 14:11 -0600
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-20 06:27 +1000
Re: for / while else doesn't make sense Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-20 11:51 +1200
Re: for / while else doesn't make sense Erik <python@lucidity.plus.com> - 2016-05-20 09:09 +0100
Re: for / while else doesn't make sense Zachary Ware <zachary.ware+pylist@gmail.com> - 2016-05-20 10:59 -0500
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-20 12:20 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 08:43 +1000
Re: for / while else doesn't make sense theherk@gmail.com - 2016-05-20 16:24 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-21 09:03 +0300
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-21 21:26 +1000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-21 07:51 -0600
Re: for / while else doesn't make sense Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-21 15:20 +0000
Re: for / while else doesn't make sense Ben Finney <ben+python@benfinney.id.au> - 2016-05-21 10:21 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-21 00:35 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 12:05 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 14:15 +0000
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-22 17:58 +0300
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 15:09 +0000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-22 08:26 -0700
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-22 13:25 -0400
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-22 10:34 -0700
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 18:06 +0000
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-22 14:17 -0400
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-23 17:09 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-23 01:19 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-23 01:32 +1000
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-22 18:50 +0300
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 15:52 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-23 02:35 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 16:46 +0000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-22 10:22 -0700
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-22 13:30 -0400
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-22 17:55 +0000
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-22 14:14 -0400
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-22 20:51 +0100
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 00:34 +0000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-22 17:04 -0600
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-23 08:09 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 00:36 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-23 11:01 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 01:00 +0000
Re: for / while else doesn't make sense breamoreboy@gmail.com - 2016-05-22 18:47 -0700
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 15:35 +0000
Re: for / while else doesn't make sense MRAB <python@mrabarnett.plus.com> - 2016-05-23 02:51 +0100
Re: for / while else doesn't make sense Ben Finney <ben+python@benfinney.id.au> - 2016-05-23 14:13 +1000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-22 23:09 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-23 09:30 +0300
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-22 23:46 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-23 18:09 +1000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 08:14 -0600
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-23 15:29 +0100
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 08:49 -0600
Re: for / while else doesn't make sense Pete Forman <petef4+usenet@gmail.com> - 2016-05-23 19:16 +0100
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 13:24 -0600
Re: for / while else doesn't make sense Pete Forman <petef4+usenet@gmail.com> - 2016-05-23 22:50 +0100
Re: for / while else doesn't make sense Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-24 18:49 +1200
Re: for / while else doesn't make sense Pete Forman <petef4+usenet@gmail.com> - 2016-05-24 19:03 +0100
Re: for / while else doesn't make sense Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-25 18:35 +1200
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-24 10:38 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 00:57 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-24 01:47 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 01:57 +1000
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-23 17:51 +0100
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 02:59 +1000
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-23 20:55 +0100
Re: for / while else doesn't make sense Mark Dickinson <mdickinson@enthought.com> - 2016-05-23 20:17 +0000
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-23 22:01 +0100
Numerical methods [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-24 10:57 +1000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-23 08:30 -0700
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 10:02 -0600
Re: for / while else doesn't make sense Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-23 20:22 +0000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 09:53 -0600
When were real numbers born? (was for / while else doesn't make sense) Rustom Mody <rustompmody@gmail.com> - 2016-05-23 22:02 -0700
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-23 15:36 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-24 11:05 +1000
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-05-23 19:19 -0700
META Culture of this place [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-25 02:43 +1000
Re: META Culture of this place [was Re: for / while else doesn't make sense] boB Stepp <robertvstepp@gmail.com> - 2016-05-24 12:19 -0500
Re: META Culture of this place [was Re: for / while else doesn't make sense] Ned Batchelder <ned@nedbatchelder.com> - 2016-05-24 10:44 -0700
Re: META Culture of this place [was Re: for / while else doesn't make sense] Paul Rubin <no.email@nospam.invalid> - 2016-05-24 12:54 -0700
Re: for / while else doesn't make sense Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-24 14:23 +0000
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-24 10:40 -0700
Re: for / while else doesn't make sense Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-25 18:38 +1200
Extended ASCII [was Re: for / while else doesn't make sense] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-25 17:30 +1000
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-25 02:10 -0700
Exended ASCII and code pages [was Re: for / while else doesn't make sense] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-25 20:19 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Chris Angelico <rosuav@gmail.com> - 2016-05-25 20:30 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Erik <python@lucidity.plus.com> - 2016-05-25 22:03 +0100
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-05-26 10:21 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Rustom Mody <rustompmody@gmail.com> - 2016-05-26 00:44 -0700
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-26 12:11 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Chris Angelico <rosuav@gmail.com> - 2016-05-26 19:20 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Erik <python@lucidity.plus.com> - 2016-05-26 21:54 +0100
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-05-27 08:03 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-05-25 21:28 -0400
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Erik <python@lucidity.plus.com> - 2016-05-26 09:11 +0100
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-26 12:20 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Erik <python@lucidity.plus.com> - 2016-05-26 21:29 +0100
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-27 00:12 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-27 13:35 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-27 09:10 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-27 16:47 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-27 10:04 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-27 19:56 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Random832 <random832@fastmail.com> - 2016-05-27 09:51 -0400
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Rustom Mody <rustompmody@gmail.com> - 2016-05-27 08:53 -0700
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Random832 <random832@fastmail.com> - 2016-05-27 12:09 -0400
Coding systems are political (was Exended ASCII and code pages) Rustom Mody <rustompmody@gmail.com> - 2016-05-27 21:46 -0700
Re: Coding systems are political (was Exended ASCII and code pages) wxjmfauth@gmail.com - 2016-05-28 08:16 -0700
Re: Coding systems are political (was Exended ASCII and code pages) Ned Batchelder <ned@nedbatchelder.com> - 2016-05-28 08:50 -0700
Re: Coding systems are political (was Exended ASCII and code pages) Random832 <random832@fastmail.com> - 2016-05-28 14:05 -0400
Re: Coding systems are political (was Exended ASCII and code pages) Steven D'Aprano <steve@pearwood.info> - 2016-05-29 15:37 +1000
Re: Coding systems are political (was Exended ASCII and code pages) Rustom Mody <rustompmody@gmail.com> - 2016-05-28 23:12 -0700
Re: Coding systems are political (was Exended ASCII and code pages) Terry Reedy <tjreedy@udel.edu> - 2016-05-29 14:46 -0400
Re: Coding systems are political (was Exended ASCII and code pages) Christian Gollwitzer <auriocus@gmx.de> - 2016-05-29 22:29 +0200
Re: Coding systems are political (was Exended ASCII and code pages) wxjmfauth@gmail.com - 2016-05-30 06:35 -0700
Re: Coding systems are political (was Exended ASCII and code pages) Rustom Mody <rustompmody@gmail.com> - 2016-06-04 20:54 -0700
Re: Coding systems are political (was Exended ASCII and code pages) alister <alister.ware@ntlworld.com> - 2016-05-29 06:19 +0000
Re: Coding systems are political (was Exended ASCII and code pages) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-29 20:54 +1200
Re: Coding systems are political (was Exended ASCII and code pages) Marko Rauhamaa <marko@pacujo.net> - 2016-05-29 12:56 +0300
Re: Coding systems are political (was Exended ASCII and code pages) wxjmfauth@gmail.com - 2016-05-30 09:11 -0700
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Chris Angelico <rosuav@gmail.com> - 2016-05-28 02:16 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-28 18:54 +1000
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-27 22:03 +0300
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Rustom Mody <rustompmody@gmail.com> - 2016-05-27 21:23 -0700
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Rustom Mody <rustompmody@gmail.com> - 2016-05-26 03:39 -0700
Re: Exended ASCII and code pages [was Re: for / while else doesn't make sense] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-05-26 07:07 -0400
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-25 13:47 +0300
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-25 05:19 -0700
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-25 22:49 -0700
Re: for / while else doesn't make sense Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-05-26 09:54 +0300
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-26 00:44 -0700
Re: for / while else doesn't make sense wxjmfauth@gmail.com - 2016-05-26 00:52 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-26 12:05 +0300
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-29 14:41 -0400
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-05-29 22:01 +0300
Re: for / while else doesn't make sense Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-05-23 20:07 -0400
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 10:11 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-24 02:59 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 17:09 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 03:33 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-23 17:57 +0000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-24 04:14 +1000
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-05-23 13:44 -0400
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-23 11:52 -0600
Re: for / while else doesn't make sense Alan Evangelista <alanoe@linux.vnet.ibm.com> - 2016-05-23 15:06 -0300
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-24 12:15 +1000
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-24 10:54 +0000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-05-25 03:44 +1000
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-25 03:49 +1000
Re: for / while else doesn't make sense MRAB <python@mrabarnett.plus.com> - 2016-05-24 19:57 +0100
Re: for / while else doesn't make sense Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-05-24 20:10 +0000
Re: for / while else doesn't make sense Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-23 20:29 +0100
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-05-23 18:33 +1000
Re: for / while else doesn't make sense Grant Edwards <grant.b.edwards@gmail.com> - 2016-05-21 02:17 +0000
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-20 18:23 -0700
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-05-21 12:31 +1000
Re: for / while else doesn't make sense Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-20 20:47 -0700
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-05-20 22:18 -0700
Education [was Re: for / while else doesn't make sense] Steven D'Aprano <steve@pearwood.info> - 2016-05-21 20:05 +1000
Re: Education [was Re: for / while else doesn't make sense] Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-21 08:51 -0700
Re: Education [was Re: for / while else doesn't make sense] Marko Rauhamaa <marko@pacujo.net> - 2016-05-21 20:08 +0300
Re: Education [was Re: for / while else doesn't make sense] Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-05-23 16:44 +0000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-01 16:39 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-02 13:44 +1000
Re: for / while else doesn't make sense Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-02 20:09 +0000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-02 14:46 -0600
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-02 21:52 +0100
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-02 18:05 -0700
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-03 10:23 +0100
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-02 19:47 -0700
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-03 10:32 +0100
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-03 09:22 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-04 12:20 +1000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-03 20:41 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-04 19:27 +1000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-04 20:20 -0700
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-04 13:55 +0100
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-02 18:08 -0700
Re: for / while else doesn't make sense Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-06-03 15:52 +0000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-03 09:24 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-04 13:00 +1000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-03 20:43 -0700
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-06-04 04:37 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-04 20:29 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-05 16:35 +1000
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-06-05 04:29 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 14:43 +0300
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-06 17:51 -0700
Re: for / while else doesn't make sense Dan Sommers <dan@tombstonezero.net> - 2016-06-07 03:34 +0000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 00:53 -0700
Re: for / while else doesn't make sense Dan Sommers <dan@tombstonezero.net> - 2016-06-07 12:27 +0000
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 14:57 -0700
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-06 22:35 -0600
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 00:52 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-07 11:00 +0300
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 15:07 -0700
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-06-07 17:31 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 18:25 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 18:29 -0700
Re: for / while else doesn't make sense Ned Batchelder <ned@nedbatchelder.com> - 2016-06-07 18:40 -0700
Re: for / while else doesn't make sense breamoreboy@gmail.com - 2016-06-07 20:45 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-08 08:24 +0300
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-07 18:36 +1000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-07 05:52 -0600
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 14:58 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-08 01:06 +0300
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-07 15:08 -0700
Re: for / while else doesn't make sense Marko Rauhamaa <marko@pacujo.net> - 2016-06-08 08:27 +0300
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-08 17:34 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-09 18:19 +1000
Re: for / while else doesn't make sense Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-07 17:11 -0600
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-06 17:53 -0700
Re: for / while else doesn't make sense Ethan Furman <ethan@stoneleaf.us> - 2016-06-07 21:13 -0700
Re: for / while else doesn't make sense pavlovevidence@gmail.com - 2016-06-12 00:01 -0700
AttributeError into a bloc try-except AttributeError Vincent Vande Vyvre <vincent.vande.vyvre@telenet.be> - 2016-06-12 09:20 +0200
Re: AttributeError into a bloc try-except AttributeError Vincent Vande Vyvre <vincent.vande.vyvre@telenet.be> - 2016-06-12 10:30 +0200
Re: for / while else doesn't make sense Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-12 20:06 +1000
Re: for / while else doesn't make sense Michael Selik <michael.selik@gmail.com> - 2016-06-12 18:44 +0000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-13 12:12 +1000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-12 20:46 -0700
Re: for / while else doesn't make sense Michael Selik <michael.selik@gmail.com> - 2016-06-13 23:45 +0000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-14 12:43 +1000
Re: for / while else doesn't make sense Michael Selik <michael.selik@gmail.com> - 2016-06-14 04:37 +0000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-14 08:33 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-14 16:27 -0700
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-14 18:29 -0700
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-15 13:12 +1000
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-14 20:38 -0700
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-15 04:19 -0700
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-15 13:27 +0100
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-15 05:44 -0700
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-06-15 09:51 -0400
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-15 07:20 -0700
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-06-15 11:54 -0400
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-15 10:03 -0700
Re: for / while else doesn't make sense BartC <bc@freeuk.com> - 2016-06-15 18:27 +0100
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-16 11:40 +1000
Re: for / while else doesn't make sense Michael Selik <michael.selik@gmail.com> - 2016-06-15 17:18 +0000
Re: for / while else doesn't make sense Random832 <random832@fastmail.com> - 2016-06-15 13:41 -0400
Re: for / while else doesn't make sense Rustom Mody <rustompmody@gmail.com> - 2016-06-15 07:31 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-15 19:59 -0700
Re: for / while else doesn't make sense Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-15 19:54 -0700
What is structured programming (was for/while else doesn't make sense) Rustom Mody <rustompmody@gmail.com> - 2016-06-15 22:48 -0700
Re: What is structured programming (was for/while else doesn't make sense) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-15 22:57 -0700
Re: What is structured programming (was for/while else doesn't make sense) Rustom Mody <rustompmody@gmail.com> - 2016-06-16 04:12 -0700
Re: What is structured programming (was for/while else doesn't make sense) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-16 18:53 -0700
Re: What is structured programming (was for/while else doesn't make sense) Rustom Mody <rustompmody@gmail.com> - 2016-06-17 09:32 -0700
Re: What is structured programming (was for/while else doesn't make sense) Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-17 16:07 -0700
Re: for / while else doesn't make sense Chris Angelico <rosuav@gmail.com> - 2016-06-15 23:56 +1000
Re: for / while else doesn't make sense Steven D'Aprano <steve@pearwood.info> - 2016-06-16 11:19 +1000
Page 1 of 15 [1] 2 3 … 15 Next page →
| From | Herkermer Sherwood <theherk@gmail.com> |
|---|---|
| Date | 2016-05-19 09:31 -0700 |
| Subject | for / while else doesn't make sense |
| Message-ID | <mailman.36.1463676220.27390.python-list@python.org> |
Most keywords in Python make linguistic sense, but using "else" in for and while structures is kludgy and misleading. I am under the assumption that this was just utilizing an already existing keyword. Adding another like "andthen" would not be good. But there is already a reserved keyword that would work great here. "finally". It is already a known keyword used in try blocks, but would work perfectly here. Best of all, it would actually make sense. Unfortunately, it wouldn't follow the semantics of try/except/else/finally. Is it better to follow the semantics used elsewhere in the language, or have the language itself make sense semantically? I think perhaps "finally" should be added to for and while to do the same thing as "else". What do you think?
[toc] | [next] | [standalone]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2016-05-19 10:22 -0700 |
| Message-ID | <90ac7bc8-d24c-443e-aead-9759a180ce5c@googlegroups.com> |
| In reply to | #108830 |
On Thursday, May 19, 2016 at 12:43:56 PM UTC-4, Herkermer Sherwood wrote:
> Most keywords in Python make linguistic sense, but using "else" in for and
> while structures is kludgy and misleading. I am under the assumption that
> this was just utilizing an already existing keyword. Adding another like
> "andthen" would not be good.
>
> But there is already a reserved keyword that would work great here.
> "finally". It is already a known keyword used in try blocks, but would work
> perfectly here. Best of all, it would actually make sense.
>
> Unfortunately, it wouldn't follow the semantics of try/except/else/finally.
>
> Is it better to follow the semantics used elsewhere in the language, or
> have the language itself make sense semantically?
>
> I think perhaps "finally" should be added to for and while to do the same
> thing as "else". What do you think?
For/else has always caused people consternation.
My best stab at explaining it is this: the else clause is executed if no
break was encountered in the body of the for loop. A simple structure
would look like this:
for thing in container:
if something_about(thing):
# Found it!
do_something(thing)
break
else:
# Didn't find it..
no_such_thing()
I think of the "else" as being paired with the "if" inside the loop.
At run time, you execute a number of "if"s, one for each iteration
around the loop. The "else" is what gets executed if none of the
"if"s was true. In that sense, it's exactly the right keyword to
use.
--Ned.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-20 04:02 +1000 |
| Message-ID | <573dffb3$0$1611$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108833 |
On Fri, 20 May 2016 03:22 am, Ned Batchelder wrote:
> On Thursday, May 19, 2016 at 12:43:56 PM UTC-4, Herkermer Sherwood wrote:
>> Most keywords in Python make linguistic sense, but using "else" in for
>> and while structures is kludgy and misleading. I am under the assumption
>> that this was just utilizing an already existing keyword. Adding another
>> like "andthen" would not be good.
>>
>> But there is already a reserved keyword that would work great here.
>> "finally". It is already a known keyword used in try blocks, but would
>> work perfectly here. Best of all, it would actually make sense.
>>
>> Unfortunately, it wouldn't follow the semantics of
>> try/except/else/finally.
>>
>> Is it better to follow the semantics used elsewhere in the language, or
>> have the language itself make sense semantically?
>>
>> I think perhaps "finally" should be added to for and while to do the same
>> thing as "else". What do you think?
>
> For/else has always caused people consternation.
>
> My best stab at explaining it is this: the else clause is executed if no
> break was encountered in the body of the for loop.
You're describing the consequences of the break: it breaks out of the entire
for statement, which includes the (badly named) "else" clause.
It's also misleading: break is not the only way to skip the else clause. You
can also return, or raise.
As far as I can determine, if you consider all the corner cases, the best
description of the behaviour is:
- the "else" clause is UNCONDITIONALLY executed after the for-loop has
completed, but before any code past the for...else blocks gets to run.
- anything which breaks outside of the for...else will prevent execution of
the else clause. returns jumps all the way out of the function, break
doesn't jump out of the function but it jumps out of the combined
for...else block.
> A simple structure would look like this:
>
> for thing in container:
> if something_about(thing):
> # Found it!
> do_something(thing)
> break
> else:
> # Didn't find it..
> no_such_thing()
>
> I think of the "else" as being paired with the "if" inside the loop.
The fatal flaw with that is that there is no requirement that there be any
such "if" inside the loop. In fact, there's no need to even have a break in
the loop at all!
> At run time, you execute a number of "if"s, one for each iteration
"One"?
for x in sequence:
if condition: break
if x < 0: break
if today is Tuesday: break
if i.feel_like_it(): break
else:
print("which `if` matches this `else`?")
> around the loop. The "else" is what gets executed if none of the
> "if"s was true. In that sense, it's exactly the right keyword to
> use.
So long as you don't think too hard about what's actually going on, and only
consider the most obvious case, it almost makes a bit of sense :-)
But really, the else clause *actually is* an unconditional block which
executes after the loop. That's how it is implemented, and that's how it is
best understood.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | theherk@gmail.com |
|---|---|
| Date | 2016-05-19 11:47 -0700 |
| Message-ID | <b0d64677-aef7-45d5-9d41-9b1c80adaabc@googlegroups.com> |
| In reply to | #108833 |
This is exactly what I'm referencing. We can do mental gymnastics for it to make sense, but remove the `break` in your code and what happens? The logic goes away. The code ends up executing anyway, which is what makes it more like "finally" to me. Although, as Ian pointed out that would cause breakages for the "finally" meaning, because with the break you wouldn't expect it to execute, but we expect "finally" always to execute. It is a great example for sure, but it only makes sense in specific constructs. I think this is a really interesting topic to which there may not be a better answer. On Thursday, May 19, 2016 at 10:22:31 AM UTC-7, Ned Batchelder wrote: > On Thursday, May 19, 2016 at 12:43:56 PM UTC-4, Herkermer Sherwood wrote: > > Most keywords in Python make linguistic sense, but using "else" in for and > > while structures is kludgy and misleading. I am under the assumption that > > this was just utilizing an already existing keyword. Adding another like > > "andthen" would not be good. > > > > But there is already a reserved keyword that would work great here. > > "finally". It is already a known keyword used in try blocks, but would work > > perfectly here. Best of all, it would actually make sense. > > > > Unfortunately, it wouldn't follow the semantics of try/except/else/finally. > > > > Is it better to follow the semantics used elsewhere in the language, or > > have the language itself make sense semantically? > > > > I think perhaps "finally" should be added to for and while to do the same > > thing as "else". What do you think? > > For/else has always caused people consternation. > > My best stab at explaining it is this: the else clause is executed if no > break was encountered in the body of the for loop. A simple structure > would look like this: > > for thing in container: > if something_about(thing): > # Found it! > do_something(thing) > break > else: > # Didn't find it.. > no_such_thing() > > I think of the "else" as being paired with the "if" inside the loop. > At run time, you execute a number of "if"s, one for each iteration > around the loop. The "else" is what gets executed if none of the > "if"s was true. In that sense, it's exactly the right keyword to > use. > > --Ned.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-05-19 23:28 +0300 |
| Message-ID | <87r3cx4wt1.fsf@elektro.pacujo.net> |
| In reply to | #108837 |
theherk@gmail.com: > This is exactly what I'm referencing. We can do mental gymnastics for > it to make sense, Programming languages are not English. Any resemblance is purely coincidental. Marko
[toc] | [prev] | [next] | [standalone]
| From | David Jardine <david@jardine.de> |
|---|---|
| Date | 2016-05-19 21:49 +0200 |
| Message-ID | <mailman.43.1463693094.27390.python-list@python.org> |
| In reply to | #108837 |
On Thu, May 19, 2016 at 11:47:28AM -0700, theherk@gmail.com wrote: > This is exactly what I'm referencing. We can do mental gymnastics for it > to make sense, but remove the `break` in your code and what happens? The > logic goes away. Quite. What would the code mean? Why would you use "else" if you were always going to drop out of the end of the loop anyway? You need it in a situation where you're "hoping" to find something: meet the 6.30 train at the station, look at each passenger that gets off and if one is wearing a pink carnation in his/her buttonhole go off together and live happily ever after. But when the last passenger has got off and you haven't seen a pink carnation? That's where the "else" clause comes in. You hope you won't need it. > [...] > On Thursday, May 19, 2016 at 10:22:31 AM UTC-7, Ned Batchelder wrote: > > > > [...] > > > > For/else has always caused people consternation. > > > > My best stab at explaining it is this: the else clause is executed if no > > break was encountered in the body of the for loop. A simple structure > > would look like this: > > > > for thing in container: > > if something_about(thing): > > # Found it! > > do_something(thing) > > break > > else: > > # Didn't find it.. > > no_such_thing() > > > > I think of the "else" as being paired with the "if" inside the loop. > > At run time, you execute a number of "if"s, one for each iteration > > around the loop. The "else" is what gets executed if none of the > > "if"s was true. In that sense, it's exactly the right keyword to > > use. > > Cheers, David
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-20 03:46 +1000 |
| Message-ID | <573dfc0f$0$1586$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108830 |
On Fri, 20 May 2016 02:31 am, Herkermer Sherwood wrote: > Most keywords in Python make linguistic sense, but using "else" in for and > while structures is kludgy and misleading. I am under the assumption that > this was just utilizing an already existing keyword. Adding another like > "andthen" would not be good. If I could steal the keys to Guido's time machine, I would go back in time and change the for...else and while...else keywords to for...then and while...then. Alas, we missed the opportunity for a major backwards-incompatible change. Python 3.0 is long past, we're up to 3.5 now, 3.6 is in alpha, there's no way the keyword is going to be changed :-( > But there is already a reserved keyword that would work great here. > "finally". It is already a known keyword used in try blocks, but would > work perfectly here. Best of all, it would actually make sense. No. for...else doesn't operate like a finally block. The idea of finally is that it executes no matter what happens[1]. That's completely the opposite of for...else: the whole point of for...else is that "break" will jump out of the block without executing the else part. > Unfortunately, it wouldn't follow the semantics of > try/except/else/finally. Exactly. > Is it better to follow the semantics used elsewhere in the language, or > have the language itself make sense semantically? If Python was a younger language with fewer users, less existing code, and no backwards-compatibility guarantees, I would argue for changing for...else to for...then. But Python is over 20 years old, has tens or hundreds of thousands of users, tens of millions of lines of code, and quite strict backwards-compatibility guarantees. > I think perhaps "finally" should be added to for and while to do the same > thing as "else". What do you think? I think adding "finally" as an alias is just needlessly confusing. Think of the millions of people who aren't English speakers who nevertheless had to memorise weird and unintuitive words like "for", "while", "if" etc. The least we English speakers can do is suck it up and memorise *one* weird case, "else". [1] Well, *almost* no matter what. If you pull the power from the computer, the finally block never gets a chance to run. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-19 17:55 +0000 |
| Message-ID | <slrnnjrvmb.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108834 |
On 2016-05-19, Steven D'Aprano <steve@pearwood.info> wrote: > On Fri, 20 May 2016 02:31 am, Herkermer Sherwood wrote: >> Most keywords in Python make linguistic sense, but using "else" in for and >> while structures is kludgy and misleading. I am under the assumption that >> this was just utilizing an already existing keyword. Adding another like >> "andthen" would not be good. > > If I could steal the keys to Guido's time machine, I would go back in time > and change the for...else and while...else keywords to for...then and > while...then. I guess we should thank our lucky stars that you don't have a time machine then, since that change would very much be one for the worse in my opinion. for...else is perfectly straightforward and clearly the right keywords to use. for...then would be entirely wrong.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-20 10:06 +1000 |
| Message-ID | <573e54f7$0$1615$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108835 |
On Fri, 20 May 2016 03:55 am, Jon Ribbens wrote:
> I guess we should thank our lucky stars that you don't have a time
> machine then, since that change would very much be one for the worse
> in my opinion. for...else is perfectly straightforward and clearly
> the right keywords to use. for...then would be entirely wrong.
"Entirely" wrong? "Clearly" the right keyword? "Perfectly" straightforward?
They are extremely strong words given the posts where *even the defenders*
of "else" have admitted that it is a hard keyword to understand. But that's
okay. Maybe you've thought of something the rest of us haven't, and have an
entire consistent mental model of for...else that is easy to understand and
makes it "perfectly straightforward and clearly the right keyword".
Can you explain your model which makes "else" appropriate?
In my experience, some people (including me) misunderstand "for...else" to
mean that the else block runs if the for block *doesn't*. It took me the
longest time to understand why this didn't work as I expected:
for x in seq:
pass
else:
print("seq is empty")
because like many people, my mental model was "the for block runs, OR ELSE
the else block runs". This *incorrect* model seems like it works: if you
set seq=[], say, it prints "seq is empty" as expected.
But its wrong: set seq=[1, 2, 3], and it *still* prints "seq is empty". My
model of what was going on was faulty.
I never would have thought of that model if it had been called "then":
for x in seq:
pass
then:
print("executes after the for block completes")
which describes what actually happens: regardless of whether seq is empty or
not, the loop runs, THEN the "else" block unconditionally executes. That
has the advantage of also matching the implementation, both as byte-code,
and in C.
I've seen people assume that the for loop actually sets a hidden flag to
record whether or not a break was executed. There is no flag. It simply
doesn't get executed because code execution jumps past it.
But please do explain your execution model of "for...else". If it is better
than mine, I'll be happy to use it instead.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | gst <g.starck@gmail.com> |
|---|---|
| Date | 2016-05-19 19:02 -0700 |
| Message-ID | <46a9d199-1c7c-47f7-935e-60a1eef6d378@googlegroups.com> |
| In reply to | #108849 |
I know this does not bring anything valuable but: Definitively agree with your mental model !! 'then' and only "then" is the best keyword in the situation which is on the table right now. it totally fix the confusing "else" actual mess (for at least 2 reasons). Python 4.0 ? My son will thank us ! NB: - I'm not a native English speaker - but I'm using the "(for,while)/else" way sometimes, but damn the "then" keyword is at least better here !
[toc] | [prev] | [next] | [standalone]
| From | Stephen Hansen <me+python@ixokai.io> |
|---|---|
| Date | 2016-05-19 23:53 -0700 |
| Message-ID | <mailman.45.1463727239.27390.python-list@python.org> |
| In reply to | #108850 |
On Thu, May 19, 2016, at 07:02 PM, gst wrote: > Python 4.0 ? My son will thank us ! No, he won't, because while Python 4.0 will happen, likely after Python 3.9, it will not be a major backwards compatible breaking point. Some people infer that because 3.0 was, 4.0, 5.0, 6.0 are open to it. They aren't. -- Stephen Hansen m e @ i x o k a i . i o
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-20 11:55 +0000 |
| Message-ID | <slrnnjtv0e.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108849 |
On 2016-05-20, Steven D'Aprano <steve@pearwood.info> wrote:
> On Fri, 20 May 2016 03:55 am, Jon Ribbens wrote:
>> I guess we should thank our lucky stars that you don't have a time
>> machine then, since that change would very much be one for the worse
>> in my opinion. for...else is perfectly straightforward and clearly
>> the right keywords to use. for...then would be entirely wrong.
>
> "Entirely" wrong? "Clearly" the right keyword? "Perfectly" straightforward?
>
> They are extremely strong words given the posts where *even the defenders*
> of "else" have admitted that it is a hard keyword to understand. But that's
> okay. Maybe you've thought of something the rest of us haven't, and have an
> entire consistent mental model of for...else that is easy to understand and
> makes it "perfectly straightforward and clearly the right keyword".
>
> Can you explain your model which makes "else" appropriate?
Certainly. "else:" is (almost?) invariably used in the situation where
you are iterating through something in order to find a value which
matches a certain condition. So the "for:" block means "find this
value" and the "else:" means "else do this".
> In my experience, some people (including me) misunderstand "for...else" to
> mean that the else block runs if the for block *doesn't*. It took me the
> longest time to understand why this didn't work as I expected:
>
> for x in seq:
> pass
> else:
> print("seq is empty")
>
> because like many people, my mental model was "the for block runs, OR ELSE
> the else block runs". This *incorrect* model seems like it works: if you
> set seq=[], say, it prints "seq is empty" as expected.
>
> But its wrong: set seq=[1, 2, 3], and it *still* prints "seq is empty". My
> model of what was going on was faulty.
The problem there is that the mental model is *completely* wrong.
"else:" has nothing at all to do with the number of values in the
iterated sequence.
> I never would have thought of that model if it had been called "then":
>
> for x in seq:
> pass
> then:
> print("executes after the for block completes")
I would find that very confusing. "then:" makes it sound like
executing that block is the usual case, when in practice it is
usually the exception - the fallback code if the expected value
was not found.
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2016-05-20 19:57 -0400 |
| Message-ID | <mailman.59.1463788631.27390.python-list@python.org> |
| In reply to | #108859 |
On Fri, 20 May 2016 11:55:34 -0000 (UTC), Jon Ribbens
<jon+usenet@unequivocal.co.uk> declaimed the following:
>
>I would find that very confusing. "then:" makes it sound like
>executing that block is the usual case, when in practice it is
>usually the exception - the fallback code if the expected value
>was not found.
And I'll second that...
In those languages that use "then" as a keyword, it separates the "if"
conditional from the "true" block of code. Or -- visualize replacing the
":" on the "for" with the word "then"
for x in sequence then
do stuff with x
else
do something with no x
If a different keyword is to be introduced, I nominate "otherwise"
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 21:26 +1000 |
| Message-ID | <574045fa$0$22142$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108874 |
On Sat, 21 May 2016 09:57 am, Dennis Lee Bieber wrote: > On Fri, 20 May 2016 11:55:34 -0000 (UTC), Jon Ribbens > <jon+usenet@unequivocal.co.uk> declaimed the following: > >> >>I would find that very confusing. "then:" makes it sound like >>executing that block is the usual case, when in practice it is >>usually the exception - the fallback code if the expected value >>was not found. > > And I'll second that... > > In those languages that use "then" as a keyword, it separates the "if" > conditional from the "true" block of code. Or -- visualize replacing the > ":" on the "for" with the word "then" > > for x in sequence then > do stuff with x > else > do something with no x > > > If a different keyword is to be introduced, I nominate "otherwise" "otherwise" fails for the same reason that "else" fails: it suggests that the else block is an alternative to the for block, which is exactly what it is NOT. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2016-05-20 16:58 -0700 |
| Message-ID | <mailman.60.1463788672.27390.python-list@python.org> |
| In reply to | #108859 |
On 05/20/2016 04:55 AM, Jon Ribbens wrote:
> On 2016-05-20, Steven D'Aprano wrote:
>> On Fri, 20 May 2016 03:55 am, Jon Ribbens wrote:
>>> I guess we should thank our lucky stars that you don't have a time
>>> machine then, since that change would very much be one for the worse
>>> in my opinion. for...else is perfectly straightforward and clearly
>>> the right keywords to use. for...then would be entirely wrong.
>>
>> "Entirely" wrong? "Clearly" the right keyword? "Perfectly" straightforward?
>>
>> They are extremely strong words given the posts where *even the defenders*
>> of "else" have admitted that it is a hard keyword to understand. But that's
>> okay. Maybe you've thought of something the rest of us haven't, and have an
>> entire consistent mental model of for...else that is easy to understand and
>> makes it "perfectly straightforward and clearly the right keyword".
>>
>> Can you explain your model which makes "else" appropriate?
>
> Certainly. "else:" is (almost?) invariably used in the situation where
> you are iterating through something in order to find a value which
> matches a certain condition. So the "for:" block means "find this
> value" and the "else:" means "else do this".
I'm happy that you have a working mental model for for/else (seriously,
I am) but please don't discount the confusion and consternation for the
many folks who don't start with that mental model.
The number of times I have /wanted/ to use the for/else structure for
searching is small (and I remember them both ;) -- every other time what
I wanted was an _else_ that ran iff the iterable was already empty when
the _for_ encountered it.
>> because like many people, my mental model was "the for block runs, OR ELSE
>> the else block runs". This *incorrect* model seems like it works: if you
>> set seq=[], say, it prints "seq is empty" as expected.
> The problem there is that the mental model is *completely* wrong.
D'oh. Completely wrong, but easy to guess because of the similarity
with if/else.
>> I never would have thought of that model if it had been called "then":
>>
>> for x in seq:
>> pass
>> then:
>> print("executes after the for block completes")
>
> I would find that very confusing. "then:" makes it sound like
> executing that block is the usual case, when in practice it is
> usually the exception - the fallback code if the expected value
> was not found.
If you don't take the extra step of _break_ it is the usual case. Most
of my for loops always run all the way through, so why have an else?
Two possible reasons:
- the loop didn't run at all
- the loop didn't run all the way
Guido picked the one that was obvious to him (him being Dutch and all ;) .
I just read Nick's post about it, and while it helps, I think the
syntactic similarity between try/else and for/else (did the block run
without error) is dwarfed by the semantic difference: a try/else else
block runs if nothing /bad/ happened whereas a for/else else block runs
if something bad /did/ happen; to wit, the thing you were looking for
was not found (or your loop didn't run at all ;) .
But as others have said, this isn't going to change now, and I'm okay
with that. But, please, be a bit more understanding of those who don't
immediately grok the for/else and while/else loops.
--
~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-21 00:24 +0000 |
| Message-ID | <slrnnjvatb.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108875 |
On 2016-05-20, Ethan Furman <ethan@stoneleaf.us> wrote: > On 05/20/2016 04:55 AM, Jon Ribbens wrote: >> Certainly. "else:" is (almost?) invariably used in the situation where >> you are iterating through something in order to find a value which >> matches a certain condition. So the "for:" block means "find this >> value" and the "else:" means "else do this". > > I'm happy that you have a working mental model for for/else (seriously, > I am) but please don't discount the confusion and consternation for the > many folks who don't start with that mental model. > > The number of times I have /wanted/ to use the for/else structure for > searching is small (and I remember them both ;) -- every other time what > I wanted was an _else_ that ran iff the iterable was already empty when > the _for_ encountered it. Well that's not a circumstance that's appropriate for the construct. Saying you want a different construct entirely is an entirely different argument. >> I would find that very confusing. "then:" makes it sound like >> executing that block is the usual case, when in practice it is >> usually the exception - the fallback code if the expected value >> was not found. > > If you don't take the extra step of _break_ it is the usual case. Having an "for: else:" clause without a "break" would be so unusual that it's literally nonexistent, because it would always be a bug. So no, it isn't the usual case for "for: else:". > But as others have said, this isn't going to change now, and I'm okay > with that. But, please, be a bit more understanding of those who don't > immediately grok the for/else and while/else loops. You're misunderstanding me. I'm not saying that the meaning of "for: else:" is 100% intuitively obvious. I'm saying that it's *more* obvious than it would be if it used any of the other existing keywords. I suppose I'm also saying that there isn't any other obvious word that could be made into a keyword that would be better than "else" (even if we assumed that adding a new keyword was a cost-free exercise).
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 13:50 +1000 |
| Message-ID | <573fdaf9$0$1584$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108878 |
On Sat, 21 May 2016 10:24 am, Jon Ribbens wrote:
> On 2016-05-20, Ethan Furman <ethan@stoneleaf.us> wrote:
>> If you don't take the extra step of _break_ it is the usual case.
>
> Having an "for: else:" clause without a "break" would be so unusual
> that it's literally nonexistent, because it would always be a bug.
> So no, it isn't the usual case for "for: else:".
What do you mean? A for...else without a break is perfectly legal code, and
does *EXACTLY* what it is documented as doing:
- first the "for" block runs, looping as appropriate;
- THEN the "else" block runs, *once*.
How is this "always a bug"?
Would you classify the second line here:
print("Hello World!")
pass
as a bug? What exactly would your bug report be? "pass statement does
nothing, as expected. It should do nothing. Please fix."
>> But as others have said, this isn't going to change now, and I'm okay
>> with that. But, please, be a bit more understanding of those who don't
>> immediately grok the for/else and while/else loops.
>
> You're misunderstanding me. I'm not saying that the meaning of
> "for: else:" is 100% intuitively obvious.
I should hope not, because as it stands with the horribly misleading
keyword "else" it is counter-intuitive and confusing. Which is a crying
shame, because it is a useful feature that actually does make a lot of
sense, if only the keyword were better!
> I'm saying that it's
> *more* obvious than it would be if it used any of the other existing
> keywords. I suppose I'm also saying that there isn't any other
> obvious word that could be made into a keyword that would be better
> than "else" (even if we assumed that adding a new keyword was a
> cost-free exercise).
Well, that's a matter of opinion. And you know what they same about
opinions... there are always two, the foolish, pig-ignorant one, and mine.
:-)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-21 14:01 +1000 |
| Message-ID | <mailman.70.1463803314.27390.python-list@python.org> |
| In reply to | #108890 |
On Sat, May 21, 2016 at 1:50 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 21 May 2016 10:24 am, Jon Ribbens wrote:
>
>> On 2016-05-20, Ethan Furman <ethan@stoneleaf.us> wrote:
>
>>> If you don't take the extra step of _break_ it is the usual case.
>>
>> Having an "for: else:" clause without a "break" would be so unusual
>> that it's literally nonexistent, because it would always be a bug.
>> So no, it isn't the usual case for "for: else:".
>
>
> What do you mean? A for...else without a break is perfectly legal code, and
> does *EXACTLY* what it is documented as doing:
>
> - first the "for" block runs, looping as appropriate;
> - THEN the "else" block runs, *once*.
>
> How is this "always a bug"?
>
> Would you classify the second line here:
>
> print("Hello World!")
> pass
>
>
> as a bug? What exactly would your bug report be? "pass statement does
> nothing, as expected. It should do nothing. Please fix."
>
Yes, I would. It's not a bug in Python or CPython - it's a bug in the
second line of code there. It implies something that isn't the case.
It's like having this code:
if True:
pass
elif False:
pass
else:
assert True
It's well-defined code. You know exactly what Python should do. But is
it good code, or is it the sort of thing that gets posted here:
http://thedailywtf.com/articles/a-spiritual-journey
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 19:56 +1000 |
| Message-ID | <574030d3$0$1598$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108892 |
On Sat, 21 May 2016 02:01 pm, Chris Angelico wrote:
> On Sat, May 21, 2016 at 1:50 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> Would you classify the second line here:
>>
>> print("Hello World!")
>> pass
>>
>>
>> as a bug? What exactly would your bug report be? "pass statement does
>> nothing, as expected. It should do nothing. Please fix."
>>
>
> Yes, I would. It's not a bug in Python or CPython - it's a bug in the
> second line of code there. It implies something that isn't the case.
What do you think it implies?
What part of the docs for "pass" implies this thing?
help("pass"):
``pass`` is a null operation --- when it is executed, nothing
happens. It is useful as a placeholder when a statement is
required syntactically, but no code needs to be executed, for
example: [examples snipped]
> It's like having this code:
>
> if True:
> pass
> elif False:
> pass
> else:
> assert True
Hmmm. Well, let see:
py> if True:
... pass
... elif False:
... pass
... else:
... assert True
...
Traceback (most recent call last):
File "<stdin>", line 6, in <module>
AssertionError
What witchcraft is this?
S
P
O
I
L
E
R
S
P
A
C
E
I'm running Python 2, and have redefined True = False.
But even in Python 3, what exactly is the bug supposed to be? The Python 3
compiler, as naive and simple as it is, is perfectly capable of compiling
out the dead code:
py> dis.dis("""if True: pass
... elif False: pass
... else: assert True
... """)
1 0 LOAD_CONST 0 (None)
3 RETURN_VALUE
So the worst we can say about this is that it is pointless dead code.
> It's well-defined code. You know exactly what Python should do. But is
> it good code,
Well, it's not *great* code, that's for sure. Is it good code? That depends.
There are certainly semantic differences between Python 2 and 3, and
without knowing the intention of the author (that would be you) its hard to
say exactly what the code should be. But it's *legal* code that does
exactly what the language documentation says it ought to do.
> or is it the sort of thing that gets posted here:
>
> http://thedailywtf.com/articles/a-spiritual-journey
I'm not sure how that specific Daily-WTF article is relevant.
But in general, is it worthy of Daily-WTF? No, I don't think so. I think
that your "True, False" example could do with some refactoring and cleanup:
perhaps it is dead code that should be completely removed, but that's not
necessarily Daily-WTF worthy. Or it's some part of some sort of Python 2+3
compatibility layer intending to detect rebindings to True or False, in
which case it is certainly ugly (and probably buggy) but may be needed.
As far as my example, using "pass" in the code... no, it's not WTF-worthy
either. It's at worst worth a raised eyebrow. Without knowing the context
of where it came from, it isn't even clear that it is pointless code.
Perhaps it is from a test suite checking that `pass` is correctly parsed,
compiled and executed as a do-nothing statement.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-21 20:08 +1000 |
| Message-ID | <mailman.78.1463825304.27390.python-list@python.org> |
| In reply to | #108908 |
On Sat, May 21, 2016 at 7:56 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 21 May 2016 02:01 pm, Chris Angelico wrote:
>
>> On Sat, May 21, 2016 at 1:50 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>
>>> Would you classify the second line here:
>>>
>>> print("Hello World!")
>>> pass
>>>
>>>
>>> as a bug? What exactly would your bug report be? "pass statement does
>>> nothing, as expected. It should do nothing. Please fix."
>>>
>>
>> Yes, I would. It's not a bug in Python or CPython - it's a bug in the
>> second line of code there. It implies something that isn't the case.
>
> What do you think it implies?
>
> What part of the docs for "pass" implies this thing?
>
> help("pass"):
>
> ``pass`` is a null operation --- when it is executed, nothing
> happens. It is useful as a placeholder when a statement is
> required syntactically, but no code needs to be executed, for
> example: [examples snipped]
So why is a statement required syntactically after that print call?
Surely that implies something about the programmer's intent? It
certainly isn't required according to the code you've shown me; and if
someone submitted this code to me, I'd query it ("was there something
else meant to be here?").
ChrisA
[toc] | [prev] | [next] | [standalone]
Page 1 of 15 [1] 2 3 … 15 Next page →
Back to top | Article view | comp.lang.python
csiph-web