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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-21 21:26 +1000 |
| Message-ID | <574045e1$0$22142$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108898 |
On Sat, 21 May 2016 04:03 pm, Marko Rauhamaa wrote: > 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. Yes, this! I might have issues with the keyword chosen, but the feature itself is very clever. Does anyone know of other languages that include the same feature? It's very rare for Python to innovate in language features. (I wonder if it came from ABC?) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2016-05-21 07:51 -0600 |
| Message-ID | <mailman.81.1463838736.27390.python-list@python.org> |
| In reply to | #108915 |
On Sat, May 21, 2016 at 5:26 AM, Steven D'Aprano <steve@pearwood.info> wrote: > Does anyone know of other languages that include the same feature? It's very > rare for Python to innovate in language features. > > (I wonder if it came from ABC?) According to Raymond Hettinger starting at about 15:50 in this video: http://pyvideo.org/video/1780/transforming-code-into-beautiful-idiomatic-pytho It was invented by Donald Knuth (including the choice of keyword).
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <grant.b.edwards@gmail.com> |
|---|---|
| Date | 2016-05-21 15:20 +0000 |
| Message-ID | <mailman.82.1463844030.27390.python-list@python.org> |
| In reply to | #108915 |
On 2016-05-21, Ian Kelly <ian.g.kelly@gmail.com> wrote: > On Sat, May 21, 2016 at 5:26 AM, Steven D'Aprano <steve@pearwood.info> wrote: > >> Does anyone know of other languages that include the same feature? >> It's very rare for Python to innovate in language features. >> >> (I wonder if it came from ABC?) > > According to Raymond Hettinger starting at about 15:50 in this > video: > > http://pyvideo.org/video/1780/transforming-code-into-beautiful-idiomatic-pytho > > It was invented by Donald Knuth (including the choice of keyword). If true, that alone dismisses with prejudice any question of changing it. As if backwards compatibility weren't a compelling enough argument. Besides which, I happen to think it makes sense the way it is. [I haven't been paying very close attention to this thread for a while, so I assume that "this feature" and "it" still refer to having an else clause in for/while loops?] I can't count the number of times I've wished C had such a feature, and have sometimes resorted to using a "goto" to get the same semantics in an easy to read/understand way. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2016-05-21 10:21 +1000 |
| Message-ID | <mailman.62.1463790109.27390.python-list@python.org> |
| In reply to | #108872 |
Steven D'Aprano <steve@pearwood.info> writes: > Just about the only things in Python which are intuitive and not > confusing to somebody are None and ints. I'll go even further: * The behaviour of ‘int’ is confusing to some. For example, to those who expect integers to produce fractions when divided. * The behaviour of ‘None’ is confusing to some. For example, to those who expect it to be a non-value, with no type. Examples of both those have appeared in this very forum in recent years. So, I think we can assert with confidence: if “avoid bevause it is unintuitive and confusing to some newcomers” were a good reason to avoid a Python feature, *all* Python features would be subject to oblivion. > 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. Yes. Appeals to intuition are irrelevant in talking about language features, IMO. The intuitions of newcomers should weigh heavily in language design. That is *not* the same as appealing to intuition: intuition gives you none of the essential and difficult concepts necessary to programming. > 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. This is not to say that every Python feature can be used without concern. Steven is not arguing that avoidance of a feature is never justified. Rather, he's demonstrating that *that particular justification* is void. There may be a good reason to avoid Python behaviour Foo, but “because JavaScript/Ruby/Lisp/BASIC/INTERCAL doesn't have behaviour Foo” is not a valid justification. The case must be argued on other merits, if any. -- \ “Special today: no ice cream.” —mountain inn, Switzerland | `\ | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-21 00:35 +0000 |
| Message-ID | <slrnnjvbhs.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108872 |
On 2016-05-20, Steven D'Aprano <steve@pearwood.info> wrote:
> By that logic, we ought to:
>
> - avoid using floats because their behaviour isn't intuitive and
> can be confusing;
To be fair, I'm very sympathetic to that argument. I think programming
languages should never magically produce floats out of nowhere unless
the programmer has explicitly done "import float" or "float('3.23')"
or somesuch. They're misunderstood so often that any convenience
they provide is outweighed by the danger they bring.
"(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
the Python 3 "2/3 ~= 0.6666" thing and regard it as a very retrograde
change.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-21 12:05 +1000 |
| Message-ID | <mailman.63.1463796315.27390.python-list@python.org> |
| In reply to | #108879 |
On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-05-20, Steven D'Aprano <steve@pearwood.info> wrote:
>> By that logic, we ought to:
>>
>> - avoid using floats because their behaviour isn't intuitive and
>> can be confusing;
>
> To be fair, I'm very sympathetic to that argument. I think programming
> languages should never magically produce floats out of nowhere unless
> the programmer has explicitly done "import float" or "float('3.23')"
> or somesuch. They're misunderstood so often that any convenience
> they provide is outweighed by the danger they bring.
>
> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
> the Python 3 "2/3 ~= 0.6666" thing and regard it as a very retrograde
> change.
The trouble is, what SHOULD 2/3 return?
* An integer? Makes a lot of sense to a C programmer. Not so much to
someone who is expecting a nonzero value. This isn't terrible (hey,
Python 2 managed with it no problem), but will definitely confuse a
number of people.
* A float? That's what we currently have. Not perfect, but it's going
to confuse less people than 0 will.
* A decimal.Decimal? That has its own issues (for instance, (x+y)/2
can return a value that isn't between x and y), and it still can't
represent two thirds properly.
* A fractions.Fraction? Well, at least that can perfectly represent a
ratio of integers. But it plays REALLY badly with other non-integer
types, and other operations than basic arithmetic (ever tried to take
the square root of a fraction?), so it's really only suited to
situations where you're working exclusively with fractions.
* Something else?
You say that Py3 making 1/10 => 0.1 was a "very retrograde change".
Why? Yes, now you're seeing floats; but would you be less surprised by
the Py2 version? Sure, Py2 has your little toy example working:
>>> (1/10) * (1/10) * 10 == (1/10)
True
but that's because 1/10 is zero, not because it's been represented
accurately! The biggest advantage of having integer division yield an
integer is that it forces people to think about their data types; but
since Python's float has a standing (core language support) that
Decimal and Fraction don't have, I don't think it's a problem. It's
the same with the complex type:
>>> 2 ** 0.5
1.4142135623730951
>>> (-2) ** 0.5
(8.659560562354934e-17+1.4142135623730951j)
Core data types will migrate between themselves as needed. (And this
proves some of the inherent inaccuracies in floating point arithmetic;
real number arithmetic says that the square root of -2 has a zero real
part.)
Interestingly, fractions.Fraction doesn't handle non-integer
exponentiation, and punts to float:
>>> fractions.Fraction(4) ** fractions.Fraction(2)
Fraction(16, 1)
>>> fractions.Fraction(4) ** fractions.Fraction(2, 3)
2.5198420997897464
>>> fractions.Fraction(4) ** fractions.Fraction(3, 2)
8.0
>>> fractions.Fraction(-4) ** fractions.Fraction(1, 2)
(1.2246467991473532e-16+2j)
Some data types just aren't well suited to certain operations.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-22 14:15 +0000 |
| Message-ID | <slrnnk3fv0.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108883 |
On 2016-05-21, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> To be fair, I'm very sympathetic to that argument. I think programming
>> languages should never magically produce floats out of nowhere unless
>> the programmer has explicitly done "import float" or "float('3.23')"
>> or somesuch. They're misunderstood so often that any convenience
>> they provide is outweighed by the danger they bring.
>>
>> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
>> the Python 3 "2/3 ~= 0.6666" thing and regard it as a very retrograde
>> change.
>
> The trouble is, what SHOULD 2/3 return?
>
> * An integer? Makes a lot of sense to a C programmer. Not so much to
> someone who is expecting a nonzero value. This isn't terrible (hey,
> Python 2 managed with it no problem), but will definitely confuse a
> number of people.
Yes, it should return an integer - and not because I think Python
should behave like C on principle, but because:
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
and floats are complicated.
> * A float? That's what we currently have. Not perfect, but it's going
> to confuse less people than 0 will.
That's a trap for those people though - it lulls them into thinking
that they understand what's going on, when in fact they don't,
because they don't understand floats, because almost nobody
understands floats. So they don't understand their program, and
- even worse - they don't know that they don't understand it.
Programming languages should do what they are told, and very little
more. They should not wander off on surprising jaunts of their own
invention out of the control of the programmer. It should be possible
to know and understand the language, or at least the subset of it
that you are likely to need for your everyday purposes. Floats are
generally not understood, so they shouldn't be suddenly turning up
un-called for.
Python generally sticks to this idea very well, which is one of the
things that I think make it an excellent programming language, so it
is a shame that in the Python 2 to Python 3 change when mistakes were
being rectified, a new one was introduced.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-05-22 17:58 +0300 |
| Message-ID | <87d1oe2l7z.fsf@elektro.pacujo.net> |
| In reply to | #108940 |
Jon Ribbens <jon+usenet@unequivocal.co.uk>: > On 2016-05-21, Chris Angelico <rosuav@gmail.com> wrote: >> The trouble is, what SHOULD 2/3 return? > > [...] > > Yes, it should return an integer - and not because I think Python > should behave like C on principle, but because: > > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > > and floats are complicated. Scheme has the best of both worlds: scheme@(guile-user)> 2/3 $1 = 2/3 scheme@(guile-user)> (exact->inexact $1) $2 = 0.6666666666666666 > That's a trap for those people though - it lulls them into thinking > that they understand what's going on, when in fact they don't, because > they don't understand floats, because almost nobody understands > floats. So they don't understand their program, and - even worse - > they don't know that they don't understand it. I don't understand this rant. Numeric programming is one of the oldest uses for computers. Rounding errors have been there since the beginning. If you think people have a hard time getting floats, integers are at least as hard to get. How about classes, closures, threads, asyncio...? Python ought to be the perfect language for seasoned experts. It doesn't need to be dumbed down for noobs. Marko
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-22 15:09 +0000 |
| Message-ID | <slrnnk3j43.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108941 |
On 2016-05-22, Marko Rauhamaa <marko@pacujo.net> wrote: > Jon Ribbens <jon+usenet@unequivocal.co.uk>: >> That's a trap for those people though - it lulls them into thinking >> that they understand what's going on, when in fact they don't, because >> they don't understand floats, because almost nobody understands >> floats. So they don't understand their program, and - even worse - >> they don't know that they don't understand it. > > I don't understand this rant. And I don't understand your use of the word "rant". > Numeric programming is one of the oldest uses for computers. > Rounding errors have been there since the beginning. If you think > people have a hard time getting floats, integers are at least as > hard to get. That is clearly nonsense. > How about classes, closures, threads, asyncio...? People don't tend to think of those as simple things that they already understand when they don't. Also, those things don't tend to turn up to the party uninvited.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-05-22 08:26 -0700 |
| Message-ID | <fe5b729a-652c-4842-b174-eb60003c87c5@googlegroups.com> |
| In reply to | #108941 |
On Sunday, May 22, 2016 at 8:28:39 PM UTC+5:30, Marko Rauhamaa wrote: > Python ought to be the perfect language for seasoned experts. It doesn't > need to be dumbed down for noobs. There's a language you may have heard of that you'll LOVE -- C++ Or maybe Haskell On a somewhat more serious note: Speaking of Haskell there has recently been a spate of dissent in the Haskell with people like Mark Lenctzer, Eric Meijer etc saying they are quitting Haskell because its too hard to teach. [These names in roughly python-equivalents are like say Raymond Hettinger and Nick Coghlan] I'd say python has done an eminently decent job so far in being approachable +powerful. But of late its losing the edge in the noob-side at the cost of catering to cognoscenti. IMHO Pascal got things right (wrt pedagogy) that are wronger and wronger in the last 30 years; see http://blog.languager.org/2015/06/functional-programming-moving-target.html On a different note: MIT has replaced scheme by python. Cause to celebrate?? Depends... If being able to do more with less understanding is good... well maybe
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-05-22 13:25 -0400 |
| Message-ID | <mailman.1.1463937929.20402.python-list@python.org> |
| In reply to | #108941 |
On Sun, May 22, 2016, at 10:58, Marko Rauhamaa wrote: > Scheme has the best of both worlds: > > scheme@(guile-user)> 2/3 > $1 = 2/3 > scheme@(guile-user)> (exact->inexact $1) > $2 = 0.6666666666666666 Why shouldn't Python do this? Imagine some future version of Python: >>> x = 2/3 >>> x (2/3) >>> type(x) <class 'rational'> # if it's going to be so integrated into the language it's # hardly sensible to keep calling it 'fractions.Fraction' >>> float(x) 0.6666666666666666 On Sun, May 22, 2016, at 11:52, Jon Ribbens wrote: > No, it *adheres* to the principle of least surprise. Floats appearing > out of nowhere is surprising. Python 2's behaviour adhered to the > principle, and Python 3's breaks it. Disregarding for the moment the particular imperfections of the float representation (which would be gone if we used Fraction instead), this is only true if the concrete types of results are regarded as part of the result rather than as an implementation detail for how best to return the requested value. I think it would be entirely reasonable for Fractions to not only appear out of nowhere, but to *disappear* when an operation on them yields a value which is an integer. Values are more important than types. Types are less important than values.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2016-05-22 10:34 -0700 |
| Message-ID | <d2f46c0e-6891-442a-8d9f-859903a61916@googlegroups.com> |
| In reply to | #108951 |
On Sunday, May 22, 2016 at 10:55:43 PM UTC+5:30, Random832 wrote: > Values are more important than types. Types are less important than > values. A stronger version that I occasionally tell my students: Values are in reality Types are in our heads Unfortunately we only know how to think thoughts inside our heads Which means we are stuck with the imperfections of our thinking apparatus
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-22 18:06 +0000 |
| Message-ID | <slrnnk3tfi.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108951 |
On 2016-05-22, Random832 <random832@fastmail.com> wrote: > On Sun, May 22, 2016, at 11:52, Jon Ribbens wrote: >> No, it *adheres* to the principle of least surprise. Floats appearing >> out of nowhere is surprising. Python 2's behaviour adhered to the >> principle, and Python 3's breaks it. > > Disregarding for the moment the particular imperfections of the float > representation (which would be gone if we used Fraction instead), this > is only true if the concrete types of results are regarded as part of > the result rather than as an implementation detail for how best to > return the requested value. > > I think it would be entirely reasonable for Fractions to not only appear > out of nowhere, but to *disappear* when an operation on them yields a > value which is an integer. > > Values are more important than types. Types are less important than > values. This would be true if we had some Grand Unified Lossless Number Type. Unfortunately, we don't, and we're not likely to any time soon.
[toc] | [prev] | [next] | [standalone]
| From | Random832 <random832@fastmail.com> |
|---|---|
| Date | 2016-05-22 14:17 -0400 |
| Message-ID | <mailman.4.1463941039.20402.python-list@python.org> |
| In reply to | #108955 |
On Sun, May 22, 2016, at 14:06, Jon Ribbens wrote: > This would be true if we had some Grand Unified Lossless Number Type. > Unfortunately, we don't, and we're not likely to any time soon. Scheme manages fine without one. It uses lossless types where it can, and lets you detect that an "inexact" number (which could be float, or could be any of the other types with an inexact flag set) was used where it can't.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2016-05-23 17:09 +1000 |
| Message-ID | <5742acc5$0$1590$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108951 |
On Monday 23 May 2016 03:25, Random832 wrote: > Why shouldn't Python do this? > > Imagine some future version of Python: >>>> x = 2/3 >>>> x > (2/3) >>>> type(x) > <class 'rational'> You would have a lot of trouble convincing Guido that this was a good idea, because that's what ABC used to do, and it was a performance killer, as well as being horrible to work with. Rationals like 2/3 are fine. But the trouble is, by the time you've done a handful of calculations, you've probably got something like 5529748264768821/18014398509481984 and after a few dozen calculations you might have something like: 391303115027894573050315966944902650883330501592661514878103414119479331609846605406995557395414953/14109433351889544757158673468211253755455976544516272594484740551000078367597300074881469573563940864 and it just keeps getting worse and worse. For bonus points, without converting to floats, can you tell which of of the two numbers is bigger by sight? -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-23 01:19 +1000 |
| Message-ID | <5741cde9$0$1587$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108940 |
On Mon, 23 May 2016 12:15 am, Jon Ribbens wrote:
> On 2016-05-21, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, May 21, 2016 at 10:35 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>> To be fair, I'm very sympathetic to that argument. I think programming
>>> languages should never magically produce floats out of nowhere unless
>>> the programmer has explicitly done "import float" or "float('3.23')"
>>> or somesuch. They're misunderstood so often that any convenience
>>> they provide is outweighed by the danger they bring.
>>>
>>> "(1/10) * (1/10) * 10 != (1/10)" anyone? I was distinctly unhappy with
>>> the Python 3 "2/3 ~= 0.6666" thing and regard it as a very retrograde
>>> change.
>>
>> The trouble is, what SHOULD 2/3 return?
>>
>> * An integer? Makes a lot of sense to a C programmer. Not so much to
>> someone who is expecting a nonzero value. This isn't terrible (hey,
>> Python 2 managed with it no problem), but will definitely confuse a
>> number of people.
>
> Yes, it should return an integer - and not because I think Python
> should behave like C on principle, but because:
>
> Explicit is better than implicit.
> Simple is better than complex.
> Complex is better than complicated.
>
> and floats are complicated.
How is this any better though? Complicated or not, people want to divide 1
by 2 and get 0.5. That is the functional requirement. Furthermore, they
want to use the ordinary division symbol / rather than having to import
some library or call a function.
Having 1/2 return 0 (as Python 2 does by default) doesn't make the language
any less complicated. It doesn't avoid the complexity of floats, it merely
breaks the principle of least surprise, and forces the programmer to add
what they consider to be an unnecessary ".0" to one or the other of the
operands.
Swapping to a base-10 float will be numerically even worse than the binary
floats we use now. Swapping to rationals add complexity and performance
issues. So whatever you do, there is complexity and annoyance.
>> * A float? That's what we currently have. Not perfect, but it's going
>> to confuse less people than 0 will.
>
> That's a trap for those people though - it lulls them into thinking
> that they understand what's going on, when in fact they don't,
> because they don't understand floats, because almost nobody
> understands floats. So they don't understand their program, and
> - even worse - they don't know that they don't understand it.
And how does forcing them to write 1.0/2 solve that?
Or (hypothetical) float.divide(1, 2) if you want to be even more
explicit :-)
> Programming languages should do what they are told, and very little
> more.
Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what
you've told it to do?
> They should not wander off on surprising jaunts of their own
> invention out of the control of the programmer. It should be possible
> to know and understand the language, or at least the subset of it
> that you are likely to need for your everyday purposes. Floats are
> generally not understood, so they shouldn't be suddenly turning up
> un-called for.
How are they uncalled for?
> Python generally sticks to this idea very well, which is one of the
> things that I think make it an excellent programming language, so it
> is a shame that in the Python 2 to Python 3 change when mistakes were
> being rectified, a new one was introduced.
*shrug*
I've programmed in Python using classic integer division and true division,
and in my experience and opinion, classic division is a real pain to work
with. You're forever having to cast things to float or write .0 literals
just to convince the interpreter to do division the way you expect.
I suppose some language some day might experiment with swapping the
operators, so that a/b is integer division and a//b is true division.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-23 01:32 +1000 |
| Message-ID | <mailman.0.1463931130.2313.python-list@python.org> |
| In reply to | #108943 |
On Mon, May 23, 2016 at 1:19 AM, Steven D'Aprano <steve@pearwood.info> wrote: > Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what > you've told it to do? That isn't the problem. With binary floats, 1/2 can be perfectly represented, so you have no trouble anywhere. The problem comes when you then try 1/5. What do you get? 3602879701896397/18014398509481984. Python shows that as 0.2. Then you do some more arithmetic, and the veil is pierced, and you discover that 1/5 doesn't actually return 0.2, but just something really really close to it - which it tells you is 0.2. I'm not saying that having 1/5 return 0 is better, but I'd like a broad acceptance that 0.2 is imperfect - that, in fact, *every* option is imperfect. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-05-22 18:50 +0300 |
| Message-ID | <8737pa2isc.fsf@elektro.pacujo.net> |
| In reply to | #108945 |
Chris Angelico <rosuav@gmail.com>: > On Mon, May 23, 2016 at 1:19 AM, Steven D'Aprano <steve@pearwood.info> wrote: >> Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what >> you've told it to do? > > That isn't the problem. With binary floats, 1/2 can be perfectly > represented, so you have no trouble anywhere. The problem comes when > you then try 1/5. What do you get? 3602879701896397/18014398509481984. > Python shows that as 0.2. Then you do some more arithmetic, and the > veil is pierced, and you discover that 1/5 doesn't actually return > 0.2, but just something really really close to it - which it tells you > is 0.2. > > I'm not saying that having 1/5 return 0 is better, but I'd like a > broad acceptance that 0.2 is imperfect - that, in fact, *every* option > is imperfect. Ah, that reminds me of an ancient joke: Ask an engineer what is two times two. He'll take out his slide rule, quickly move the slider and reply: "Approximately four." I remember learning my first programming language, Basic, when I was 16. One of the very first things to notice was the way "the computer" worked with approximations. Marko
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2016-05-22 15:52 +0000 |
| Message-ID | <slrnnk3ll1.krr.jon+usenet@wintry.unequivocal.co.uk> |
| In reply to | #108943 |
On 2016-05-22, Steven D'Aprano <steve@pearwood.info> wrote: > On Mon, 23 May 2016 12:15 am, Jon Ribbens wrote: >> Yes, it should return an integer - and not because I think Python >> should behave like C on principle, but because: >> >> Explicit is better than implicit. >> Simple is better than complex. >> Complex is better than complicated. >> >> and floats are complicated. > > How is this any better though? Complicated or not, people want to divide 1 > by 2 and get 0.5. That is the functional requirement. Furthermore, they > want to use the ordinary division symbol / rather than having to import > some library or call a function. That's a circular argument. You're defining the result as the requirement and then saying that proves the result is necessary. Clearly, people managed when 1/2 returned 0, and continue to do so today in Python 2 and other languages. > Having 1/2 return 0 (as Python 2 does by default) doesn't make the > language any less complicated. It doesn't avoid the complexity of > floats, it merely breaks the principle of least surprise, No, it *adheres* to the principle of least surprise. Floats appearing out of nowhere is surprising. Python 2's behaviour adhered to the principle, and Python 3's breaks it. >> That's a trap for those people though - it lulls them into thinking >> that they understand what's going on, when in fact they don't, >> because they don't understand floats, because almost nobody >> understands floats. So they don't understand their program, and >> - even worse - they don't know that they don't understand it. > > And how does forcing them to write 1.0/2 solve that? Because it forces them to consciously address the fact that they are asking for, and getting, floats, and that floats are not something the language is willingly to silently foist upon them. >> Programming languages should do what they are told, and very little >> more. > > Okay, now I'm confused. How is 1/2 returning 0.5 the language not doing what > you've told it to do? I didn't ask for floats, I got floats. That's how. >> They should not wander off on surprising jaunts of their own >> invention out of the control of the programmer. It should be possible >> to know and understand the language, or at least the subset of it >> that you are likely to need for your everyday purposes. Floats are >> generally not understood, so they shouldn't be suddenly turning up >> un-called for. > > How are they uncalled for? By... not being called for? I must admit I don't entirely understand your question.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2016-05-23 02:35 +1000 |
| Message-ID | <mailman.0.1463934926.20402.python-list@python.org> |
| In reply to | #108947 |
On Mon, May 23, 2016 at 1:52 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> That's a circular argument. You're defining the result as the
> requirement and then saying that proves the result is necessary.
> Clearly, people managed when 1/2 returned 0, and continue to do so
> today in Python 2 and other languages.
>
Python's int and float types are both approximations to a
non-representable type called a "real number". You learned about
numbers in your early childhood - you learned about the basic concepts
like addition (you have one apple here and one apple there, so you
have two apples), and division (you take those two apples and split
them between four people by cutting them both in half). If you ask
someone how much apple everyone gets when you divide one apple between
two people, the answer should be "half an apple". Not "no apples" - of
course there are situations where things are indivisible, but numbers
themselves aren't, because there are times when you can indeed halve
those apples just fine.
The problem is that computers can't actually represent real numbers.
We have to content ourselves with a variety of approximations, which
we call numeric data types. Python then treats those data types as
being a minor detail, and the underlying real number as important:
>>> 1 == 1.0 == (1+0j)
True
>>> {1.0: "foo"}[1]
'foo'
Now, there is the small problem that the numeric types can't be
arranged into a perfect tower. If Python's integer were restricted to
2**32, you could automatically upcast any integer to a float
losslessly, and you can already losslessly upcast a float to a complex
simply by adding 0j to it. But most people don't work with numbers big
enough to be unrepresentable in 64-bit IEEE floating point:
>>> (1<<53)+1
9007199254740993
>>> (1<<53)+1 == (1<<53)
False
>>> (1<<53)+1.0 == (1<<53)
True
So for *most people*, this treatment works perfectly. An int will
upcast to a float when you apply the division operator to it. An int
or float will upcast to complex when you apply the exponentiation
operator:
>>> (-4)**0.5
(1.2246467991473532e-16+2j)
Nearly everything stored in a computer is an abstraction that can
leak. In this case, we can't perfectly represent real numbers or
calculate with them, so we do the best we can. Binary floating point
is far from perfect in purity, but it's not bad in practicality.
Remind me what PEP 20 says about that? Gotcha.
ChrisA
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.python
csiph-web