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 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 20:55 +1000 |
| Message-ID | <57403e97$0$1608$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108911 |
On Sat, 21 May 2016 08:08 pm, Chris Angelico wrote:
> 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?
Who said it was required?
The docs say that `pass` is useful when a statement is required, not the
other way: you can put `pass` anywhere a statement can go, without it being
required.
> 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?").
Sure. Does that make it a bug? I don't think so. I think that a linter
should flag it as unnecessary code, but the compiler certainly shouldn't
prohibit it. And a human reviewer might be able to judge whether it belongs
or not.
Some people might not like "FIXME" or "XXX" comments to flag missing code,
and use `pass` statements as placeholders. Who are we to tell them they
shouldn't?
I think we agree that it's not the compiler's job to enforce good coding
standards.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-21 21:10 +1000 |
| Message-ID | <mailman.79.1463829033.27390.python-list@python.org> |
| In reply to | #108913 |
On Sat, May 21, 2016 at 8:55 PM, Steven D'Aprano <steve@pearwood.info> wrote: > I think we agree that it's not the compiler's job to enforce good coding > standards. Yep. I believe we are in (possibly belligerent) agreement. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Erik <python@lucidity.plus.com> |
|---|---|
| Date | 2016-05-21 08:20 +0100 |
| Message-ID | <mailman.72.1463815207.27390.python-list@python.org> |
| In reply to | #108849 |
On 20/05/16 01:06, Steven D'Aprano wrote:
> 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")
So why don't we consider if that should be a syntax error - "else"
clause on "for" loop with no "break" in its body? I know that doesn't
change your fundamental mental model, but it's a hint that it's wrong :)
As it's backwards-incompatible, it could be introduced using a
__future__ import (a precedent is 'generators' and the "yield" keyword
back in the day) which those who would like the new check could add to
the top of their sources.
But also, as you say, any instances of that construct in the wild is
almost certainly a bug, so it would be good to be able to test code
using a command-line or similar switch to turn on the behaviour by
default for testing existing bodies of code.
I notice that pylint complains about this (as a warning). Is there any
reason why this should _not_ just be considered an error and be done
with it?
E.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-05-21 11:37 +0300 |
| Message-ID | <8760u74xig.fsf@elektro.pacujo.net> |
| In reply to | #108900 |
Erik <python@lucidity.plus.com>:
> On 20/05/16 01:06, Steven D'Aprano wrote:
>> 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")
>
> So why don't we consider if that should be a syntax error - "else"
> clause on "for" loop with no "break" in its body? I know that doesn't
> change your fundamental mental model, but it's a hint that it's wrong
> :)
While we are at it, we should trigger a syntax error in these cases:
a = 0
b += a # pointless to add a 0
c = 1
d *= c # pointless to multiply by 1
if False: # pointless to test for truth in falsity
...
However, all of these "pointless" constructs crop up in real situations,
and artifically flagging them as errors would lead to unnecessary
frustration.
For example,
if False:
yield None
is the way to create a generator that doesn't generate any output.
Marko
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 20:39 +1000 |
| Message-ID | <57403ade$0$1593$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108900 |
On Sat, 21 May 2016 05:20 pm, Erik wrote:
> On 20/05/16 01:06, Steven D'Aprano wrote:
>
>> 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")
>
> So why don't we consider if that should be a syntax error - "else"
> clause on "for" loop with no "break" in its body? I know that doesn't
> change your fundamental mental model, but it's a hint that it's wrong :)
Just for the record, that's not my mental model *now*.
It took me a long time to work out what for...else was actually doing, but
some years ago I finally managed to do so. It's my argument that had the
keyword been "then" (implying that the `then` block is unconditionally
executed after the `for` block, which is the actual behaviour of the
interpreter) rather than "else" implying that it is an alternative to the
`for` block) I wouldn't have come up with the wrong mental model in the
first place. And I'm not the only one who has come up with the same, wrong,
model.
But you do ask a good question. Why isn't for...else with no break a syntax
error? I suppose it could be. But that's a *stylistic* question, and Python
generally treats that as "none of the compiler's business". It's not the
business of the compiler to enforce good code, only legal code. We can
legally write lots of code of questionable value:
while 0:
print("surprise!")
n = 1 + int(x) - 1
x = x
try:
something()
finally:
pass
without the compiler judging us and making it a syntax error. Why should
for...else be any different? The behaviour is perfectly well defined:
- first the `for` block runs, as many times as needed;
- then the `else` block runs, once.
Of course, the usual four keywords (continue, break, return, raise) will
change the order of execution by jumping to:
- the top of the for loop;
- past the for...else blocks;
- out of the current function;
- the nearest exception handler
respectively. But in the absence of a jump, for...else works as specified,
regardless of whether there is a break in it or not.
> As it's backwards-incompatible, it could be introduced using a
> __future__ import (a precedent is 'generators' and the "yield" keyword
> back in the day) which those who would like the new check could add to
> the top of their sources.
Sure, we *could* do this, but as I said, it does go against the usual
philosophy that the compiler shouldn't make judgements on what is good code
and what isn't.
> But also, as you say, any instances of that construct in the wild is
> almost certainly a bug,
I don't think it was me calling it a bug.
> so it would be good to be able to test code
> using a command-line or similar switch to turn on the behaviour by
> default for testing existing bodies of code.
I think that switch is called "use Pylint, PyChecker, Jedi or some other
opinionated linter or style-checker".
> I notice that pylint complains about this (as a warning). Is there any
> reason why this should _not_ just be considered an error and be done
> with it?
Because there's nothing actually broken with it.
There's lots of code which a human programmer would recognise as "silly",
or "wrong", but is well-defined and legal. Just because you can't think of
a reason to do something doesn't mean it should be prohibited.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Erik <python@lucidity.plus.com> |
|---|---|
| Date | 2016-05-21 21:48 +0100 |
| Message-ID | <mailman.89.1463863879.27390.python-list@python.org> |
| In reply to | #108912 |
On 21/05/16 11:39, Steven D'Aprano wrote:
> Just for the record, that's not my mental model *now*.
Sure. And I should have written "one's mental model" - the model of
anyone writing that code (not you personally) who thought the same at
the time.
> It took me a long time to work out what for...else was actually doing, but
> some years ago I finally managed to do so.
Coming from a partly assembler background, I happened to get it straight
away just because the thought of separate jump targets for the loop
condition being satisfied and breaking out of the loop being different
was quite natural (and a very nice feature to have in a high level
language!).
> But you do ask a good question. Why isn't for...else with no break a syntax
> error? I suppose it could be. But that's a *stylistic* question, and Python
> generally treats that as "none of the compiler's business". It's not the
> business of the compiler to enforce good code, only legal code.
On 21/05/16 08:29, Chris Angelico wrote:
> It's up to the linter, and ONLY the linter, to tell you about this.
Apologies for joining two threads here, but my reply is the same to
both, so it makes sense to me.
Let me tell you a story ;) <wibbly-wobbly-lines> Back in the mid-to-late
1980s I worked with C compilers on hardware that could take several
minutes to compile even a fairly trivial program. They errored on
syntactically incorrect code and happily compiled syntactically correct
code. Sometimes the output of the compiler wouldn't execute as expected
because of "undefined behaviour" of some parts of the language (which
the compilers could quite legally accept but would not produce valid
code for - even illegal ops are fair game at that point). They would
create valid code for the valid syntax of buggy code ("if (x = y) {
foo(); }") without a whimper.
At that time, we had a program called 'lint'. Every so often we might
run it on our sources and find all sorts of questionable behaviour that
our code might have that we should look harder at (such as that above).
We didn't run it all the time because it took so much longer to run than
the compiler itself.
Over time, some compilers started adding the checks and advisories that
"lint" gave to their messages. For some branded compilers ("Green
Hills", "SAS/C"), this even became a selling point. They started to do
this while still retaining the original compilation speed.
Things got faster, more was added to the compiler, and once the compiler
started to do everything it did and more, lint died(*).
</wibbly-wobbly-lines>
And now, today, the compilers all do far more than the original 'lint'
program did in almost zero time every time some source is compiled. It
is free; it is not something one has to remember to run every so often.
So, back to Python ;)
The responses of "we can all write suspect/bad/ineffectual code - so
just run the linter" takes me back those 30 years to when we HAD to do
that with our C code too ...
There must be a better way.
I realise that Python has the issue that sometimes the person doing the
compilation is the end user (by virtue of them executing a .py file), so
lint-style compiler warnings aren't really appropriate - and that's the
reason why I suggested a syntax error: I understand that it's not really
any such thing, but it's all I had to work with and it ensured such code
could not get as far as the end user.
So I guess my question is perhaps whether Python compilers should start
to go down the same path that C compilers did 30 years ago (by starting
to include some linter functionality) but in a way that only outputs the
messages to developers and not end users. Also, the current "pylint"
blurs the edges between style (identifier names) and questionable code
("for/else" with no "break").
E. <-- waiting to be shot down again.
(*) Though to be fair, there are now even more deeply checking
(commercial) static tools available, which effectively fill the gap that
'lint' used to.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-22 12:57 +1000 |
| Message-ID | <5741200d$0$1588$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108930 |
On Sun, 22 May 2016 06:48 am, Erik wrote:
> Let me tell you a story ;) <wibbly-wobbly-lines> Back in the mid-to-late
> 1980s I worked with C compilers on hardware that could take several
> minutes to compile even a fairly trivial program. They errored on
> syntactically incorrect code and happily compiled syntactically correct
> code. Sometimes the output of the compiler wouldn't execute as expected
> because of "undefined behaviour" of some parts of the language (which
> the compilers could quite legally accept but would not produce valid
> code for - even illegal ops are fair game at that point). They would
> create valid code for the valid syntax of buggy code ("if (x = y) {
> foo(); }") without a whimper.
Don't get me started about C and undefined behaviour.
Fortunately, Python has nothing even remotely like C undefined behaviour.
> At that time, we had a program called 'lint'.
[...]
> And now, today, the compilers all do far more than the original 'lint'
> program did in almost zero time every time some source is compiled. It
> is free; it is not something one has to remember to run every so often.
This is certainly not the case for Python. With C, you run your
compiler+linter once, and it builds an executable which can then run
without the compiler or linter.
With Python, *every time you run* the code, the compiler runs. The compiler
is the interpreter. It can, sometimes, skip some of the compilation steps
(parsing of source code) by use of cached byte-code files, but not all of
them. Including a linter will increase the size of the compiler
significantly, which much be distributed or installed for even the smallest
Python script, and it will have runtime implications re compilation time,
execution time, and memory use.
If you make the linter optional, say, a Python module that you install
separately and run only if you choose, then you have the status quo.
> So, back to Python ;)
>
> The responses of "we can all write suspect/bad/ineffectual code - so
> just run the linter" takes me back those 30 years to when we HAD to do
> that with our C code too ...
>
> There must be a better way.
Yes. And the better way is... don't write a language where you NEED a linter
because the language specification is so fecking *insane* that no human
being can reliably write correct code without running into undefined
behaviour which *can and will* have effects that propagate in both
directions, contaminating code which is correct in unpredictible ways.
https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/
One difference between C and Python is that most of the things which Python
linters look at don't actually have implications for correctness. Here are
a few of the features that Pylint looks at:
* line length;
* variable naming standards;
* unused imports;
* unnecessary semi-colons;
* use of deprecated modules;
and a complete list here:
http://pylint-messages.wikidot.com/all-codes
As you can see, most of the actual errors Pylint will pick up would result
in a runtime error, e,g, opening a file with an invalid mode. Most codes
are for code quality issues, related to maintenance issues, not bug
detection.
Coming back to for...else with no break, the behaviour is perfectly
well-defined, and does exactly what it is documented as doing. It's hard to
see that it is a "bug" for something to do what exactly what it is designed
to do. If somebody, for their own idiosyncratic reasons, wants to write:
for x in seq:
spam()
else:
eggs()
(Note: I've done this -- see below.)
and the language insists on a break, they will just pointlessly defeat the
compiler:
shutup_stupid_compiler = False
for x in seq:
if shutup_stupid_compiler: break
spam
else:
eggs
Thus entering an arms race where the compiler is seen as something to be
silenced rather than something that helps you.
I said that I've written for...else with no break. Why would I do such a
thing? Because I wanted to clearly mark that the code in the else was a
unit of code that went with the for-loop.
Code displays varying levels of cohesiveness. Python lets you group related
code in four levels:
- the function/method;
- the class;
- the module;
- the package
but sometimes you have code which is smaller than a function that needs to
be considered as a unit, but is not enough to justify putting it into a
function. When that happens, we usually delimit it with comments, or
sometimes even just a blank line:
code
that
goes
together
different
bunch
of
code
that
goes
together
So, when I had a bunch of code that included a for-loop, and something
immediately after the for-loop, I could have written:
for x in seq:
block
code that goes
with the loop
different bunch
of code
but I thought it communicated the grouping better to write it as:
for x in seq:
block
else: # runs after the for
code that goes
with the loop
different bunch
of code
I've since changed my mind. That's too subtle and too idiosyncratic for my
liking. It clashes with the keyword "else", which I maintain is badly
named. If it was named "next", which I maintain describes what it does much
better, then things might be different, but given the status quo, I've gone
back to doing it the old-fashioned way, with a comment.
But the point is, that's a matter of *taste*, not a matter for the compiler.
If somebody else wanted to do it my way, well, that's between them and
whoever else works on their code.
You probably wouldn't want the compiler to raise a syntax error because you
put a blank line or a comment somewhere the compiler writer disapproved
off. For example, some people insist that the first line of code must
follow immediately after the docstring, some prefer to leave a blank line:
def spam():
"""Docs"""
code
def eggs():
"""Docs"""
code
Your suggestion to raise a syntax error in the case of for...else without
break strikes me as no different from the idea that we should raise a
syntax error if there is/isn't a blank line after the docstring. (Choose
one.)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Michael Selik <michael.selik@gmail.com> |
|---|---|
| Date | 2016-05-22 02:55 +0000 |
| Message-ID | <mailman.90.1463885758.27390.python-list@python.org> |
| In reply to | #108912 |
On Sat, May 21, 2016, 4:52 PM Erik <python@lucidity.plus.com> wrote: > So I guess my question is perhaps whether Python compilers should start > to go down the same path that C compilers did 30 years ago (by starting > to include some linter functionality) > Well, there's that whole optional type hints thing. You should be asking how to preserve Python's simplicity while adding more static analysis features. >
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-21 17:29 +1000 |
| Message-ID | <mailman.73.1463815762.27390.python-list@python.org> |
| In reply to | #108849 |
On Sat, May 21, 2016 at 5:20 PM, Erik <python@lucidity.plus.com> wrote:
> On 20/05/16 01:06, Steven D'Aprano wrote:
>
>> 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")
>
>
> So why don't we consider if that should be a syntax error - "else" clause on
> "for" loop with no "break" in its body? I know that doesn't change your
> fundamental mental model, but it's a hint that it's wrong :)
>
> As it's backwards-incompatible, it could be introduced using a __future__
> import (a precedent is 'generators' and the "yield" keyword back in the day)
> which those who would like the new check could add to the top of their
> sources.
>
> But also, as you say, any instances of that construct in the wild is almost
> certainly a bug, so it would be good to be able to test code using a
> command-line or similar switch to turn on the behaviour by default for
> testing existing bodies of code.
>
> I notice that pylint complains about this (as a warning). Is there any
> reason why this should _not_ just be considered an error and be done with
> it?
Because it's not the language parser's job to decide what's "sensible"
and what's "not sensible". That's a linter's job. Some things
fundamentally can't work, but others work fine and might just be
not-very-useful - for example:
def f(x):
x if x <= 2 else x * f(x-1)
This is syntactically-legal Python code, but it probably isn't doing
what you want it to (in Python, a bare final expression does NOT
become the function's return value, although that does happen in other
languages). A linter should look at this and give a warning (even if
the else part has side effects, the first part can't, and the
condition shouldn't), but the language will happily evaluate it (this
example from CPython 3.6):
>>> dis.dis(f)
2 0 LOAD_FAST 0 (x)
3 LOAD_CONST 1 (2)
6 COMPARE_OP 1 (<=)
9 POP_JUMP_IF_FALSE 18
12 LOAD_FAST 0 (x)
15 JUMP_FORWARD 17 (to 35)
>> 18 LOAD_FAST 0 (x)
21 LOAD_GLOBAL 0 (f)
24 LOAD_FAST 0 (x)
27 LOAD_CONST 2 (1)
30 BINARY_SUBTRACT
31 CALL_FUNCTION 1 (1 positional, 0 keyword pair)
34 BINARY_MULTIPLY
>> 35 POP_TOP
36 LOAD_CONST 0 (None)
39 RETURN_VALUE
So, yes, this function might load up the value of x (position 12),
then jump to 35 and discard that value, before unconditionally
returning None. Not a problem. It's up to the linter, and ONLY the
linter, to tell you about this.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Bob Martin <bob.martin@excite.com> |
|---|---|
| Date | 2016-05-20 07:45 +0100 |
| Message-ID | <dq7q4bF7csmU1@mid.individual.net> |
| In reply to | #108835 |
in 759855 20160519 185500 Jon Ribbens <jon+usenet@unequivocal.co.uk> wrote: >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. Yes. "else" and "then" have opposite meanings.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-20 06:01 +1000 |
| Message-ID | <mailman.39.1463688090.27390.python-list@python.org> |
| In reply to | #108834 |
On Fri, May 20, 2016 at 3:46 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> The idea of finally is
> that it executes no matter what happens[1].
>
> [1] Well, *almost* no matter what. If you pull the power from the computer,
> the finally block never gets a chance to run.
Nor if you kill -9 the process, or get into an infinite loop, or any
number of other things. Specifically, what the finally block
guarantees is that it will be executed *before any code following the
try block*. In this example:
try:
code1
except Exception:
code2
else:
code3
finally:
code4
code5
Once you hit code1, you are absolutely guaranteed that code5 *will
not* be run prior to code4.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2016-05-19 14:11 -0600 |
| Message-ID | <mailman.40.1463688744.27390.python-list@python.org> |
| In reply to | #108834 |
On Thu, May 19, 2016 at 2:01 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Fri, May 20, 2016 at 3:46 AM, Steven D'Aprano <steve@pearwood.info> wrote: >> The idea of finally is >> that it executes no matter what happens[1]. >> >> [1] Well, *almost* no matter what. If you pull the power from the computer, >> the finally block never gets a chance to run. > > Nor if you kill -9 the process, or get into an infinite loop, or any > number of other things. Specifically, what the finally block > guarantees is that it will be executed *before any code following the > try block*. In this example: > > try: > code1 > except Exception: > code2 > else: > code3 > finally: > code4 > code5 > > Once you hit code1, you are absolutely guaranteed that code5 *will > not* be run prior to code4. The guarantee is stronger than that. It's possible to exit the try block without passing execution to code5 at all. The finally block is still guaranteed to be executed in this case.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-20 06:27 +1000 |
| Message-ID | <mailman.41.1463689669.27390.python-list@python.org> |
| In reply to | #108834 |
On Fri, May 20, 2016 at 6:11 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Thu, May 19, 2016 at 2:01 PM, Chris Angelico <rosuav@gmail.com> wrote: >> On Fri, May 20, 2016 at 3:46 AM, Steven D'Aprano <steve@pearwood.info> wrote: >>> The idea of finally is >>> that it executes no matter what happens[1]. >>> >>> [1] Well, *almost* no matter what. If you pull the power from the computer, >>> the finally block never gets a chance to run. >> >> Nor if you kill -9 the process, or get into an infinite loop, or any >> number of other things. Specifically, what the finally block >> guarantees is that it will be executed *before any code following the >> try block*. In this example: >> >> try: >> code1 >> except Exception: >> code2 >> else: >> code3 >> finally: >> code4 >> code5 >> >> Once you hit code1, you are absolutely guaranteed that code5 *will >> not* be run prior to code4. > > The guarantee is stronger than that. It's possible to exit the try > block without passing execution to code5 at all. The finally block is > still guaranteed to be executed in this case. Yes, but I don't know how to depict "other code outside of the try block" in a way that doesn't fall foul of other nitpicks like "well, you could call that function from within the try block" :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2016-05-20 11:51 +1200 |
| Message-ID | <dq71srF3j00U1@mid.individual.net> |
| In reply to | #108830 |
Herkermer Sherwood wrote: > But there is already a reserved keyword that would work great here. > "finally". > > 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 using "finally" this way would be more confusing than the status quo. Currently, if you see a "finally" somewhere, it means the block following is always executed come what may. But with this change, you would need to look up some arbitrary distance to see whether it belonged to a "try" or a "for". It's not so bad with "else" because you need to look back to find out what condition the "else" refers to anyway. -- Greg \
[toc] | [prev] | [next] | [standalone]
| From | Erik <python@lucidity.plus.com> |
|---|---|
| Date | 2016-05-20 09:09 +0100 |
| Message-ID | <mailman.47.1463731949.27390.python-list@python.org> |
| In reply to | #108848 |
On 20/05/16 00:51, Gregory Ewing wrote:
> It's not so bad with "else" because you need to look back
> to find out what condition the "else" refers to anyway.
With my tongue only slightly in my cheek, if it was desirable to
"fix"/clarify this syntax then I would suggest adding some optional
(existing) trailing keywords to 'else' in this context that spells it out:
for item in seq:
if foo(item):
break
else if not break:
nomatch()
I would rule out "elif not break" - this is just about adding additional
trailing words to existing syntax to spell it out (which might be a good
teaching aid as well as turn into personal preferred style).
I guess that it _could_ be a syntax error to reference "break" if the
for/while loop does not contain the keyword in its body - this could
actually address one of the "confusing" things mentioned in this thread,
like:
seq = []
for item in seq:
pass
else if not break:
pass
# Syntax error - "break" referenced in "for/else" clause but not present
in loop body.
Someone also pointed out that there are other flow control mechanisms
that could prevent the 'else' from being executed: "return" and "raise".
One could extend the above to allow one or more of those to be specified:
else if not break or return or raise:
That looks like a lot of noise, but again it could help make code more
explicit (both to the human reader, and to a compile-time check):
for item in seq:
if foo(item):
break
if bar(item):
return
else if not return:
pass
# Syntax error - extended "for/else" clause does not reference "break",
which exists in loop body.
I would _not_ suggest that the above should ever mean "if it doesn't
return, this code is executed regardless of whether 'break' happened" -
one would remove the 'else' clause altogether for that.
"raise" is more problematic as an exception can always be raised by
pretty much _anything_ in the body without the keyword being present.
Perhaps "or raise" is just a completely benign, optional keyword for the
completists. Or perhaps it's simply not mentioned at all and is always
implied (as is true of exceptions in other constructs such as plain
"if/else", and just generally).
The additional keywords would effectively just be a static checked
filter - the original bare "else" would effectively mean "else if not
any_flow_control_out_of_the_loop" (which is what it means today).
In summary: Adding the "if not" extension is the suggestion, with
"break" as the filter. "return" as an additional filter is a possibility
which may add something, "raise" as an additional filter is a
possibility which probably doesn't add anything (and may actually be
distracting).
I'm not entirely sure if _I_ like this yet (there are some things I've
suggested that I like and some I'm not sure about and some I don't like
but I've mentioned them anyway) - I'm just throwing it out there ;)
E.
[toc] | [prev] | [next] | [standalone]
| From | Zachary Ware <zachary.ware+pylist@gmail.com> |
|---|---|
| Date | 2016-05-20 10:59 -0500 |
| Message-ID | <mailman.54.1463760022.27390.python-list@python.org> |
| In reply to | #108848 |
On Fri, May 20, 2016 at 3:09 AM, Erik <python@lucidity.plus.com> wrote:
> On 20/05/16 00:51, Gregory Ewing wrote:
>>
>> It's not so bad with "else" because you need to look back
>> to find out what condition the "else" refers to anyway.
>
>
> With my tongue only slightly in my cheek, if it was desirable to
> "fix"/clarify this syntax then I would suggest adding some optional
> (existing) trailing keywords to 'else' in this context that spells it out:
>
> for item in seq:
> if foo(item):
> break
> else if not break:
> nomatch()
With tongue firmly cheeked, you can always use the special `:#` operator:
for item in seq:
if foo(item):
break
else:# if no break:
nomatch()
This has the benefit that you can use whatever syntax you like after
the `:#`, and use it in any version of Python you want.
--
Zach
[toc] | [prev] | [next] | [standalone]
| From | Christopher Reimer <christopher_reimer@icloud.com> |
|---|---|
| Date | 2016-05-20 12:20 -0700 |
| Message-ID | <mailman.57.1463775663.27390.python-list@python.org> |
| In reply to | #108848 |
On 5/20/2016 8:59 AM, Zachary Ware wrote: > On Fri, May 20, 2016 at 3:09 AM, Erik <python@lucidity.plus.com> wrote: >> On 20/05/16 00:51, Gregory Ewing wrote: >>> It's not so bad with "else" because you need to look back >>> to find out what condition the "else" refers to anyway. >> >> With my tongue only slightly in my cheek, if it was desirable to >> "fix"/clarify this syntax then I would suggest adding some optional >> (existing) trailing keywords to 'else' in this context that spells it out: >> >> for item in seq: >> if foo(item): >> break >> else if not break: >> nomatch() > With tongue firmly cheeked, you can always use the special `:#` operator: > > for item in seq: > if foo(item): > break > else:# if no break: > nomatch() > > This has the benefit that you can use whatever syntax you like after > the `:#`, and use it in any version of Python you want. According to "Effective Python: 59 Specific Ways to Write Better Python" by Brett Slatkin, Item 12 recommends against using the else block after for and while loops (see page 25): "Avoid using else blocks after loops because their behavior isn't intuitive and can be confusing." Until I read the book, I wasn't aware of this feature (or bug). Doesn't seem like a feature I would use since it's not commonly found in other programming languages. As the author demonstrates in his book, I would probably write a helper function instead. Item 13 does recommend using the else block for try/except/else/finally in exception handling. :) Thank you, Chris R.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 08:43 +1000 |
| Message-ID | <573f9322$0$1616$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108867 |
On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote: > According to "Effective Python: 59 Specific Ways to Write Better Python" > by Brett Slatkin, Item 12 recommends against using the else block after > for and while loops (see page 25): "Avoid using else blocks after loops > because their behavior isn't intuitive and can be confusing." By that logic, we ought to: - avoid using floats because their behaviour isn't intuitive and can be confusing; - avoid using lists because their behaviour isn't intuitive and can be confusing; - avoid using classes because their behaviour isn't intuitive and can be confusing; - avoid any form of asynchronous functions because their behaviour isn't intuitive and can be confusing; and so on. I can give examples of unintuitive and confusing behaviour for all of those things, and more, except the last. And the reason I can't give examples for async programming is because it confuses me and I don't understand it well enough to give even a minimal example. Just about the only things in Python which are intuitive and not confusing to somebody are None and ints. Or, we can *learn how to use the features* and stop thinking that programming is a matter of intuition. And most importantly, stop thinking that features need to be judged entirely by the least knowledgeable programmers. > Until I read the book, I wasn't aware of this feature (or bug). Doesn't > seem like a feature I would use since it's not commonly found in other > programming languages. As the author demonstrates in his book, I would > probably write a helper function instead. Sorry, was that called "Ineffective Python"? There is absolutely nothing effective about re-inventing the wheel badly or writing unnecessary code. Are you programming in those other languages or in Python? If you're programming in, say, Javascript, I can completely understand you deciding to limit yourself to features available in Javascript. Indeed to try to use Python language features in Javascript would be an exercise in frustration. Likewise using Ruby language features in Python is nothing but SyntaxError after SyntaxError, it makes it hard to get work done. But the idea that you should avoid a Python feature while programming in Python because Javascript doesn't have it, or Ruby, or C, is surely the height of muddleheaded thinking. You're not programming Javascript, Ruby or C, you're programming in Python. The whole point of picking one language over another is to get access to the tools and features that language offers. Otherwise you're just wasting your time. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | theherk@gmail.com |
|---|---|
| Date | 2016-05-20 16:24 -0700 |
| Message-ID | <aa52aa7b-2e26-46a5-a78e-c65bb4036d91@googlegroups.com> |
| In reply to | #108872 |
You seem to have missed the point. Nobody is suggesting, I don't believe, that all of a language should be intuitive. Rather that if any part of it is unnecessarily counter-intuitive, it may be worth looking for a better solution. Python is a very well designed language when it comes to in linguistic presentation. In this case however, it is not only unintuitive but counter-intuitive. The original question was simply, "Is it better to follow the semantics used elsewhere in the language, or have the language itself make sense semantically?" So, it is better to leave counter-intuitive constructs so they are consistent across the language or try to make each keyword make semantic sense where it is used? On Friday, May 20, 2016 at 3:43:58 PM UTC-7, Steven D'Aprano wrote: > On Sat, 21 May 2016 05:20 am, Christopher Reimer wrote: > > > According to "Effective Python: 59 Specific Ways to Write Better Python" > > by Brett Slatkin, Item 12 recommends against using the else block after > > for and while loops (see page 25): "Avoid using else blocks after loops > > because their behavior isn't intuitive and can be confusing." > > By that logic, we ought to: > > - avoid using floats because their behaviour isn't intuitive and > can be confusing; > - avoid using lists because their behaviour isn't intuitive and > can be confusing; > - avoid using classes because their behaviour isn't intuitive and > can be confusing; > - avoid any form of asynchronous functions because their behaviour > isn't intuitive and can be confusing; > > and so on. I can give examples of unintuitive and confusing behaviour for > all of those things, and more, except the last. And the reason I can't give > examples for async programming is because it confuses me and I don't > understand it well enough to give even a minimal example. > > Just about the only things in Python which are intuitive and not confusing > to somebody are None and ints. > > Or, we can *learn how to use the features* and stop thinking that > programming is a matter of intuition. And most importantly, stop thinking > that features need to be judged entirely by the least knowledgeable > programmers. > > > > Until I read the book, I wasn't aware of this feature (or bug). Doesn't > > seem like a feature I would use since it's not commonly found in other > > programming languages. As the author demonstrates in his book, I would > > probably write a helper function instead. > > Sorry, was that called "Ineffective Python"? > > There is absolutely nothing effective about re-inventing the wheel badly or > writing unnecessary code. > > Are you programming in those other languages or in Python? If you're > programming in, say, Javascript, I can completely understand you deciding > to limit yourself to features available in Javascript. Indeed to try to use > Python language features in Javascript would be an exercise in frustration. > Likewise using Ruby language features in Python is nothing but SyntaxError > after SyntaxError, it makes it hard to get work done. > > But the idea that you should avoid a Python feature while programming in > Python because Javascript doesn't have it, or Ruby, or C, is surely the > height of muddleheaded thinking. You're not programming Javascript, Ruby or > C, you're programming in Python. The whole point of picking one language > over another is to get access to the tools and features that language > offers. Otherwise you're just wasting your time. > > > > -- > Steven
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-05-21 09:03 +0300 |
| Message-ID | <87d1og3q33.fsf@elektro.pacujo.net> |
| In reply to | #108873 |
theherk@gmail.com: > You seem to have missed the point. Nobody is suggesting, I don't > believe, that all of a language should be intuitive. Rather that if > any part of it is unnecessarily counter-intuitive, it may be worth > looking for a better solution. Python is a very well designed language > when it comes to in linguistic presentation. In this case however, it > is not only unintuitive but counter-intuitive. The for-else construct is a highly practical feature. It is in no way inherently counter-intuitive. As any new thing, it needs to be learned and used to be appreciated. Marko
[toc] | [prev] | [next] | [standalone]
Page 2 of 15 — ← Prev page 1 [2] 3 4 … 15 Next page →
Back to top | Article view | comp.lang.python
csiph-web