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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Lawrence D’Oliveiro <lawrencedo99@gmail.com> |
|---|---|
| Date | 2016-06-08 17:34 -0700 |
| Message-ID | <54890c12-388e-4923-888f-bd611a0c2076@googlegroups.com> |
| In reply to | #109656 |
On Wednesday, June 8, 2016 at 5:27:41 PM UTC+12, Marko Rauhamaa wrote: > Someone mentioned you had a 500-line function. In my undergraduate Comp Sci classes, we used to discuss arbitrary rules like limiting functions to n lines. With real-world experience, it soon became clear that such rules were a waste of time. A function should be just as big as it needs to be, no more, no less. The same with a class, or a module. Or whatever other constructs your language may have.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-06-09 18:19 +1000 |
| Message-ID | <5759268d$0$2886$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #109693 |
On Thursday 09 June 2016 10:34, Lawrence D’Oliveiro wrote: > In my undergraduate Comp Sci classes, we used to discuss arbitrary rules like > limiting functions to n lines. With real-world experience, it soon became > clear that such rules were a waste of time. A function should be just as big > as it needs to be, no more, no less. The same with a class, or a module. Or > whatever other constructs your language may have. The opposite of "arbitrary limits" is not "no limits". An arbitrary limit like "500 lines is the maximum size a function may be" is clearly arbitrary and not very helpful. (Also too high.) Better is to understand that there is no hard cut-off between "acceptable" and "too long", but we can still judge that all else being equal, long functions are worse than short functions. The real problem is complexity of functions. The more complex they are, the harder they are to write correctly, and the harder to maintain, and the more likely that they have bugs. The length of a function is a very crude measure of complexity, but it *is* a measure of complexity, and people are right to look at long functions as a code smell and a sign that the function probably does too much, or is badly written, or that it could do with some refactoring to simplify it. Not in *every* case, but I've never yet seen a long (> 200 lines) function that wasn't improved by refactoring or splitting. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2016-06-07 17:11 -0600 |
| Message-ID | <mailman.65.1465341122.2306.python-list@python.org> |
| In reply to | #109635 |
On Tue, Jun 7, 2016 at 3:58 PM, Lawrence D’Oliveiro <lawrencedo99@gmail.com> wrote: > On Tuesday, June 7, 2016 at 11:53:46 PM UTC+12, Ian wrote: >> On Tue, Jun 7, 2016 at 1:52 AM, Lawrence D’Oliveiro wrote: > >>> Wow, that’s only twice the length of the code you’re replacing. Well done. >> >> Huh? The example that you posted was 17 lines, excluding comments. My >> replacement code is 17 lines, excluding comments. Where are you >> getting "twice the length" from? > > Maybe not twice. But your code for dealing with the include stack was 16 lines, as opposed to 13 in mine. Well, I don't know how you're counting that. All the code for dealing with the include stack is in the generate_lines function, which is 10 lines long. The remaining code is then simpler for not having to deal with it. In the original version, I can't identify which lines are "dealing with the include stack" because they're so intertwined. For example, all the sporadic code checking for line == None or line != None only need to exist because of the include stack.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <lawrencedo99@gmail.com> |
|---|---|
| Date | 2016-06-06 17:53 -0700 |
| Message-ID | <9021ff59-16bf-4c47-bb80-2ff47809c9a7@googlegroups.com> |
| In reply to | #109510 |
On Sunday, June 5, 2016 at 11:43:20 PM UTC+12, Marko Rauhamaa wrote: > Then, you might overdo constructs like lambdas and maps. Who says you can have too many lambdas? <http://ldo17.tumblr.com/post/17544419704/conditional-expressions-in-python>
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2016-06-07 21:13 -0700 |
| Message-ID | <mailman.68.1465359185.2306.python-list@python.org> |
| In reply to | #109322 |
On 06/01/2016 04:39 PM, Lawrence D’Oliveiro wrote: [multiple apparent trolls redacted] This thread is dead. Please stop beating it. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | pavlovevidence@gmail.com |
|---|---|
| Date | 2016-06-12 00:01 -0700 |
| Message-ID | <9e7b6ded-15ad-490a-9842-b3da5d8a048d@googlegroups.com> |
| In reply to | #108830 |
On Thursday, May 19, 2016 at 9:43:56 AM UTC-7, 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?
I agree it's not the clearest name, but it does behave consistent with if...else. "finally" has a strong connotation for code that is guaranteed to be executed on the way out regardless of an exception, so it wouldn't be appropriate for this even if it were clearer (though it isn't IMO).
Here's how I make sense of for...else. Consider this loop:
for item in seq:
if pred(item):
use(item)
break
else:
not_found()
This particular loop functions as a kind of a dynamic if...elif...else statement. You can see that if you unroll the loop:
if pred(seq[0]):
use(seq[0])
elif pred(seq[1]):
use(seq[1])
elif pred(seq[2]):
use(seq[2])
else:
not_found()
You will note that the else block is the same in both the rolled and unrolled versions, and has exactly the same meaning and usage.
As for a more appropriate keyword, I don't like the examples I saw skimming this thread; neither "finally" nor "then" communicates that the block would executed conditionally.
If you want my opinion, you might as well use something explicit and unambiguous, like "if_exhausted", for the block; and you might as well add an "if_broken" block while you're at it (though it's not quite as useful since in most cases you could just put the code before the break). Since it's only occasionally useful, there's no real need to make the keyword short.
If you really want my opinion, it probably shouldn't be in the language at all, even though I happily use it from time to time, and my code is better for it. But it's not useful enough that the language would really suffer without it, and it would save some users from something that can be quite confusing.
--
Carl Banks
[toc] | [prev] | [next] | [standalone]
| From | Vincent Vande Vyvre <vincent.vande.vyvre@telenet.be> |
|---|---|
| Date | 2016-06-12 09:20 +0200 |
| Subject | AttributeError into a bloc try-except AttributeError |
| Message-ID | <mailman.8.1465716450.2288.python-list@python.org> |
| In reply to | #109842 |
Hi,
I have a strange behaviour in my code.
In an interactive session, the result is as expected:
Python 3.4.3 (default, Oct 14 2015, 20:28:29)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = None
>>> try:
... _ = a.value
... except AttributeError:
... print('OK')
...
OK
>>>
But not in my code:
def call_settings_dialog(self):
try:
_ = self.video.category
self.core.artelive.configure_downloading(self.video)
except AttributeError:
self.core.artetv.configure_downloading(self.video)
and ...
Traceback (most recent call last):
File "/home/vincent/qarte-3/trunk/loadingscheduler.py", line 240, in
call_settings_dialog
_ = self.video.category
AttributeError: 'TVItem' object has no attribute 'category'
I have two types of video, one with an attribute category handled by a
module 'artelive' and an other without this attribute handled by an
other module, that's the reason of this code.
[toc] | [prev] | [next] | [standalone]
| From | Vincent Vande Vyvre <vincent.vande.vyvre@telenet.be> |
|---|---|
| Date | 2016-06-12 10:30 +0200 |
| Subject | Re: AttributeError into a bloc try-except AttributeError |
| Message-ID | <mailman.9.1465720239.2288.python-list@python.org> |
| In reply to | #109842 |
Le 12/06/16 09:20, Vincent Vande Vyvre a écrit :
> Hi,
>
> I have a strange behaviour in my code.
>
> In an interactive session, the result is as expected:
>
> Python 3.4.3 (default, Oct 14 2015, 20:28:29)
> [GCC 4.8.4] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> a = None
> >>> try:
> ... _ = a.value
> ... except AttributeError:
> ... print('OK')
> ...
> OK
> >>>
>
> But not in my code:
>
> def call_settings_dialog(self):
> try:
> _ = self.video.category
> self.core.artelive.configure_downloading(self.video)
> except AttributeError:
> self.core.artetv.configure_downloading(self.video)
>
> and ...
>
> Traceback (most recent call last):
> File "/home/vincent/qarte-3/trunk/loadingscheduler.py", line 240, in
> call_settings_dialog
> _ = self.video.category
> AttributeError: 'TVItem' object has no attribute 'category'
>
> I have two types of video, one with an attribute category handled by a
> module 'artelive' and an other without this attribute handled by an
> other module, that's the reason of this code.
... I have just rewrite the line "_ = self.video.category" and the
problem disappears.
Vincent
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-06-12 20:06 +1000 |
| Message-ID | <575d3430$0$11108$c3e8da3@news.astraweb.com> |
| In reply to | #109842 |
On Sunday 12 June 2016 17:01, pavlovevidence@gmail.com wrote:
> On Thursday, May 19, 2016 at 9:43:56 AM UTC-7, 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.
[...]
>> I think perhaps "finally" should be added to for and while to do the same
>> thing as "else". What do you think?
>
> I agree it's not the clearest name, but it does behave consistent with
> if...else.
Er, not really.
if condition:
print "A"
else:
print "B"
Exactly one of "A" or "B", but NEVER both, will be printed.
for item in sequence:
print "A"
else:
print "B"
Normally we would expect that both "A" and "B" will be printed. There will be a
variable number of "A"s printed, zero or more, and exactly one "B", but the
point is that in general BOTH will run, which is the opposite of if...else.
The actual semantics are:
- run the for block
- THEN unconditionally run the "else" block
The only way to skip running the "else" block is to jump out of the entire
for...else statement, using `return`, `raise` or `break`.
> Here's how I make sense of for...else. Consider this loop:
>
> for item in seq:
> if pred(item):
> use(item)
> break
> else:
> not_found()
That's the major intended use of "else", but note that it is NOT paired with
the `if`. You can have:
def func():
for item in seq:
if pred(item):
use(item)
if condition:
return something
else:
different_use(item)
continue
do_more()
break
else:
not_found()
or any of an infinite number of other combinations. You can't really understand
for...else correctly if you think of the "else" being partnered with an "if"
inside the loop. What if there is no "if"? Or ten of them? Of if they all
already have "else" clauses?
> This particular loop functions as a kind of a dynamic if...elif...else
> statement. You can see that if you unroll the loop:
>
>
> if pred(seq[0]):
> use(seq[0])
> elif pred(seq[1]):
> use(seq[1])
> elif pred(seq[2]):
> use(seq[2])
> else:
> not_found()
They are only equivalent because of the "break". Take the break out, unroll the
loop, and what you have is:
if pred(seq[0]):
use(seq[0])
if pred(seq[1]):
use(seq[1])
if pred(seq[2]):
use(seq[2])
not_found()
Put the break back in, and you have:
if pred(seq[0]):
use(seq[0])
GOTO foo # not actual Python syntax, but see below
if pred(seq[1]):
use(seq[1])
GOTO foo
if pred(seq[2]):
use(seq[2])
GOTO foo
not_found()
label: foo
Admittedly GOTO isn't Python syntax, but this actually is the way that the
bytecode is done: the else clause is executed unconditionally, and a break
jumps past the else clause.
In Python 3.3, "break" is compiled to a JUMP_ABSOLUTE bytecode. You can see
this for yourself using the dis module, e.g.:
import dis
code = compile("""
for i in seq:
this()
if condition:
break
that()
else:
another()
print("done")
""", "", "exec")
dis.dis(code)
> You will note that the else block is the same in both the rolled and unrolled
> versions, and has exactly the same meaning and usage.
But not in the general case. Only certain specific uses of for...else behave as
you suggest.
> As for a more appropriate keyword, I don't like the examples I saw skimming
> this thread; neither "finally" nor "then" communicates that the block would
> executed conditionally.
The block isn't executed conditionally. The block is executed UNCONDITIONALLY.
The only way to avoid executing the "else" block is to jump past it, using a
return, raise of break.
> If you want my opinion, you might as well use something explicit and
> unambiguous, like "if_exhausted", for the block;
But that is exactly what the else clause is NOT. That is an incredibly common
mistake that people make, thinking that the "else" clause executes when the
sequence is exhausted. At first, it *seems* to be the case:
py> seq = []
py> for item in seq:
... print("not empty!")
... else:
... print("empty")
...
empty
but that wrong.
py> seq = [1, 2]
py> for item in seq:
... print("not empty!")
... else:
... print("empty")
...
not empty!
not empty!
empty
py> print(seq) # not exhausted
[1, 2]
The else clause has nothing to do with whether or not the for block runs, or
whether it is empty, or whether the iterable is exhausted after the loop is
complete. The else clause simple runs directly after the for block, unless you
skip it by using the Python equivalent of a GOTO.
> If you really want my opinion, it probably shouldn't be in the language at
> all, even though I happily use it from time to time, and my code is better
> for it.
o_O
> But it's not useful enough that the language would really suffer
> without it, and it would save some users from something that can be quite
> confusing.
As confusing as threads? As confusing as multiple inheritance? As confusing as
asynchronous programming?
If you have seen as many beginners ask "why do I always get 100 heads or 100
tails?" as I have:
count_heads = 0
coin = random.choose(['heads', 'tails'])
for i in range(100):
if coin == 'heads':
count_heads += 1
print("number of heads:", count_heads)
print("number of tails:", 100 - count_heads)
then you will understand that "confusing" is often a matter of experience and
understanding. Once you have the correct understanding of "for...else", there
is nothing confusing about it.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | Michael Selik <michael.selik@gmail.com> |
|---|---|
| Date | 2016-06-12 18:44 +0000 |
| Message-ID | <mailman.23.1465758525.2288.python-list@python.org> |
| In reply to | #109845 |
On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano < steve+comp.lang.python@pearwood.info> wrote: > - run the for block > - THEN unconditionally run the "else" block > Saying "unconditionally" is a bit misleading here. As you say, it's conditioned on completing the loop without break/return/raise.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-06-13 12:12 +1000 |
| Message-ID | <575e167a$0$1608$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #109869 |
On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote: > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano < > steve+comp.lang.python@pearwood.info> wrote: > >> - run the for block >> - THEN unconditionally run the "else" block >> > > Saying "unconditionally" is a bit misleading here. As you say, it's > conditioned on completing the loop without break/return/raise. It's also conditional on the OS not killing the Python process, conditional on the CPU not catching fire, conditional on the user not turning the power of, and conditional on the sun not exploding and disintegrating the entire earth. In the absence of any event which interferes with the normal execution of code by the Python VM, and in the absence of one of a very few explicit "JUMP" statements which explicitly jump out of the compound for...else statement, the else clause is unconditionally executed after the for clause. Happy now? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-06-12 20:46 -0700 |
| Message-ID | <caef1c20-85f1-4174-a383-08e2d74b657d@googlegroups.com> |
| In reply to | #109878 |
On Monday, June 13, 2016 at 7:42:25 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote: > > > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano wrote: > > > >> - run the for block > >> - THEN unconditionally run the "else" block > >> > > > > Saying "unconditionally" is a bit misleading here. As you say, it's > > conditioned on completing the loop without break/return/raise. > > It's also conditional on the OS not killing the Python process, conditional > on the CPU not catching fire, conditional on the user not turning the power > of, and conditional on the sun not exploding and disintegrating the entire > earth. > > In the absence of any event which interferes with the normal execution of > code by the Python VM, and in the absence of one of a very few > explicit "JUMP" statements which explicitly jump out of the compound > for...else statement, the else clause is unconditionally executed after the > for clause. > > Happy now? Wholesale business of strawmen doing brisk business?
[toc] | [prev] | [next] | [standalone]
| From | Michael Selik <michael.selik@gmail.com> |
|---|---|
| Date | 2016-06-13 23:45 +0000 |
| Message-ID | <mailman.47.1465861566.2288.python-list@python.org> |
| In reply to | #109878 |
On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <steve@pearwood.info> wrote: > On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote: > > > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano < > > steve+comp.lang.python@pearwood.info> wrote: > > > >> - run the for block > >> - THEN unconditionally run the "else" block > >> > > > > Saying "unconditionally" is a bit misleading here. As you say, it's > > conditioned on completing the loop without break/return/raise. > > It's also conditional on the OS not killing the Python process, conditional > on the CPU not catching fire, conditional on the user not turning the power > of, and conditional on the sun not exploding and disintegrating the entire > earth. > > In the absence of any event which interferes with the normal execution of > code by the Python VM, and in the absence of one of a very few > explicit "JUMP" statements which explicitly jump out of the compound > for...else statement, the else clause is unconditionally executed after the > for clause. > > Happy now? > I think most folks assume that their program will not run as expected if the sun explodes. Saying that ``raise``, ``break``, and ``return`` are "one of a very few explicit JUMP statements" implies that they are obscure. Listing them in addition to the sun exploding suggests that you think they are similarly unlikely and should be ignored as too bizarre to consider. In contrast, I think raise, break, and return are quite common. Further, I think you do too, despite what you are trying to imply. Maybe I read the tone wrong. It's tough sometimes to hear someone's tone of voice in email.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-06-14 12:43 +1000 |
| Message-ID | <575f6f58$0$1591$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #109917 |
On Tue, 14 Jun 2016 09:45 am, Michael Selik wrote:
> On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <steve@pearwood.info>
> wrote:
>
>> On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote:
>>
>> > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano <
>> > steve+comp.lang.python@pearwood.info> wrote:
>> >
>> >> - run the for block
>> >> - THEN unconditionally run the "else" block
>> >>
>> >
>> > Saying "unconditionally" is a bit misleading here. As you say, it's
>> > conditioned on completing the loop without break/return/raise.
>>
>> It's also conditional on the OS not killing the Python process,
>> conditional on the CPU not catching fire, conditional on the user not
>> turning the power of, and conditional on the sun not exploding and
>> disintegrating the entire earth.
>>
>> In the absence of any event which interferes with the normal execution of
>> code by the Python VM, and in the absence of one of a very few
>> explicit "JUMP" statements which explicitly jump out of the compound
>> for...else statement, the else clause is unconditionally executed after
>> the for clause.
>>
>> Happy now?
>>
>
> I think most folks assume that their program will not run as expected if
> the sun explodes.
On this list, I daresay somebody will insist that if their computer is on
one of Jupiter's moons it will keep running fine and therefore I'm wrong.
> Saying that ``raise``, ``break``, and ``return`` are "one of a very few
> explicit JUMP statements" implies that they are obscure.
What? No. How do you get that?
If I tell you that Python has only two loop constructs, for and while, would
that imply that they are rare and unusual? (Three if you count
comprehensions as distinct from the for statement.)
Python has only two conditional branches: if...elif..else, and the ternary
if operator. Does that make them obscure?
raise, break and return are all explicit JUMPs: they transfer execution to
some place other than the next executable line. There are others, including
continue, but they don't transfer execution past the for loop, so don't
matter in this context. None of this implies that they are obscure. I'm
sorry if you've never thought of a return or break as a JUMP before, but
that's what they are.
> Listing them in
> addition to the sun exploding suggests that you think they are similarly
> unlikely and should be ignored as too bizarre to consider.
No. The sun exploding was me gently mocking you for your comment disputing
the "unconditional" part. Yes, you are technically right that technically
the "else" block will only run if no "break" is reached, and no "return" is
reached, no exception is raised, also that os._exit or os.abort aren't
called, the CPU doesn't catch fire, and the world isn't destroyed.
If we try to enumerate all the things which could prevent the "else" block
from running, we'll be here for decades. But, and this is the point that
everyone seems to have missed, * every single one of those things* is
completely independent of the for...else statement.
*Including* the presence or absence of a "break".
If you want to understand how Python statements work, you should understand
them in isolation (as much as possible), which then allows you to
extrapolate their behaviour in combination with other statements. Most
lines of Python code are understandable in isolation, or at least close to
isolation. You can get *very close* to a full understanding of Python by
just reading one line at a time (with perhaps a bit of short term memory to
remember if you are compiling a function, building a class, etc).
E.g. you don't need to understand for loops to understand if...else.
And vice versa: for...else has a well-defined meaning and operates in a
simple fashion in isolation of other language features. Its not compulsory
to put a "return" statement inside your for loop. Nor is it compulsory to
put a "raise" inside it. And "break" is not compulsory either.
If you think of for...else as being (in some sense) glued to break, then
what are you going to make of code with for...else and no break? That's
legal Python code, and somebody will write it, even if only by accident.
If you think of for...else as being glued to an if inside the for block,
then what are you going to make of code where the if already has an else?
Or code that unconditionally breaks inside the loop? Again, that's legal
code, even if useless. If you think that the for...else has to match an if
inside the loop, you'll have to invent special rules for when there is no
if, or ten of them, or they all are already matched with their own elses.
If you start thinking of it as code which is run conditionally "only if no
break was executed", that leads to people thinking of it in terms of some
sort of hidden flag that Python keeps to tell whether or not a break was
seen. A month or two ago, we had somebody, mislead by that mental model,
asking whether Python should expose that flag so he could write code
something like:
for x in seq:
do_stuff()
else:
do_something_else()
if MAGIC_FLAG:
print("break")
(I don't quite remember all the details of the poster's question/proposal,
but the details aren't important. What's important is that he had a
misleading mental model of Python's for...else semantics that lead him to
make *incorrect predictions* of what Python can, or will, do.)
Somebody else suggested that "else" had the same semantics as "finally", in
that it was always executed after the for loop except for the one special
case of "break". And that mental model is wrong too. And another poster
carefully unrolled the loop to show that the else matched up with the if
inside the loop, and completely failed to deal with the case where the if
already has a matching else. Or the case where there's no break.
There's a simple mental model, one which has the advantage of actually
matching the implementation: for...else executes else unconditionally,
unless something, *anything*, (break, return, raise, the end of the world)
prevents it. As far as I can see, that model works under all possible
circumstances, now and in the future: one if or none, or even ten, with or
without their own matching elses, break or no break, return, raise, even
the end of the world. *wink*
If Python 3.6 introduces a GOTO command, then my mental model of for...else
doesn't need to change. (Neither will the implementation.) If Python 3.7
decides that functions can only have one exit, out the bottom of the
function, and removes the "return" statement, then my mental model of
for...else doesn't need to change either.
All mental models are imperfect, but I think mine is the least imperfect of
all those I've seen. I've struggled with understanding for...else for a
very long time, and I've tried out various models over the years. Starting
with the one implied by the name:
for x in sequence:
block
else:
# for...else is like if...else
# one *or* the other runs but not both
...
That mental model was ludicrously wrong, but I suffered under it for *years*
and couldn't see why my for...else statements weren't doing what I wanted.
I then moved to the mental model that else was linked to the presence of a
break, but it always felt incomplete. I would write this:
for x in sequence:
block
else:
# only if no break occurs
and then I would feel guilty for lying, because that comment is not, in
fact, correct. Returning out of the function from inside the loop will also
avoid running the else part, as will an exception. If you think about it,
there are other ways that will prevent the else from running too. I leave
them as an exercise for the reader :-)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Michael Selik <michael.selik@gmail.com> |
|---|---|
| Date | 2016-06-14 04:37 +0000 |
| Message-ID | <mailman.54.1465879063.2288.python-list@python.org> |
| In reply to | #109922 |
On Mon, Jun 13, 2016 at 10:46 PM Steven D'Aprano <steve@pearwood.info> wrote: > On Tue, 14 Jun 2016 09:45 am, Michael Selik wrote: > > On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <steve@pearwood.info> > > wrote: > >> On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote: > >> > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano < > >> > steve+comp.lang.python@pearwood.info> wrote: > >> > > >> >> - run the for block > >> >> - THEN unconditionally run the "else" block > >> >> > >> > Saying "unconditionally" is a bit misleading here. As you say, it's > >> > conditioned on completing the loop without break/return/raise. > >> > >> It's also conditional on the OS not killing the Python process, > >> conditional on the CPU not catching fire, conditional on the user not > >> turning the power of, and conditional on the sun not exploding and > >> disintegrating the entire earth. > >> > >> In the absence of any event which interferes with the normal execution > of > >> code by the Python VM, and in the absence of one of a very few > >> explicit "JUMP" statements which explicitly jump out of the compound > >> for...else statement, the else clause is unconditionally executed after > >> the for clause. > > > Saying that ``raise``, ``break``, and ``return`` are "one of a very few > > explicit JUMP statements" implies that they are obscure. > > What? No. How do you get that? > The context. That was right after a list of several (mostly) oddball situations. In my experience, that pattern of speech is usually used to imply that everything listed is also exceptionally strange. There's a simple mental model, one which has the advantage of actually > matching the implementation: for...else executes else unconditionally, ... > If Python 3.6 introduces a GOTO command, then my mental model of > for...else doesn't need to change. > That's a good explanation. The documentation says, "A break statement executed in the first suite terminates the loop without executing the else clause’s suite." Do you think that qualification of "without executing the else clause" is unnecessary/redundant? Regardless of the implementation, I think that explanation -- if break, then skip the else-clause -- helps clarify the purpose. https://docs.python.org/3/reference/compound_stmts.html#the-for-statement else: # only if no break occurs > and then I would feel guilty for lying, because that comment is not, in > fact, correct. Returning out of the function from inside the loop will also > avoid running the else part, as will an exception. > I absolve you of guilt! :-) If you had written, "guaranteed to run if no break," then lawyers will come after you. If you had written "if and only if" some mathematicians might complain. As you wrote it, it's actually true. An "if and only if" logical statement has two parts: "if no break, run else-clause" and "if break, do not run else-clause". As you say, the first part is false. But you only made the latter claim.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-06-14 08:33 -0700 |
| Message-ID | <036dbf77-9483-4c71-a86b-f03cbf55cc3b@googlegroups.com> |
| In reply to | #109922 |
On Tuesday, June 14, 2016 at 8:13:53 AM UTC+5:30, Steven D'Aprano wrote: > No. The sun exploding was me gently mocking you for your comment disputing > the "unconditional" part. Yes, you are technically right that technically > the "else" block will only run if no "break" is reached, and no "return" is > reached, no exception is raised, also that os._exit or os.abort aren't > called, the CPU doesn't catch fire, and the world isn't destroyed. > > If we try to enumerate all the things which could prevent the "else" block > from running, we'll be here for decades. But, and this is the point that > everyone seems to have missed, * every single one of those things* is > completely independent of the for...else statement. > > *Including* the presence or absence of a "break". This is real wild: A break that is inside a for is independent of the for?!?! Thats about as meaningful a statement as saying that the algebraic expression "x² + 1" has a value independent of "x" However see below > > If you want to understand how Python statements work, you should understand > them in isolation (as much as possible), which then allows you to > extrapolate their behaviour in combination with other statements. Most > lines of Python code are understandable in isolation, or at least close to > isolation. You can get *very close* to a full understanding of Python by > just reading one line at a time (with perhaps a bit of short term memory to > remember if you are compiling a function, building a class, etc). > > E.g. you don't need to understand for loops to understand if...else. > > And vice versa: for...else has a well-defined meaning and operates in a > simple fashion in isolation of other language features. Its not compulsory > to put a "return" statement inside your for loop. Nor is it compulsory to > put a "raise" inside it. And "break" is not compulsory either. This *desire* for what you call isolation is a standard tenet of semantics and is right It is called compositionality Inn programming: https://en.wikipedia.org/wiki/Denotational_semantics#Compositionality More general linguistics: https://en.wikipedia.org/wiki/Principle_of_compositionality However gotos break compositionality unless one introduces heavy artillery like continuations And break is a euphemism for goto
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <lawrencedo99@gmail.com> |
|---|---|
| Date | 2016-06-14 16:27 -0700 |
| Message-ID | <e530f879-c57f-472c-a3f6-b8bfb2fb1cf0@googlegroups.com> |
| In reply to | #109934 |
On Wednesday, June 15, 2016 at 3:34:14 AM UTC+12, Rustom Mody wrote: > And break is a euphemism for goto Is this the old “structured-programming-is-mathematically-equivalent-to-gotos” red herring again?
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-06-14 18:29 -0700 |
| Message-ID | <11c8ce7a-d0f9-4fcd-98e6-65c40517dd4d@googlegroups.com> |
| In reply to | #109947 |
On Wednesday, June 15, 2016 at 4:58:05 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Wednesday, June 15, 2016 at 3:34:14 AM UTC+12, Rustom Mody wrote: > > > And break is a euphemism for goto > > Is this the old “structured-programming-is-mathematically-equivalent-to-gotos” red herring again? Are you familiar with Duff's device? https://en.wikipedia.org/wiki/Duff%27s_device
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-06-15 13:12 +1000 |
| Message-ID | <5760c795$0$1609$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #109934 |
On Wed, 15 Jun 2016 01:33 am, Rustom Mody wrote:
> On Tuesday, June 14, 2016 at 8:13:53 AM UTC+5:30, Steven D'Aprano wrote:
>> No. The sun exploding was me gently mocking you for your comment
>> disputing the "unconditional" part. Yes, you are technically right that
>> technically the "else" block will only run if no "break" is reached, and
>> no "return" is reached, no exception is raised, also that os._exit or
>> os.abort aren't called, the CPU doesn't catch fire, and the world isn't
>> destroyed.
>>
>> If we try to enumerate all the things which could prevent the "else"
>> block from running, we'll be here for decades. But, and this is the point
>> that everyone seems to have missed, * every single one of those things*
>> is completely independent of the for...else statement.
>>
>> *Including* the presence or absence of a "break".
>
> This is real wild: A break that is inside a for is independent of the
> for?!?!
If that's what I said, you would be right to question me. But that's not
what I said.
It is legal syntax to have for...else without a break, or a break inside a
for block with no else. And, if you really want to nitpick, you can even
have a break statement without a for. (Just stick it inside a while loop
instead.)
I know that's it's great fun to pick at nits without making a good faith
effort to communicate, but honestly Rustom, your following comments do
suggest that you understood what I was saying.
[...]
> This *desire* for what you call isolation is a standard tenet of
> semantics and is right
>
> It is called compositionality
>
> Inn programming:
> https://en.wikipedia.org/wiki/Denotational_semantics#Compositionality
>
> More general linguistics:
> https://en.wikipedia.org/wiki/Principle_of_compositionality
Thanks for that.
> However gotos break compositionality unless one introduces heavy artillery
> like continuations
>
> And break is a euphemism for goto
Sort of. A break is a jump, and a goto is a jump, but apart from that,
they're not really the same thing. A goto can jump (almost) anywhere.
Depending on the language, they can jump into the middle of functions, or
into the middle of loops. That's what makes them powerful enough to break
compositionality. But break can only jump to a single place: to the
statement that follows the for...else compound statement. It's more like a
return than a goto.
You can reason about for...else without the break, then reason about what
the break does. This isn't hard, and its what people do even in the common
use-case:
for x in seq:
process(x)
if condition:
break
else:
fnord()
spam()
"If the condition is never true, then we loop through seq, calling
process(x) each time, then call fnord(), then call spam(). If the condition
becomes true at some point in the loop, we stop looping, and go straight to
calling spam()."
We can reason about the condition is true case separately from the condition
is false case. And we can do so without imagining that there is an
invisible "did_not_break" flag, or needing a second mental model to
understand this ever-so-slightly more complex example:
for x in seq:
process(x)
if condition:
break
else:
foo()
else:
fnord()
spam()
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-06-14 20:38 -0700 |
| Message-ID | <27b3af95-7aa9-4800-ac25-dc6da6ac566e@googlegroups.com> |
| In reply to | #109950 |
On Wednesday, June 15, 2016 at 8:42:33 AM UTC+5:30, Steven D'Aprano wrote: > On Wed, 15 Jun 2016 01:33 am, Rustom Mody wrote: > > > On Tuesday, June 14, 2016 at 8:13:53 AM UTC+5:30, Steven D'Aprano wrote: > >> No. The sun exploding was me gently mocking you for your comment > >> disputing the "unconditional" part. Yes, you are technically right that > >> technically the "else" block will only run if no "break" is reached, and > >> no "return" is reached, no exception is raised, also that os._exit or > >> os.abort aren't called, the CPU doesn't catch fire, and the world isn't > >> destroyed. > >> > >> If we try to enumerate all the things which could prevent the "else" > >> block from running, we'll be here for decades. But, and this is the point > >> that everyone seems to have missed, * every single one of those things* > >> is completely independent of the for...else statement. > >> > >> *Including* the presence or absence of a "break". > > > > This is real wild: A break that is inside a for is independent of the > > for?!?! > > If that's what I said, you would be right to question me. But that's not > what I said. > > It is legal syntax to have for...else without a break, or a break inside a > for block with no else. And, if you really want to nitpick, you can even > have a break statement without a for. (Just stick it inside a while loop > instead.) > > I know that's it's great fun to pick at nits without making a good faith > effort to communicate, but honestly Rustom, your following comments do > suggest that you understood what I was saying. > > > [...] > > This *desire* for what you call isolation is a standard tenet of > > semantics and is right > > > > It is called compositionality > > > > Inn programming: > > https://en.wikipedia.org/wiki/Denotational_semantics#Compositionality > > > > More general linguistics: > > https://en.wikipedia.org/wiki/Principle_of_compositionality > > Thanks for that. > > > > However gotos break compositionality unless one introduces heavy artillery > > like continuations > > > > And break is a euphemism for goto > > Sort of. A break is a jump, and a goto is a jump, but apart from that, > they're not really the same thing. A goto can jump (almost) anywhere. > Depending on the language, they can jump into the middle of functions, or > into the middle of loops. That's what makes them powerful enough to break > compositionality. But break can only jump to a single place: to the > statement that follows the for...else compound statement. It's more like a > return than a goto. > > You can reason about for...else without the break, then reason about what > the break does. This isn't hard, and its what people do even in the common > use-case: > > for x in seq: > process(x) > if condition: > break > else: > fnord() > spam() Yon need to take an example of the if condition: break nested inside some more ifs with those other conditions giving validity to the condition eg outer condition being say y != 0 Inner if being if x/y == 0 : break Now you would see that your reasoning about the inner needs potentially the FULL CONTEXT of the outer. This need to carry large context is the essential property of non-compositional semantics.
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.python
csiph-web