Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #84181 > unrolled thread
| Started by | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| First post | 2015-01-22 15:30 +1100 |
| Last post | 2015-01-30 02:11 +0000 |
| Articles | 20 on this page of 277 — 34 participants |
Back to article view | Back to comp.lang.python
Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-22 15:30 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 15:43 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-21 21:35 -0800
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-21 21:56 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 06:12 +0000
Re: Python is DOOMED! Again! Nicholas Cole <nicholas.cole@gmail.com> - 2015-01-22 05:50 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 16:56 +1100
Re: Python is DOOMED! Again! Ethan Furman <ethan@stoneleaf.us> - 2015-01-21 22:02 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-22 18:23 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 09:10 +0100
Re: Python is DOOMED! Again! Nicholas Cole <nicholas.cole@gmail.com> - 2015-01-22 09:37 +0000
Re: Python is DOOMED! Again! alex23 <wuwei23@gmail.com> - 2015-01-23 20:10 +1000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 21:09 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 10:37 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 21:44 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 11:06 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 12:24 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 01:57 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 02:13 +1100
Python is DOOMED! Again! Nicholas Cole <nicholas.cole@gmail.com> - 2015-01-22 10:46 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 21:50 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 11:12 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 23:14 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 01:16 +1100
Re: Python is DOOMED! Again! Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-01-22 14:33 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 02:11 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 21:59 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 22:38 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 17:35 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-24 14:42 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 03:00 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-25 03:27 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 04:31 +1100
Re: Python is DOOMED! Again! Tim Chase <python.list@tim.thechases.com> - 2015-01-24 12:46 -0600
Re: Python is DOOMED! Again! Rustom Mody <rustompmody@gmail.com> - 2015-01-24 10:59 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-25 13:22 +1100
Re: Python is DOOMED! Again! alister <alister.nospam.ware@ntlworld.com> - 2015-01-24 21:14 +0000
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-24 14:51 -0700
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-24 23:30 +0100
Re: Python is DOOMED! Again! BartC <bc@freeuk.com> - 2015-01-26 17:00 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-27 11:22 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:25 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 19:56 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 12:41 +1100
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-22 14:24 -0700
Re: Python is DOOMED! Again! Rustom Mody <rustompmody@gmail.com> - 2015-01-22 18:59 -0800
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-23 00:11 -0800
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-23 09:28 -0700
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 16:37 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:23 -0800
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 00:42 -0800
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-01-22 12:05 +0200
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-22 21:13 +1100
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 18:11 +0000
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 10:31 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 12:23 -0800
Re: Python is DOOMED! Again! MRAB <python@mrabarnett.plus.com> - 2015-01-22 20:46 +0000
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 22:06 +0100
Re: Python is DOOMED! Again! albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-02-08 00:45 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-08 12:01 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-08 18:55 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-08 19:21 +1100
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-08 01:31 -0700
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-02-08 12:17 +0200
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 06:22 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-21 22:25 -0800
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-21 22:48 -0800
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 00:24 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 08:40 +0000
Re: Python is DOOMED! Again! Grant Edwards <invalid@invalid.invalid> - 2015-01-23 03:40 +0000
Re: Python is DOOMED! Again! Terry Reedy <tjreedy@udel.edu> - 2015-01-22 14:20 -0500
Re: Python is DOOMED! Again! Nicholas Cole <nicholas.cole@gmail.com> - 2015-01-22 07:40 +0000
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 09:10 +0000
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 18:03 +0000
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-01-22 21:08 +0200
Re: Python is DOOMED! Again! wxjmfauth@gmail.com - 2015-01-23 01:19 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 16:34 +1100
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-22 12:14 -0600
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 12:38 -0800
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 18:23 +0000
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 18:28 +0000
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-01-22 21:16 +0200
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-22 11:36 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 11:16 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-23 06:29 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 12:44 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 20:50 +0000
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 23:25 +0100
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 17:06 -0800
Re: Python is DOOMED! Again! Terry Reedy <tjreedy@udel.edu> - 2015-01-22 22:59 -0500
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 15:23 +1100
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-23 19:00 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 18:48 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-24 09:30 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-24 15:20 -0800
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-25 10:30 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-25 00:39 +0100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-25 10:44 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-24 23:55 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-24 17:00 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-25 02:28 +0000
Re: Python is DOOMED! Again! wxjmfauth@gmail.com - 2015-01-25 10:57 -0800
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-26 10:01 -0500
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-27 11:11 +1100
Re: Python is DOOMED! Again! Dan Sommers <dan@tombstonezero.net> - 2015-01-27 01:09 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-27 17:36 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-27 18:59 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-27 19:03 +1100
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-27 12:26 -0500
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-27 17:40 +0000
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-26 17:10 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve@pearwood.info> - 2015-01-27 06:32 +0000
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-27 12:35 -0500
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-27 12:37 -0500
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-27 18:59 +0100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-28 07:40 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-27 21:58 +0100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-28 08:08 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:19 +0100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-28 08:24 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:35 +0100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-27 22:39 +0100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-28 08:53 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 13:05 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 12:26 +1100
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-28 08:10 -0600
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-28 16:04 +0100
Re: Python is DOOMED! Again! wxjmfauth@gmail.com - 2015-01-28 07:40 -0800
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-28 10:33 -0700
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-29 11:37 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-29 11:43 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-29 09:34 +0100
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-29 09:30 -0700
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-30 03:41 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-28 18:16 +0000
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-29 09:23 +0100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-29 08:49 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-30 03:11 +1100
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-29 13:12 -0800
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-30 19:36 +0100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 14:06 +1100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-30 19:42 +0100
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-30 14:50 -0700
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-28 12:34 -0600
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-28 12:36 -0600
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-29 09:08 -0500
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-30 02:56 +1100
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-29 13:23 -0500
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-31 22:56 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-01 01:53 +1100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-01 14:16 +1100
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-01 14:46 +1100
Re: Python is DOOMED! Again! Ethan Furman <ethan@stoneleaf.us> - 2015-01-31 20:31 -0800
dunder-docs (was Python is DOOMED! Again!) Rustom Mody <rustompmody@gmail.com> - 2015-01-31 21:36 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Ethan Furman <ethan@stoneleaf.us> - 2015-02-01 00:12 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:20 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:55 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-01 10:31 -0700
Re: dunder-docs (was Python is DOOMED! Again!) Rustom Mody <rustompmody@gmail.com> - 2015-02-01 19:52 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Rustom Mody <rustompmody@gmail.com> - 2015-02-01 20:04 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Rustom Mody <rustompmody@gmail.com> - 2015-02-01 20:22 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-02 17:55 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 18:15 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-01 23:41 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 23:06 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 23:09 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 00:58 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-02 05:00 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-03 01:07 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-03 01:24 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Marko Rauhamaa <marko@pacujo.net> - 2015-02-03 12:38 +0200
Re: dunder-docs (was Python is DOOMED! Again!) Chris Angelico <rosuav@gmail.com> - 2015-02-03 21:49 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Marko Rauhamaa <marko@pacujo.net> - 2015-02-03 13:27 +0200
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 10:12 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Marko Rauhamaa <marko@pacujo.net> - 2015-02-03 23:28 +0200
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 11:43 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Marko Rauhamaa <marko@pacujo.net> - 2015-02-04 01:32 +0200
Re: dunder-docs (was Python is DOOMED! Again!) Chris Angelico <rosuav@gmail.com> - 2015-02-04 10:39 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-02-03 23:41 +0000
Re: dunder-docs (was Python is DOOMED! Again!) Ethan Furman <ethan@stoneleaf.us> - 2015-02-03 15:55 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-04 13:30 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-04 12:57 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 19:04 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-04 04:40 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 10:39 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-03 15:04 -0700
Re: dunder-docs (was Python is DOOMED! Again!) Rick Johnson <rantingrickjohnson@gmail.com> - 2015-02-03 18:31 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Chris Angelico <rosuav@gmail.com> - 2015-02-04 09:19 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-04 13:30 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-04 15:58 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 19:22 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 19:22 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-02 05:02 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-03 01:20 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-03 01:25 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-04 00:32 +1300
Re: dunder-docs (was Python is DOOMED! Again!) Vito De Tullio <vito.detullio@gmail.com> - 2015-02-02 06:26 +0100
Re: dunder-docs (was Python is DOOMED! Again!) Rustom Mody <rustompmody@gmail.com> - 2015-02-02 04:27 -0800
Re: dunder-docs (was Python is DOOMED! Again!) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 23:43 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Chris Angelico <rosuav@gmail.com> - 2015-02-02 07:45 +1100
Re: dunder-docs (was Python is DOOMED! Again!) Emile van Sebille <emile@fenx.com> - 2015-02-01 12:51 -0800
Re: Python is DOOMED! Again! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-02-01 11:35 -0500
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-31 22:12 -0800
Re: Python is DOOMED! Again! Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-01-31 22:54 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:34 +1100
Re: Python is DOOMED! Again! Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-01 08:54 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 04:09 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 14:02 -0800
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 14:27 -0800
Re: Python is DOOMED! Again! Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-01 14:52 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 13:03 +1100
Re: Python is DOOMED! Again! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-02 18:46 +1300
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 03:31 +1100
Re: Python is DOOMED! Again! Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-02-01 09:45 -0800
Re: Python is DOOMED! Again! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-02-02 18:19 +1300
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-02 16:38 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 22:07 -0800
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-02-02 17:16 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 22:25 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-02-02 18:18 +1100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 23:43 -0800
Re: Python is DOOMED! Again! Rustom Mody <rustompmody@gmail.com> - 2015-02-02 04:12 -0800
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-02-01 22:12 -0800
Re: Python is DOOMED! Again! wxjmfauth@gmail.com - 2015-01-29 10:53 -0800
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-29 18:54 +0000
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-30 19:50 +0100
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-30 13:00 -0600
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-28 12:09 +1100
Re: Python is DOOMED! Again! Terry Reedy <tjreedy@udel.edu> - 2015-01-22 22:57 -0500
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 05:33 +1100
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-01-22 21:22 +0200
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-22 13:43 -0600
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 20:56 +0100
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-22 14:31 -0600
Re: Python is DOOMED! Again! Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-22 14:32 -0600
Re: Python is DOOMED! Again! Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-22 13:08 -0800
Re: Python is DOOMED! Again! Marko Rauhamaa <marko@pacujo.net> - 2015-01-22 23:25 +0200
Re: Python is DOOMED! Again! random832@fastmail.us - 2015-01-22 13:41 -0500
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 20:10 +0100
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 20:53 +0100
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 21:03 +0100
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-23 01:40 +0100
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-22 17:31 -0800
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 14:53 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-23 06:38 +0000
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-24 02:00 +0100
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-24 16:51 +1100
Re: Python is DOOMED! Again! Nicholas Cole <nicholas.cole@gmail.com> - 2015-01-24 09:04 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-24 12:15 +1100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-24 14:40 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 12:00 +1100
Re: Python is DOOMED! Again! Emile van Sebille <emile@fenx.com> - 2015-01-22 17:14 -0800
Re: Python is DOOMED! Again! Terry Reedy <tjreedy@udel.edu> - 2015-01-22 22:34 -0500
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-22 19:05 +0000
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 19:07 +0000
Re: Python is DOOMED! Again! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-23 15:51 +1100
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-22 19:09 +0000
Re: Python is DOOMED! Again! Emile van Sebille <emile@fenx.com> - 2015-01-22 13:56 -0800
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-22 15:08 -0700
Re: Python is DOOMED! Again! Paul Rubin <no.email@nospam.invalid> - 2015-01-22 15:24 -0800
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-22 15:12 -0700
Re: Python is DOOMED! Again! Rustom Mody <rustompmody@gmail.com> - 2015-01-22 19:11 -0800
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 14:52 +1100
Re: Python is DOOMED! Again! Rustom Mody <rustompmody@gmail.com> - 2015-01-22 21:06 -0800
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-23 16:33 +1100
Re: Python is DOOMED! Again! Chris Kaynor <ckaynor@zindagigames.com> - 2015-01-22 14:27 -0800
Re: Python is DOOMED! Again! Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-22 15:47 -0700
Re: Python is DOOMED! Again! Mario Figueiredo <marfig@gmail.com> - 2015-01-22 23:54 +0100
Re: Python is DOOMED! Again! Ben Finney <ben+python@benfinney.id.au> - 2015-01-23 10:22 +1100
Re: Python is DOOMED! Again! Sturla Molden <sturla.molden@gmail.com> - 2015-01-23 01:44 +0100
Re: Python is DOOMED! Again! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-23 06:33 +0000
Re: Python is DOOMED! Again! wxjmfauth@gmail.com - 2015-01-23 01:07 -0800
Re: Python is DOOMED! Again! Tony the Tiger <tony@tiger.invalid> - 2015-01-23 18:08 +0000
Re: Python is DOOMED! Again! BartC <bc@freeuk.com> - 2015-01-29 22:57 +0000
Re: Python is DOOMED! Again! Chris Angelico <rosuav@gmail.com> - 2015-01-30 10:17 +1100
Re: Python is DOOMED! Again! Chris Kaynor <ckaynor@zindagigames.com> - 2015-01-29 15:25 -0800
Re: Python is DOOMED! Again! MRAB <python@mrabarnett.plus.com> - 2015-01-30 02:11 +0000
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-22 21:50 +1100 |
| Message-ID | <mailman.17969.1421923826.18130.python-list@python.org> |
| In reply to | #84207 |
On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole <nicholas.cole@gmail.com> wrote: > Hang on! The particular example may not make a lot of sense but there are > plenty of places in ordinary Python where functions can accept different > objects in arguments and return different things. The point here is that > that will become rapidly messy and hard to read. Yes; but with proper use of TypeVar can simplify things a lot - have a read of the PEP. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-22 11:12 +0000 |
| Message-ID | <1a194e0a09db8d20453e39394a3@nntp.aioe.org> |
| In reply to | #84223 |
Chris, > On Thu, Jan 22, 2015 at 9:46 PM, Nicholas Cole > <nicholas.cole@gmail.com> wrote: > >> Hang on! The particular example may not make a lot of sense but there >> are plenty of places in ordinary Python where functions can accept >> different objects in arguments and return different things. The point >> here is that that will become rapidly messy and hard to read. >> > Yes; but with proper use of TypeVar can simplify things a lot - have a > read of the PEP. > > ChrisA > I agree. TypeVar will help tremendously by removing the need for union in cases of object inheritance. But only on cases of object inheritance.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-22 23:14 +1100 |
| Message-ID | <mailman.17971.1421928903.18130.python-list@python.org> |
| In reply to | #84226 |
On Thu, Jan 22, 2015 at 10:12 PM, Mario Figueiredo <marfig@gmail.com> wrote: > I agree. TypeVar will help tremendously by removing the need for union in > cases of object inheritance. But only on cases of object inheritance. Why only inheritance? One of the examples is of str and bytes, which don't have any inheritance relationship (they both just subclass object), and it works just fine for that. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-23 01:16 +1100 |
| Message-ID | <54c1063c$0$13008$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84207 |
Mario Figueiredo wrote:
> In article <54c0a571$0$13002$c3e8da3$5496439d@news.astraweb.com>,
> steve+comp.lang.python@pearwood.info says...
>>
>> The point isn't that there are no other alternative interpretations
>> possible, or that annotations are the only syntax imaginable, but that
>> they're not hard to guess what they mean, and if you can't guess, they're
>> not hard to learn and remember.
>
> Possibly one common use case will be Unions. And that factory syntax is
> really awful and long when you look at a function definition with as
> little as 3 arguments. The one below has only 2 arguments.
>
> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
> None]:
You can't use "raise" as a parameter name, since that's a keyword. Using
floats for money is Just Wrong and anyone who does so should have their
licence to program taken away. And I really don't understand what this
function is supposed to do, that it returns None, a single Employee, or a
sequence of Employees. (If it's hard to declare what the return type is,
perhaps your function does too much or the wrong thing.)
But putting those aside, let's re-write that with something a little closer
to PEP-8 formatting:
def handle_employees(
emp: Union[Employee, Sequence[Employee]],
pay_raise: Union[int, Sequence[int]]
) -> Union[Employee, Sequence[Employee], None]:
pass
That's quite nice and easy to follow. I can think of three improvements:
(1) Allow the return annotation to be on a line on its own rather than force
it to follow the closing bracket;
(2) Support | to make Unions of types;
(3) Have a shorter way to declare "Spam or Sequence (tuple?) of Spam".
def handle_employees(
emp: OneOrMore[Employee],
pay_raise: OneOrMore[int])
-> OneOrMore[Employee] | None:
pass
(2) has been rejected by Guido, but he may change his mind. The name I've
chosen for (3) is just the first thing I've thought of.
> Meanwhile there's quite a few more generics like the Sequence one above
> you may want to take a look at and try and remember. And that's just one
> factory (the generics support factory). You may also want to take a look
> at TypeVar and Callable for more syntactic hell.
Exaggerate, much?
> Meanwhile, there's the strange decision to implement type hints for
> local variables # comment lines. I have an hard time wrapping my head
> around this one. Really, comments!?
Yes, really. There is plenty of prior art for machine-meaningful comments:
- mypy uses it, and it works fine
- Pascal uses {$ ...} compiler directives
- Unix uses a special hash-bang #! comment in the first line to
specify the executable that runs the script
- Python supports a special encoding declaration using #
- doctest uses comments for directives
- HTML puts code (Javascript usually) inside of comments
- JMSAssert for Java uses comments for design-by-contract assertions
But note that the type declarations have *no runtime effect*. They truly are
comments, aimed at the human reader and any compliant type-checker.
Guido has said that he isn't ruling out an explicit syntactic support for
type declarations in the future, but right now there are various
constraints:
- it must be backwards compatible, i.e. something that Python 3.4 and older
will just ignore
- it must be available by lexical analysis, that is, from reading the
source code, which rules out anything that happens at runtime
- it must be human-readable
- and easily parsed by even simple tools
> Finally, remember all this is being added to your code just to
> facilitate static analysis.
You say "just" to facilitate static analysis, but let me put it this way. It
is "just" to facilitate:
- improved correctness of programs
- to assist in finding bugs as early as possible
- reduced need to write tedious, boring unit tests to check things
that an automated type-checker can deal with instead
- to reduce the need for runtime type-checks and isinstance() calls
- to aid in producing documentation
- to give hints to IDEs, editors, linters, code browsers and
similar tools.
> Strangely enough though I was taught from
> the early beginning that once I start to care about types in Python, I
> strayed from the pythonic way. I'm confused now... What is it then?
That's actually a really good question.
Good practice in Python will not change. If anything, explicitly checking
types with isinstance will become even less common: if you can use lexical
analysis to prove that the argument passed to a function is always a float,
there is no need to perform a runtime check that it is a float.
Notice that nearly all the examples in the PEP use abstract classes like
Sequence instead of concrete classes like list? This is a good thing, and
will encourage more flexible code. You don't need a specific type of
sequence, any type of sequence will do -- that's pretty much the definition
of duck-typing.
I've watched the evolution of typing in Python over the 15+ years. Back in
the old days of Python 1.4 and 1.5, the only way to type-check was to
compare two types for equality:
if type(x) == type(1.0):
print "x is a float"
That was very restrictive. You couldn't check for subclasses. You couldn't
subclass built-in types like floats, but you could use delegation, but
there was no way to tell Python your float-proxy should be treated as if it
were a float. Being so restrictive, it was best avoided, hence the very
strong emphasis on duck-typing.
Python 2.2 introduced "new style classes", which meant that you could
subclass built-ins. Functions like str, float, int and list became type
objects (classes) instead of functions, so now you could write:
if type(x) == float: print "x is a float"
Python 2.2 also introduced issubclass and isinstance, which allowed you to
check for a specific type or sub-type. That's less restrictive than exact
type equality: if you want something that quacks like a float, chances are
that it probably is a float or a sub-class of a float.
Python 2.5 (I think?) introduced Abstract Base Classes, which takes it to
the next level. Now, if you want something that quacks like a float, you
don't even have to inherit from float! You can create your own classes
without inheriting from float at all, and then register it as a float, and
Python will treat it as if it were a float. Or you can inherit from
*abstract* classes which provide a lot of the basic functionality needed so
you're not forced to re-invent the wheel.
Duck-typing in the Python 1.5 sense has a number of issues that make it less
than a panacea:
- Sometimes you really must have an duck, not just something duck-like.
If you're trying to find a mate for Donald Duck, you want a duck,
not a goose.
- More practically, if you're interfacing with C or Java or Fortran code,
you don't have the luxury of passing any old "duck like" object. If
the C code requires a float, you have to be sure you give it a float.
- It is good programming practice to raise errors as close as possible
to the source as you can. If your function requires a float, it is
often better to raise an exception *immediately* if it receives a
non-float, not deep inside the function's body.
- Duck-typing has its share of problems too. Consider a function that
expects an Artist object, and calls the draw() method, but instead it
received a Gunslinger object. Instead of getting a nice AttributeError,
your code will now do the wrong thing. How do you prevent errors like
this, if not by type-checking?
Since the "language wars" of the 1990s, dynamic languages have won. Even
static languages like Java contain dynamic features. But the victory isn't
all one way: dynamic languages are gaining static features too. Static
typing can improve performance and correctness, and it is silly to reject
that out of some misplaced idealism that there is One True Way to design a
language.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Jon Ribbens <jon+usenet@unequivocal.co.uk> |
|---|---|
| Date | 2015-01-22 14:33 +0000 |
| Message-ID | <slrnmc22i1.uab.jon+usenet@frosty.unequivocal.co.uk> |
| In reply to | #84230 |
On 2015-01-22, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > You can't use "raise" as a parameter name, since that's a keyword. Using > floats for money is Just Wrong and anyone who does so should have their > licence to program taken away. And I really don't understand what this > function is supposed to do, that it returns None, a single Employee, or a > sequence of Employees. (If it's hard to declare what the return type is, > perhaps your function does too much or the wrong thing.) That makes me think - it seems odd to me that PEP 484 doesn't even mention function overloading (even to say that it's outside the scope). I think overloading should certainly be considered, and unless the consensus is that it is something that should never happen, it should either be explicitly allowed or at least the type-hinting syntax should be checked to ensure it is forward-compatible with it.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-23 02:11 +1100 |
| Message-ID | <mailman.17973.1421939508.18130.python-list@python.org> |
| In reply to | #84230 |
On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Mario Figueiredo wrote:
>
>> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise:
>> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee],
>> None]:
>
> Using
> floats for money is Just Wrong and anyone who does so should have their
> licence to program taken away.
But using a float to specify a percentage raise that an employee (or
class of employees) gets would be reasonable. You could "handle" all
your problem employees by giving them an across-the-board 3% raise to
try to stop them from going on strike (they have a Union, as we can
see there, so strikes are clearly possible).
Not that that matters to the typing question. If it really is a
monetary type, all you need to do is replace 'float' with 'Money'
which would be a superclass to USD, AUD, GBP, and RepublicCredits.
There's still the question of what it's doing.
My best guess about this function is that it has three modes:
1) handle_employee(emp: Employee, pay_raise: float)
Give one employee a percentage raise. (Note the different function name.)
2) handle_employees(emp: Sequence[Employee], pay_raise: float)
Give all these employees the same percentage raise.
3) handle_employees(emp: Sequence[Employee], pay_raise: Sequence[float])
Equivalent to [handle_employee(e, r) for e, r in zip(emp, pay_raise)]
I can't figure out any sane meaning for passing a single employee and
a sequence of floats, and I think the one-and-one case should have a
different name. That would mean that there's really only one Union
involved, and the plural function would look like this:
def handle_employees(emp: Sequence[Employee], pay_raise: Union[float,
Sequence[float]]):
"""Atomically give many employees raises.
If pay_raise is a float, gives each employee that raise; otherwise, it
should be a sequence of the same length as emp.
"""
if isinstance(pay_raise, collections.Sequence):
for e, r in zip(emp, pay_raise):
handle_employee(e, r)
else:
for e in emp:
handle_employee(e, pay_raise)
But I still have no clue what the return value of either the
one-and-one case or the multiple case should be.
> (3) Have a shorter way to declare "Spam or Sequence (tuple?) of Spam".
>
>
> def handle_employees(
> emp: OneOrMore[Employee],
> pay_raise: OneOrMore[int])
> -> OneOrMore[Employee] | None:
> pass
Yes, that would be a reasonable thing. It might even be possible to
implement it on top of TypeVar. That said, though, APIs that accept
"just one, or maybe more" have problems; for instance, you can't write
a "pretty-print" function that can take either an arbitrary object, or
a sequence of arbitrary objects. Fundamentally not possible. But when
you can guarantee that the thing you're getting OneOrMore of is not
itself iterable, it would be useful.
>> Meanwhile there's quite a few more generics like the Sequence one above
>> you may want to take a look at and try and remember. And that's just one
>> factory (the generics support factory). You may also want to take a look
>> at TypeVar and Callable for more syntactic hell.
>
> Exaggerate, much?
Maybe. Callable does get pretty hairy; specifying the arguments and
return values of a function is never pretty. Pike is no better:
> typeof(write);
(1) Result: function(array(string) | string, mixed ... : int)
That's a function which takes either a single string or an array of
strings, followed by any number of additional arguments, and returns
an integer.
> typeof(GTK2.setup_gtk);
(2) Result: function(void | array(string) | string, void | int : array(string))
Optional arguments: one or more strings, and maybe an integer. Returns
an array of strings.
> typeof(rm);
(3) Result: function(string : int)
This one's pretty simple. It takes a string (path name), and returns
an integer (success or failure flag). And deletes a file/directory.
> typeof(asin);
(4) Result: function(int | float : float)
Could take an integer or a float, and returns a float.
The PEP 484 equivalents would be, I think:
write = Callable[[Union[str, Sequence[str]], AnyArgs], int]
# I have no idea how to do optional args.
rm = Callable[[str], int]
asin = Callable[[Union[int, float]], float]
It's not too bad when the function signature is really simple. And
that's going to be the common case. But it is syntactically
complicated to type-check a callback's arguments. Imagine, for
instance, GUI toolkit callbacks; chances are you can stuff extra args
into them (so they need a *args equivalent at the end), and they'll
take a variety of different args. They will not be pretty... or else
they'll be type-hinted simply as Callable, with nothing else.
But ultimately, that's not a fault of the type hinting structure. It's
a natural consequence of the complexity of callbacks. You can't get
away from it.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-23 21:59 +1100 |
| Message-ID | <54c2299d$0$13005$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84233 |
Chris Angelico wrote: > On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> Mario Figueiredo wrote: >> >>> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: >>> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee], >>> None]: >> >> Using >> floats for money is Just Wrong and anyone who does so should have their >> licence to program taken away. > > But using a float to specify a percentage raise that an employee (or > class of employees) gets would be reasonable. I don't think that a raise of 0.10000000000000001 (10%), 0.035000000000000003 (3.5%) or 0.070000000000000007 (7%) is quite what people intended. :-) (Don't use binary floating point numbers for anything related to money. Just don't.) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-23 22:38 +1100 |
| Message-ID | <mailman.18029.1422013105.18130.python-list@python.org> |
| In reply to | #84335 |
On Fri, Jan 23, 2015 at 9:59 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > I don't think that a raise of 0.10000000000000001 (10%), > 0.035000000000000003 (3.5%) or 0.070000000000000007 (7%) is quite what > people intended. > > :-) I also don't think it'll make any appreciable difference, especially if the actual salary is stored as an integer :-) > (Don't use binary floating point numbers for anything related to money. Just > don't.) While I generally agree, it's not quite as hard-and-fast as that. It's just important to know that binary floating point can't accurately represent many commonly-used real numbers... the same consideration that they always need. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-24 17:35 +1100 |
| Message-ID | <54c33d20$0$13011$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84337 |
Chris Angelico wrote: > On Fri, Jan 23, 2015 at 9:59 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> (Don't use binary floating point numbers for anything related to money. >> Just don't.) > > While I generally agree, it's not quite as hard-and-fast as that. It's > just important to know that binary floating point can't accurately > represent many commonly-used real numbers... the same consideration > that they always need. I think it is that hard-and-fast. If you sometimes use floats and sometimes don't use floats, you're forever worrying about coercing your values from one type to another, worrying whether the representation error of this value is sufficiently small to use a float or whether you have to use something else... the whole thing gets messy and ugly. Or worse, you're *not* worrying about these things, and when your users complain that their pay is sometimes a cent off and their account doesn't balance at the end of the year, you "fix the bug" by arbitrarily adjusting the printing routines. Better to just have a hard rule: never use binary floats for anything to do with money, if you care about the result. Obviously I'm not a fanatic. If I'm working out my share of a $37 meal split three ways, I just do 37/3 the same as anyone else :-) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-01-24 14:42 +0000 |
| Message-ID | <mailman.18086.1422110705.18130.python-list@python.org> |
| In reply to | #84442 |
On 24/01/2015 06:35, Steven D'Aprano wrote: > Obviously I'm not a fanatic. If I'm working out my share of a $37 meal split > three ways, I just do 37/3 the same as anyone else :-) > Always rounding down I take it? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-25 03:00 +1100 |
| Message-ID | <54c3c1b1$0$13011$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84471 |
Mark Lawrence wrote: > On 24/01/2015 06:35, Steven D'Aprano wrote: >> Obviously I'm not a fanatic. If I'm working out my share of a $37 meal >> split three ways, I just do 37/3 the same as anyone else :-) >> > > Always rounding down I take it? :) I'm hurt. I have a maths degree, I know how to do division: _____ 3| 37 3 goes into 3 once, and 3 goes into 7 twice with one remainder. So the answer is 12 and 1/3. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-25 03:27 +1100 |
| Message-ID | <mailman.18088.1422116868.18130.python-list@python.org> |
| In reply to | #84473 |
On Sun, Jan 25, 2015 at 3:00 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Mark Lawrence wrote: > >> On 24/01/2015 06:35, Steven D'Aprano wrote: >>> Obviously I'm not a fanatic. If I'm working out my share of a $37 meal >>> split three ways, I just do 37/3 the same as anyone else :-) >>> >> >> Always rounding down I take it? :) > > I'm hurt. I have a maths degree, I know how to do division: > > _____ > 3| 37 > > > 3 goes into 3 once, and 3 goes into 7 twice with one remainder. So the > answer is 12 and 1/3. I'm not sure whereabouts you are, but I don't have a $1/3 coin in my pocket most of the time. Mark probably doesn't have many £1/3 coins either. So... rounding up or down? :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-25 04:31 +1100 |
| Message-ID | <54c3d6d8$0$12988$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84475 |
Chris Angelico wrote: > On Sun, Jan 25, 2015 at 3:00 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> Mark Lawrence wrote: >> >>> On 24/01/2015 06:35, Steven D'Aprano wrote: >>>> Obviously I'm not a fanatic. If I'm working out my share of a $37 meal >>>> split three ways, I just do 37/3 the same as anyone else :-) >>>> >>> >>> Always rounding down I take it? :) >> >> I'm hurt. I have a maths degree, I know how to do division: >> >> _____ >> 3| 37 >> >> >> 3 goes into 3 once, and 3 goes into 7 twice with one remainder. So the >> answer is 12 and 1/3. > > I'm not sure whereabouts you are, but I don't have a $1/3 coin in my > pocket most of the time. Mark probably doesn't have many £1/3 coins > either. So... rounding up or down? :) I'm right here, in front of my computer. Where are you? Of course we don't have $1/3 dollar coins, but I do have a pair of tin-snips and can easily cut a $1 coin into three equal pieces. Either that, or make up change with 20¢, 10¢ and 5¢ (we practice round-to-nearest-5-cents here). -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Tim Chase <python.list@tim.thechases.com> |
|---|---|
| Date | 2015-01-24 12:46 -0600 |
| Message-ID | <mailman.18091.1422125112.18130.python-list@python.org> |
| In reply to | #84479 |
On 2015-01-25 04:31, Steven D'Aprano wrote: > Of course we don't have $1/3 dollar coins, but I do have a pair of > tin-snips and can easily cut a $1 coin into three equal pieces. I'm impressed that you can use tin-snips to cut it into exactly three equal pieces with greater precision than the floating point numbers that you're cautioning against in Python. I believe at that point, you're talking about at least the sub-sub-sub-atomic scale. :-) -tkc
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-01-24 10:59 -0800 |
| Message-ID | <53cdeb68-90ff-44af-a006-51be3ae3728e@googlegroups.com> |
| In reply to | #84482 |
On Sunday, January 25, 2015 at 12:15:28 AM UTC+5:30, Tim Chase wrote: > On 2015-01-25 04:31, Steven D'Aprano wrote: > > Of course we don't have $1/3 dollar coins, but I do have a pair of > > tin-snips and can easily cut a $1 coin into three equal pieces. > > I'm impressed that you can use tin-snips to cut it into exactly three > equal pieces with greater precision than the floating point numbers > that you're cautioning against in Python. I believe at that point, > you're talking about at least the sub-sub-sub-atomic scale. :-) > > -tkc With Superman¹, you should expect nails that cut electrons precisely ¹ And other s-starting names
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-25 13:22 +1100 |
| Message-ID | <54c45359$0$12975$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84482 |
Tim Chase wrote: > On 2015-01-25 04:31, Steven D'Aprano wrote: >> Of course we don't have $1/3 dollar coins, but I do have a pair of >> tin-snips and can easily cut a $1 coin into three equal pieces. > > I'm impressed that you can use tin-snips to cut it into exactly three > equal pieces with greater precision than the floating point numbers > that you're cautioning against in Python. I believe at that point, > you're talking about at least the sub-sub-sub-atomic scale. :-) They're really good quality tin-snips. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | alister <alister.nospam.ware@ntlworld.com> |
|---|---|
| Date | 2015-01-24 21:14 +0000 |
| Message-ID | <2XTww.350898$lm5.140746@fx36.am4> |
| In reply to | #84479 |
> > Of course we don't have $1/3 dollar coins, but I do have a pair of > tin-snips and can easily cut a $1 coin into three equal pieces. wow you have just given a physical demonstration of integer Maths $1 /3 =$0 as the coin is now worthless ;-) > > Either that, or make up change with 20¢, 10¢ and 5¢ (we practice > round-to-nearest-5-cents here). I suppose if you all pay 35¢ it at least gives the waitress a tip. -- Many pages make a thick book.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-01-24 14:51 -0700 |
| Message-ID | <mailman.18101.1422136344.18130.python-list@python.org> |
| In reply to | #84494 |
On Sat, Jan 24, 2015 at 2:14 PM, alister
<alister.nospam.ware@ntlworld.com> wrote:
>>
>> Either that, or make up change with 20¢, 10¢ and 5¢ (we practice
>> round-to-nearest-5-cents here).
>
> I suppose if you all pay 35¢ it at least gives the waitress a tip.
"""
In the Pacific States they have made a bolder push for complexity, and
settle their affairs by a coin that no longer exists – the BIT, or old
Mexican real. The supposed value of the bit is twelve and a half
cents, eight to the dollar. When it comes to two bits, the
quarter-dollar stands for the required amount. But how about an odd
bit? The nearest coin to it is a dime, which is, short by a fifth.
That, then, is called a SHORT bit. If you have one, you lay it
triumphantly down, and save two and a half cents. But if you have not,
and lay down a quarter, the bar-keeper or shopman calmly tenders you a
dime by way of change; and thus you have paid what is called a LONG
BIT, and lost two and a half cents, or even, by comparison with a
short bit, five cents.
"""
-- Robert Louis Stevenson
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-24 23:30 +0100 |
| Message-ID | <MPG.2f2e3b4acb2e5d9a989695@nntp.aioe.org> |
| In reply to | #84335 |
In article <54c2299d$0$13005$c3e8da3$5496439d@news.astraweb.com>, steve+comp.lang.python@pearwood.info says... > > I don't think that a raise of 0.10000000000000001 (10%), > 0.035000000000000003 (3.5%) or 0.070000000000000007 (7%) is quite what > people intended. > > (Don't use binary floating point numbers for anything related to > money. Just don't.) Few rules are written in stone and that rule isn't either. It all depends on the context. People often read these bits of well intentioned advise and go on to immediately make some kind of gospel out of it. Why is that? And why is that? Why do you think I can't ever use floats for money? Is there some kind of unspoken rule that money must always be dealt with with enough precision to give a microscope an headache? - What if I am storing money as an integer or a 2 decimal place Decimal to manage my electrical bill and I use a float to express a percentage? - What if the float operation is not a repetitive operation that would indeed invariably lead to round errors, but instead a once in a lifetime operation? I'm not saying I don't agree we should avoid it. I'm saying we need also to properly contextualize it before we decide to do so. If I'm writing a banking system, or a POS, you will be damn sure it will be hard to spot a float in my code. But if I'm writing my household electrical bill yearly report, or I'm writting a damn code snippet on a python group to illustrate how type hinting mangles your code, who gives a flying arse if I'm using a float to express money? Sheesh!
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-26 17:00 +0000 |
| Message-ID | <Houxw.308955$FO6.44943@fx33.am4> |
| In reply to | #84335 |
[Reposting. First attempt went direct to poster, perhaps via email, not sure why as I don't have a button to do that. If this does the same then please ignore.] On 23/01/2015 10:59, Steven D'Aprano wrote: > Chris Angelico wrote: > >> On Fri, Jan 23, 2015 at 1:16 AM, Steven D'Aprano >> <steve+comp.lang.python@pearwood.info> wrote: >>> Mario Figueiredo wrote: >>> >>>> def handle_employees(emp: Union[Employee, Sequence[Employee]], raise: >>>> Union[float, Sequence[float]]) -> Union[Employee, Sequence[Employee], >>>> None]: >>> >>> Using >>> floats for money is Just Wrong and anyone who does so should have their >>> licence to program taken away. >> >> But using a float to specify a percentage raise that an employee (or >> class of employees) gets would be reasonable. > > I don't think that a raise of 0.10000000000000001 (10%), > 0.035000000000000003 (3.5%) or 0.070000000000000007 (7%) is quite what > people intended. It seems they are getting a bigger raise than they expected in each case. So why complain? But in practice they will never see that billionth of a cent extra; they will get the same amount as they would if floating point wasn't used. And, how is the increase determined? It could well be the result of some complex calculation performed in floating point, which then has to be converted to ... BTW how *do* you represent a raise of 10% exactly if not with binary floating point? -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web