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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-01 14:06 +1100 |
| Message-ID | <54cd983c$0$13002$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84910 |
Mario Figueiredo wrote: > In article <54ca5bbf$0$12992$c3e8da3$5496439d@news.astraweb.com>, > steve+comp.lang.python@pearwood.info says... >> >> Why should I feel guilty? You wrote: >> >> >> "Static analysis cannot and should not clutter executable code." >> >> >> But what are type declarations in statically typed languages like C, >> Pascal, Haskell, etc.? They are used by the compiler for static analysis. >> The same applies to type declarations in dynamically typed languages like >> Cobra and Julia. And yet, there they are, in the executable code. >> >> So there are a whole lot of languages, going all the way back to 1950s >> languages like Fortran, to some of the newest languages which are only a >> few years old like Go, both dynamically typed and statically typed, which >> do exactly what you say languages "cannot and should not" do: they put >> type information used for static analysis there in the code. > > You are confusing static analysis with compile time checking which > produces side-effects like implicit conversion for instance and that > affects the resulting binary code. Something that Python won't do with > type annotations. And something that Julia, Scala or C does. I'm not confusing anything. I'm fully aware of the differences between what C or Pascal does and what Python does. But I'm also aware of the similarities. > This is also the first time I hear compilation time mentioned as static > analysis. Compilation consists of many different tasks. They may be explicitly handled by different tools, or implicitly handled by a single tool. That tool may combine them into a single phase, or keep them separate. These are all implementation details: different compilers for the same language could do this differently. Typical tasks for a compiler, in no particular order: - lexing and parsing of source code - type analysis and checking - code generation - linking to external libraries - optimisation For languages like C and Pascal, the type checking is typically done statically at compile-time. So of course they include static analysis. The compiler hasn't compiled the code yet, so it only has the source code to work with! A type error will halt the compiler and stop the program from compiling. > To be clear, type declarations in Julia, Scala, C have the potential to > produce side-effects, can result in optimized code and can result in > compile time errors or warnings. Type annotations in Python are instead > completely ignored by the interpreter. They do nothing of the above. > They do not participate in code execution. As as been pointed out repeatedly, Python annotations DO participate in the code execution: the annotations are created and stored in the function object at runtime, and one could easily create a library to use those annotations at runtime for runtime type-checks. >> As I said, these languages disagree with you. You are not just arguing >> against Guido, but against the majority of programming language designers >> for 60+ years. > > You are right. I'm not arguing against Guido. I have yet to hear his > opinion on your or mine arguments. I'm not arguing against the majority > of programming languages either, because they agree with me. Do you really expect us to believe that the majority of programming languages put type declarations in docstrings, or a second file separate from the source of the function? Okay, let's see some examples. Here is a list of languages still well-known enough that people use them: http://rosettacode.org/wiki/Category:Programming_Languages How many of them use docstrings as the only way to declare the type of a variable? How many use header files as the sole way to declare the type of variables? I'm feeling generous. You don't even need to show a *majority* (50%). I'd be amazed if you can find *ten percent* of those languages that agree with you. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-30 19:42 +0100 |
| Message-ID | <MPG.2f35eef1cc884a1b9896b6@nntp.aioe.org> |
| In reply to | #84822 |
In article <54ca5bbf$0$12992$c3e8da3$5496439d@news.astraweb.com>, steve+comp.lang.python@pearwood.info says... > > > Why should I feel guilty? You wrote: > > > "Static analysis cannot and should not clutter executable code." > > > But what are type declarations in statically typed languages like C, Pascal, > Haskell, etc.? They are used by the compiler for static analysis. The same > applies to type declarations in dynamically typed languages like Cobra and > Julia. And yet, there they are, in the executable code. > > So there are a whole lot of languages, going all the way back to 1950s > languages like Fortran, to some of the newest languages which are only a > few years old like Go, both dynamically typed and statically typed, which > do exactly what you say languages "cannot and should not" do: they put type > information used for static analysis there in the code. (Sorry if I'm late...) You are comparing static analysis with compile time checking which can result in implicit conversions and that can affect the resulting binary code. Something that Python won't do with type annotations. And something that Julia, Scala or C does. This is also the first time I hear compilation mentioned as static analysis. But I suppose... After all it does perform a crude form of static analysis as a natural consequence of compile time checks, besides doing a whole bunch of other things that aren't static analysis. A dog has four legs and two eyes. So does an elephant. I suppose you are going to argue with me that a dog is an elephant after all. To be clear, type declarations in Julia, Scala, C have the potential to produce side-effects, can result in optimized code and can result in compile time errors or warnings. They also affect runtime evaluation as you could easily attest if you input a float into a function expecting an int, whereas in Python the float will be gladly accepted and will only fail at the point in code where its interface won't match the statement. Meanwhile, type annotations in Python are instead completely ignored by the interpreter. They do nothing of the above. They do not participate in code generation and execution. > As I said, these languages disagree with you. You are not just arguing > against Guido, but against the majority of programming language designers > for 60+ years. You are right. I'm not arguing against Guido. I have yet to hear his opinion on what you are saying, so I don't even know if I should want to argue with him. And I'm not arguing against the majority of programming languages either, because as much as you try I have yet to hear an argument from you that convinces me they don't agree with me. No. I'm arguing with you.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-01-30 14:50 -0700 |
| Message-ID | <mailman.18323.1422654667.18130.python-list@python.org> |
| In reply to | #84911 |
On Fri, Jan 30, 2015 at 11:42 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> To be clear, type declarations in Julia, Scala, C have the potential to
> produce side-effects, can result in optimized code and can result in
> compile time errors or warnings. They also affect runtime evaluation as
> you could easily attest if you input a float into a function expecting
> an int, whereas in Python the float will be gladly accepted and will
> only fail at the point in code where its interface won't match the
> statement.
At least for C, as I noted in a previous post, it is simply not true
that they are used for runtime evaluation. For example:
>>> import ctypes
>>> libc = ctypes.CDLL("libc.so.6")
>>> libc.abs(ctypes.c_double(123.456))
2093824448
The C compiler may complain about it, but that's a compile-time static
check, no different from the sort of checks that PEP 484 seeks to add
to Python.
> Meanwhile, type annotations in Python are instead completely ignored by
> the interpreter. They do nothing of the above. They do not participate
> in code generation and execution.
But unlike C, Python lets you easily implement this yourself if you want to.
>>> def runtime_type_check(f):
... @functools.wraps(f)
... def wrapper(**args):
... for arg, value in args.items():
... if arg in f.__annotations__:
... if not isinstance(value, f.__annotations__[arg]):
... raise TypeError("Arg %s expected %s, got %s"
... % (arg, f.__annotations__[arg].__name__, type(arg).__name__))
... return f(**args)
... return wrapper
...
>>> @runtime_type_check
... def add(x:int, y:int) -> int:
... return x + y
...
>>> add(x="hello", y="world")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 8, in wrapper
TypeError: Arg y expected int, got str
(This could of course be extended for positional arguments and more
complex annotations, but I wanted to keep it simple for the purpose of
the example.)
[toc] | [prev] | [next] | [standalone]
| From | Skip Montanaro <skip.montanaro@gmail.com> |
|---|---|
| Date | 2015-01-28 12:34 -0600 |
| Message-ID | <mailman.18230.1422470046.18130.python-list@python.org> |
| In reply to | #84760 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: > C and C++ are weakly and statically typed languages. Python is a strongly > and dynamically typed language. Feel free to edit this Google spreadsheet:
[toc] | [prev] | [next] | [standalone]
| From | Skip Montanaro <skip.montanaro@gmail.com> |
|---|---|
| Date | 2015-01-28 12:36 -0600 |
| Message-ID | <mailman.18231.1422470183.18130.python-list@python.org> |
| In reply to | #84760 |
On Wed, Jan 28, 2015 at 12:34 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote: > > > On Wed, Jan 28, 2015 at 12:16 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote: >> >> C and C++ are weakly and statically typed languages. Python is a strongly and dynamically typed language. > > > Feel free to edit this Google spreadsheet: Man, sometimes Gmail makes me mad... Ctlr-V shouldn't send. Of course, sending is bound to Shift-Ctrl-V. Sometimes Gmail gets confused or doesn't get the "he let up on the shift key" memo. Or maybe I'm a spaz. At any rate, here's the link: http://preview.tinyurl.com/kcrcq4y Feel free to modify the spreadsheet. Should be open for anyone to edit. Skip
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-29 09:08 -0500 |
| Message-ID | <mailman.18262.1422540523.18130.python-list@python.org> |
| In reply to | #84760 |
On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote: > C and C++ are weakly and statically typed languages. "strong typing" has no meaning at all, and "weak typing" means "anything I don't like". The fact that you can add an int and a float, or that you can use any object as a boolean, would make python weakly typed in some people's eyes.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-30 02:56 +1100 |
| Message-ID | <54ca583e$0$13005$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84817 |
random832@fastmail.us wrote:
> On Wed, Jan 28, 2015, at 13:16, Mark Lawrence wrote:
>> C and C++ are weakly and statically typed languages.
>
> "strong typing" has no meaning at all, and "weak typing" means "anything
> I don't like".
I see you've been reading Chris Smith's essay on typing :-)
https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/
I think his essay is excellent, but his claim that strong and weak typing is
a meaningless distinction is excessive.
> The fact that you can add an int and a float, or that you can use any
> object as a boolean, would make python weakly typed in some people's
> eyes.
I think they would be wrong. Well, mostly wrong. But a little bit right.
We should agree that there is no universal, hard distinction between strong
and weak typing. But the names already suggest that -- there is no dividing
line between strong and weak. But we can certainly *rank* languages by
degrees of strength according to some standard, and if we agree on the
standard, we should agree on the rankings.
Even if we don't agree on a standard, we can surely agree on the two extreme
cases. Let's call them Foo and Bar language. They're both typed languages.
Foo language has no automatic coercions at all. Every type is utterly
distinct. The only way to convert a value of one type to another is with an
explicit XtoY function. Surely we can agree that Foo is a *very strongly
typed* language? (Perhaps even too strong?)
Bar language, on the other hand, tries extremely hard to ensure that every
type is automatically able to be coerced into every other type. The
coercion might not do what you expect, but it will do *something*:
{'a': 100, 'b': 300} + 5.0
=> 7.0
[1, 2, 3] + "hello"
=> [1, 2, 3, 'h', 'e', 'l', 'l', 'o']
"hello" + [1, 2, 3]
=> "hello[1, 2, 3]"
Bar will never give you a TypeError. I think we can agree that Bar is a
*very weakly typed* language.
There are degrees of strength, and I think that Python comes closer to the
Foo end than the Bar end. There are few automatic coercions, and most of
those are in the numeric tower according to the usual mathematical rules.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-29 13:23 -0500 |
| Message-ID | <mailman.18276.1422555831.18130.python-list@python.org> |
| In reply to | #84821 |
On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote: > Bar language, on the other hand, tries extremely hard to ensure that > every > type is automatically able to be coerced into every other type. The > coercion might not do what you expect, but it will do *something*: See, this is where the concept falls apart. Many people will define a dynamically-typed language as weakly-typed *only if* the result of the automatic type coercion is unexpected/distasteful/fattening, even if it is well-defined and predictable according to the rules of the language. Which makes it a matter of personal taste. > Bar will never give you a TypeError. I think we can agree that Bar is a > *very weakly typed* language. Statically typed lanugages by definition can never give you a TypeError - there are no runtime conversions that can succeed or fail based on the type of the arguments. What makes a statically typed language strong or weak? Are statically typed languages always weak? > > There are degrees of strength, and I think that Python comes closer to > the > Foo end than the Bar end. There are few automatic coercions, and most of > those are in the numeric tower according to the usual mathematical rules. Why is converting an int to a float when passed to a math function better than converting any object to a string when passed to a string function?
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-31 22:56 +1100 |
| Message-ID | <54ccc2fc$0$13009$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84833 |
random832@fastmail.us wrote:
> On Thu, Jan 29, 2015, at 10:56, Steven D'Aprano wrote:
>> Bar language, on the other hand, tries extremely hard to ensure that
>> every
>> type is automatically able to be coerced into every other type. The
>> coercion might not do what you expect, but it will do *something*:
>
> See, this is where the concept falls apart. Many people will define a
> dynamically-typed language as weakly-typed *only if* the result of the
> automatic type coercion is unexpected/distasteful/fattening,
Oh, the curse of the discontinuous mind! :-)
https://richarddawkins.net/2013/01/the-tyranny-of-the-discontinuous-mind-christmas-2011/
A concept doesn't fall apart just because a few people are unable to use it
correctly. We may not be able to distinguish the exact moment when a child
becomes an adult (except, of course, by picking some arbitrary culturally
sanctioned age) but the concepts of child and adult are meaningful. And so
it is with strong and weak typing: people of good faith may nevertheless
disagree where the dividing line should be draw, or even whether a dividing
line is meaningful, but the concept of typing strength remains meaningful.
> even if it
> is well-defined and predictable according to the rules of the language.
> Which makes it a matter of personal taste.
Some degree of weakness in a type system is not necessarily bad. Even the
strongest of languages usually allow a few exceptions, such as numeric
coercions. I've never come across a language that has pointers which
insists on having a separate Nil pointer for ever pointer type: the
compiler will allow Nil to be used for any pointer type. Anything else
would be impractical.
Unfortunately, weakly typed languages get a bad reputation because so few of
them have well-defined rules that can be derived without having to learn a
bunch of arbitrary rules. Consider Javascript. What happens when you add
two arrays?
js> [1, 2, 3] + [4]
1,2,34
If it makes no sense to you, consider this:
js> typeof([1, 2, 3] + [4])
string
If it still makes no sense to you, you're not alone.
How about an array and an object?
js> [] + {} //empty array plus empty object
[object Object]
js> {} + [] //empty object plus empty array
0
What if you add two empty objects?
js> {} + {}
NaN
More here:
https://www.destroyallsoftware.com/talks/wat
>> Bar will never give you a TypeError. I think we can agree that Bar is a
>> *very weakly typed* language.
>
> Statically typed lanugages by definition can never give you a TypeError
They can't give you a *runtime* TypeError, but the compiler can give you a
compile-time type error. (Sorry for the misleading use of "TypeError" as in
the Python exception, I was thinking more broadly than just runtime
exceptions.)
> - there are no runtime conversions that can succeed or fail based on the
> type of the arguments. What makes a statically typed language strong or
> weak? Are statically typed languages always weak?
Statically typed languages tend to be strong. The point of doing static type
analysis is to prohibit ill-defined operations at compile-time, rather than
have the compiler mindlessly (say) write a 16-byte struct where a 2-byte
int is expected. But I don't think that it is necessarily the case that
statically-typed languages *must* be strongly typed, or dynamically-typed
languages weak.
>> There are degrees of strength, and I think that Python comes closer to
>> the
>> Foo end than the Bar end. There are few automatic coercions, and most of
>> those are in the numeric tower according to the usual mathematical rules.
>
> Why is converting an int to a float when passed to a math function
> better than converting any object to a string when passed to a string
> function?
Both ints and floats are models of the same abstract thing, namely "number".
Ideally, from a mathematically standpoint, there should be no difference
between 23 and 23.0. Automatic coercions allow us to get a little closer to
that ideal.
Arbitrary objects, on the other hand, are rarely related to strings. Given
that we need to be able to display arbitrary objects to the human
programmer, if only for debugging, we need to be able to *explicitly*
convert into a string:
py> import nntplib
py> SERVER = "news.gmane.org"
py> server = nntplib.NNTP(SERVER)
py> str(server)
'<nntplib.NNTP instance at 0xb7bc76ec>'
but doing so *implicitly* gains us nothing except the saving of a few
keystrokes, while risking serious bugs. Forcing all arbitrary objects to
support string operations would be pointless and confusing. What could this
possibly mean?
server.replace('7', 'FOO')
We shouldn't insist that server objects support string methods, since that
would preempt them using methods of the same name for their own purposes,
and would needlessly clutter their API. We shouldn't want server objects to
automatically coerce into a string (why a string? why not a list or a dict
or a float?) because there is no real benefit to doing so. It can only
cause confusion.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-01 01:53 +1100 |
| Message-ID | <mailman.18340.1422716000.18130.python-list@python.org> |
| In reply to | #84951 |
On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Both ints and floats are models of the same abstract thing, namely "number".
> Ideally, from a mathematically standpoint, there should be no difference
> between 23 and 23.0. Automatic coercions allow us to get a little closer to
> that ideal.
So far, I'm mostly with you. (Though if your float type is not a
perfect superset of your integer type - as in Python - then the
default "up-cast" from int to float, while disallowing a corresponding
implicit "down-cast", seems flawed. But in concept, yes, automatic
coercion allows us to treat 23 and 23.0 as the same.)
> Arbitrary objects, on the other hand, are rarely related to strings. Given
> that we need to be able to display arbitrary objects to the human
> programmer, if only for debugging, we need to be able to *explicitly*
> convert into a string:
>
>
> py> import nntplib
> py> SERVER = "news.gmane.org"
> py> server = nntplib.NNTP(SERVER)
> py> str(server)
> '<nntplib.NNTP instance at 0xb7bc76ec>'
Here, though, I'm not so sure. Why should you be able to *type-cast*
anything to string? Python has another, and perfectly serviceable,
function for converting arbitrary objects into strings, and that's
repr(). It would make perfect sense for a language to make this
distinction much more stark:
1) str() attempts to convert something into a string. It can do this
automatically in the case of "string-like" objects (eg buffers, maybe
some magical things that come from databases), and can convert others
with help (eg bytes->string using an encoding parameter), but anything
else will raise an error.
2) repr() guarantees to convert anything into a string. It does this
in a relatively arbitrary fashion; you can write a helper method for
your class to make this more useful to the human.
#2 is how Python's repr already functions, so explicitly converting
arbitrary objects into strings is covered. The idea that we can str()
them as well isn't necessarily part of a sane typing system.
(Note that I'm not saying that Python got it wrong, here; just that
taking the alternate choice would also be not-wrong.)
> but doing so *implicitly* gains us nothing except the saving of a few
> keystrokes, while risking serious bugs.
Complete and automatic casting to string, I would agree. However, I
would suggest that there are a few *binary operations* which could be
more convenient if they allowed some non-strings. For instance, Pike
allows addition of strings and integers: "1" + 2 == "12", where Python
requires "1" + str(2) for the same operation. (But Pike does *not*
allow just any object there. Only a few, like numbers, can be quietly
cast on being added to strings.)
> Forcing all arbitrary objects to
> support string operations would be pointless and confusing. What could this
> possibly mean?
>
> server.replace('7', 'FOO')
Well duh, you would go to the server and replace the 7th stored post
with the new body 'FOO' :)
Strings have *tons* of methods. There's no way you'd want them all on
every object, and it wouldn't make sense. You definitely don't up-cast
everything to string just to use methods on them... I can't imagine
any (sane) language ever doing that.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-01 14:16 +1100 |
| Message-ID | <54cd9a7a$0$12984$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84955 |
Chris Angelico wrote: > On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> Both ints and floats are models of the same abstract thing, namely >> "number". Ideally, from a mathematically standpoint, there should be no >> difference between 23 and 23.0. Automatic coercions allow us to get a >> little closer to that ideal. > > So far, I'm mostly with you. (Though if your float type is not a > perfect superset of your integer type - as in Python - then the > default "up-cast" from int to float, while disallowing a corresponding > implicit "down-cast", seems flawed. But in concept, yes, automatic > coercion allows us to treat 23 and 23.0 as the same.) In principle, we might have a real-number type that is a perfect superset of ints, and we might even have int versions of NAN and INF. But down-casting real-to-integer is ambiguous, due to the need to handle any fractional parts: - raise an exception if the fractional part is non-zero - truncate (round towards zero) - round down towards -infinity - round up toward +infinity - round to nearest, ties to odd numbers - round to nearest, ties to even numbers - round to nearest, ties split randomly - something else One might semi-arbitrarily pick one (say, truncation) as the default when you cast using int(x) but you need to support at least the most common rounding modes, perhaps as separate functions. >> Arbitrary objects, on the other hand, are rarely related to strings. >> Given that we need to be able to display arbitrary objects to the human >> programmer, if only for debugging, we need to be able to *explicitly* >> convert into a string: >> >> >> py> import nntplib >> py> SERVER = "news.gmane.org" >> py> server = nntplib.NNTP(SERVER) >> py> str(server) >> '<nntplib.NNTP instance at 0xb7bc76ec>' > > Here, though, I'm not so sure. Why should you be able to *type-cast* > anything to string? Python has another, and perfectly serviceable, > function for converting arbitrary objects into strings, and that's > repr(). Which *also* converts to a string. (Note I didn't say *cast* to a string. I cannot imagine any meaningful definition of what casting a NNTP server object to a str might be.) > It would make perfect sense for a language to make this > distinction much more stark: > > 1) str() attempts to convert something into a string. It can do this > automatically in the case of "string-like" objects (eg buffers, maybe > some magical things that come from databases), and can convert others > with help (eg bytes->string using an encoding parameter), but anything > else will raise an error. > > 2) repr() guarantees to convert anything into a string. It does this > in a relatively arbitrary fashion; you can write a helper method for > your class to make this more useful to the human. > > #2 is how Python's repr already functions, so explicitly converting > arbitrary objects into strings is covered. The idea that we can str() > them as well isn't necessarily part of a sane typing system. > > (Note that I'm not saying that Python got it wrong, here; just that > taking the alternate choice would also be not-wrong.) I agree with all of that. And for what it is worth, a class can refuse to convert to str while still supporting repr: py> class K(object): ... def __str__(self): raise TypeError ... def __repr__(self): return "Stuff and things. Mostly stuff." ... py> k = K() py> str(k) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in __str__ TypeError py> repr(k) 'Stuff and things. Mostly stuff.' But by default, Python will fallback on __repr__ if __str__ doesn't exist, or __str__ if __repr__ doesn't exist, or both. Or something. (I always forget what the rules are exactly.) >> but doing so *implicitly* gains us nothing except the saving of a few >> keystrokes, while risking serious bugs. > > Complete and automatic casting to string, I would agree. However, I > would suggest that there are a few *binary operations* which could be > more convenient if they allowed some non-strings. For instance, Pike > allows addition of strings and integers: "1" + 2 == "12", where Python > requires "1" + str(2) for the same operation. (But Pike does *not* > allow just any object there. Only a few, like numbers, can be quietly > cast on being added to strings.) I'm surprised you're not into Perl, with an attitude like that. A sick, disgusting, despicably perverted attitude. *wink* But seriously, I can see some uses there, but frankly why bother to make an exception for ints when you require all other types to have an explicit coercion? The problem with string/int automatic coercions is that there are lots of answers but none of them are obviously the right answer: "1" + 1 --> "11" or 2? "1a" + 1 --> 2 like Perl does, or "1a1" like Javascript does? Do you strip out all non-numeric characters, or truncate at the first non-numeric character? Should you perhaps be a little more flexible and allow common mistypings like O for 0 and l for 1? How about whitespace? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-01 14:46 +1100 |
| Message-ID | <mailman.18349.1422762384.18130.python-list@python.org> |
| In reply to | #84975 |
On Sun, Feb 1, 2015 at 2:16 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Chris Angelico wrote: > >> On Sat, Jan 31, 2015 at 10:56 PM, Steven D'Aprano >> <steve+comp.lang.python@pearwood.info> wrote: >>> Both ints and floats are models of the same abstract thing, namely >>> "number". Ideally, from a mathematically standpoint, there should be no >>> difference between 23 and 23.0. Automatic coercions allow us to get a >>> little closer to that ideal. >> >> So far, I'm mostly with you. (Though if your float type is not a >> perfect superset of your integer type - as in Python - then the >> default "up-cast" from int to float, while disallowing a corresponding >> implicit "down-cast", seems flawed. But in concept, yes, automatic >> coercion allows us to treat 23 and 23.0 as the same.) > > In principle, we might have a real-number type that is a perfect superset of > ints, and we might even have int versions of NAN and INF. But down-casting > real-to-integer is ambiguous, due to the need to handle any fractional > parts: > > - raise an exception if the fractional part is non-zero > - truncate (round towards zero) > - round down towards -infinity > - round up toward +infinity > - round to nearest, ties to odd numbers > - round to nearest, ties to even numbers > - round to nearest, ties split randomly > - something else > > One might semi-arbitrarily pick one (say, truncation) as the default when > you cast using int(x) but you need to support at least the most common > rounding modes, perhaps as separate functions. Agreed; but the trap here is that there are equivalent problems when converting integers to floating point - just more subtle, because they don't happen in the low ranges of values. In the same way that a UTF-16 string representation has more subtle problems than an ASCII string representation (because it's easy to test your code on "foreign text" and still not realize that it has issues with astral characters), casting int to float is subtle because you'll probably do all your testing on numbers less than 2**53. It might take a lot of tracking-down work before you finally discover that there's one place in your code where you do division with / instead of //, and you get back a float, and then only when your integers are really huge (maybe you encode an eight-digit date, four-digit time, then a three-digit country code, and finally a two-digit incrementing number) do you actually start losing precision. The bulk of Python programs will never run into this; yet we do have an arbitrary-precision integer type, we're not like ECMAScript with a single "Number" type. >>> Arbitrary objects, on the other hand, are rarely related to strings. >>> Given that we need to be able to display arbitrary objects to the human >>> programmer, if only for debugging, we need to be able to *explicitly* >>> convert into a string: >>> >>> >>> py> import nntplib >>> py> SERVER = "news.gmane.org" >>> py> server = nntplib.NNTP(SERVER) >>> py> str(server) >>> '<nntplib.NNTP instance at 0xb7bc76ec>' >> >> Here, though, I'm not so sure. Why should you be able to *type-cast* >> anything to string? Python has another, and perfectly serviceable, >> function for converting arbitrary objects into strings, and that's >> repr(). > > Which *also* converts to a string. (Note I didn't say *cast* to a string. I > cannot imagine any meaningful definition of what casting a NNTP server > object to a str might be.) Sure, but Python doesn't really have a way to spell "convert this to a string if it's already basically stringy, otherwise raise TypeError". You can do that for other types like int, but not for string, because you can always call str() on something. > I agree with all of that. And for what it is worth, a class can refuse to > convert to str while still supporting repr: > > py> class K(object): > ... def __str__(self): raise TypeError > ... def __repr__(self): return "Stuff and things. Mostly stuff." > ... > py> k = K() > py> str(k) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "<stdin>", line 2, in __str__ > TypeError > py> repr(k) > 'Stuff and things. Mostly stuff.' Hmm. Sure you can do that, but is that just part of the freedom you have to shoot yourself in the foot? Would that be considered an ill-behaved class? >> Complete and automatic casting to string, I would agree. However, I >> would suggest that there are a few *binary operations* which could be >> more convenient if they allowed some non-strings. For instance, Pike >> allows addition of strings and integers: "1" + 2 == "12", where Python >> requires "1" + str(2) for the same operation. (But Pike does *not* >> allow just any object there. Only a few, like numbers, can be quietly >> cast on being added to strings.) > > I'm surprised you're not into Perl, with an attitude like that. A sick, > disgusting, despicably perverted attitude. *wink* > > But seriously, I can see some uses there, but frankly why bother to make an > exception for ints when you require all other types to have an explicit > coercion? Ints, floats, and any user-defined type that chooses to ask for it; but not arrays, mappings, files, or other types that don't make sense. It's the same feature that allows you to add a float and an int; the + operator is defined as accepting certain pairs of dissimilar types, and has well-defined behaviour around those types. > The problem with string/int automatic coercions is that there are lots of > answers but none of them are obviously the right answer: > > "1" + 1 --> "11" or 2? If that's 2, then you have a classic "sloppy typing" system that has to spell addition and concatenation differently (cf PHP and REXX). The one obvious answer here is "11". > "1a" + 1 --> 2 like Perl does, or "1a1" like Javascript does? > > Do you strip out all non-numeric characters, or truncate at the first > non-numeric character? You don't strip out anything from the string when you add an integer to it, because you convert the integer to a string. (Now, what the rules are for converting a string to an integer, well, that's a completely different question. Fresh new argument as to whether casting "1z" to integer should be 1 or TypeError.) > Should you perhaps be a little more flexible and allow common mistypings > like O for 0 and l for 1? How about whitespace? Definitely not O/0 or I/1, but ignoring whitespace when converting string to integer is often helpful, and seldom a problem. But none of this has anything to do with adding strings and non-strings; you *always* convert to string (or throw an error), never the other way. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2015-01-31 20:31 -0800 |
| Message-ID | <mailman.18350.1422765114.18130.python-list@python.org> |
| In reply to | #84975 |
[Multipart message — attachments visible in raw view] — view raw
On 01/31/2015 07:16 PM, Steven D'Aprano wrote: > > But by default, Python will fallback on __repr__ if __str__ doesn't exist, > or __str__ if __repr__ doesn't exist, or both. Or something. (I always > forget what the rules are exactly.) If __str__ is missing, __repr__ is called. If __repr__ is missing, object.__repr__ (or some intermediate base class' __repr__) is called. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-01-31 21:36 -0800 |
| Subject | dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <e4b6415e-f3f0-4a47-8f66-6f39609df0f6@googlegroups.com> |
| In reply to | #84980 |
On Sunday, February 1, 2015 at 10:15:13 AM UTC+5:30, Ethan Furman wrote: > On 01/31/2015 07:16 PM, Steven D'Aprano wrote: > > > > But by default, Python will fallback on __repr__ if __str__ doesn't exist, > > or __str__ if __repr__ doesn't exist, or both. Or something. (I always > > forget what the rules are exactly.) > > If __str__ is missing, __repr__ is called. > > If __repr__ is missing, object.__repr__ (or some intermediate base class' __repr__) is called. > > -- > ~Ethan~ The other day I was taking a class in which I was showing - introspection for discovering -- help, type, dir etc at the repl - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) And a student asked me the diff between dir([]) and [].__dir__() I didnt know what to say... Now surely the amount of python I dont know is significantly larger than what I know Still it would be nice to have surface-syntax ←→ dunder-magic more systematically documented
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2015-02-01 00:12 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18354.1422778368.18130.python-list@python.org> |
| In reply to | #84981 |
[Multipart message — attachments visible in raw view] — view raw
On 01/31/2015 09:36 PM, Rustom Mody wrote: > > And a student asked me the diff between > dir([]) > and > [].__dir__() > > I didnt know what to say... > Now surely the amount of python I dont know is significantly larger than what I know > Still it would be nice to have surface-syntax ←→ dunder-magic more > systematically documented I don't have a complete answer for you, but I can say this: In simple cases (such as __len__) there is little difference between calling the surface operator and the dunder version (the error message differs in this case). In more complex cases (such as __add__) using the surface syntax (+) buys lots of extras: - if one operand is a subclass of the other, calling its __add__ or __radd__ method as appropriate - if the first operand returns NotImplemented, calling the other operand's __radd__ to see if that works - possibly others that I don't recall at the moment Basically, unless you're programming at the system (or class internals) level, don't call dunder methods directly. -- ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 03:20 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54ce526a$0$13012$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84981 |
Rustom Mody wrote:
> The other day I was taking a class in which I was showing
> - introspection for discovering -- help, type, dir etc at the repl
> - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
>
> And a student asked me the diff between
> dir([])
> and
> [].__dir__()
>
> I didnt know what to say...
Surely the right answer would have been "I don't know, let's check the
interactive interpreter first, and the docs second."
Checking the REPL first would have revealed that [].__dir__ raises
AttributeError. In other words, lists don't have a __dir__ method.
Checking the docs would then have revealed that __dir__ is only required
when a class wishes to customise the output of dir(). Or at least, that's
what I recall them saying. I'm too lazy to look it up :-)
Oh very well, because it's you...
https://docs.python.org/2/library/functions.html#dir
Note that there are two inaccuracies in the documentation for __dir__:
[quote]
If the object has a method named __dir__(), this method will
be called and must return the list of attributes.
[end quote]
The first inaccuracy is that like all (nearly all?) dunder methods, Python
only looks for __dir__ on the class, not the instance itself. Hence:
py> class K(object):
... def __dir__(self):
... return ["eggs", "spam"]
...
py> k = K()
py> from types import MethodType
py> k.__dir__ = MethodType(lambda self: ["cheese", "spam"], k)
py> dir(k)
['eggs', 'spam']
Well, actually that's only true for new-style classes. For old-style classic
classes (Python 2 only), it will work on the instance as well. That is, in
Python 2 only, if I had left out the "object" base class, dir(k) would have
returned ["cheese", "spam"].
Now that I have confused your students, we shall never mention classic
classes again (until next time).
The second inaccuracy is that method should not return the attributes
themselves, but their names.
> Now surely the amount of python I dont know is significantly larger than
> what I know Still it would be nice to have surface-syntax ←→ dunder-magic
> more systematically documented
Each function or operator is unique. However, there are certain general
behaviours that typically hold.
Dunder methods are only looked up on the class, not the instance. (Except
for classic classes, if there are any exceptions to this rule, it is
probably a bug.) So the correct analog of surface syntax `obj + spam` is
*not* `obj.__add__(spam)` but actually:
type(obj).__add__(spam)
Similar for other operators and functions. In the case of dir, the
comparison should be:
dir([]) versus type([]).__dir__()
Except of course dir doesn't require there to be a __dir__ method.
len tries to call __len__ if it exists, and if not, it tries walking the
iterable counting items.
bool tries calling __bool__ (Python 3) or __nonzero__ (Python 2), if it
exists. If not, it tries returning len(obj) != 0. If that fails, objects
are true by default.
In the case of operators, operator syntax `x $ y` for some operator $ will
generally do something like this:
X = type(x)
Y = type(y)
if issubclass(Y, X):
# Try the reflected version first, if it exists.
dunder = getattr(Y, "__rdunder__", None)
if dunder:
result = dunder(y, x)
if result is not NotImplemented:
return result
# Or the non-reflected version second.
dunder = getattr(X, "__dunder__", None)
if dunder:
result = dunder(x, y)
if result is not NotImplemented:
return result
else:
# Like the above, except we check the non-reflected
# version first, and the reflected version second.
...
raise TypeError
Some methods are their own reflection, e.g. __eq__. In the special case of
__eq__ and __ne__, if the class defines one method but not the other,
recent versions of Python will automatically call the other method and
return its boolean not. Unary operators obviously have no concept of a
reflected version.
Comparison operators prefer to call the rich comparison methods but may fall
back on the older __cmp__ dunder method (Python 2 only).
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 03:55 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54ce5a92$0$12996$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85000 |
Steven D'Aprano wrote: > len tries to call __len__ if it exists, and if not, it tries walking the > iterable counting items. Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-02-01 10:31 -0700 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18366.1422811948.18130.python-list@python.org> |
| In reply to | #85009 |
On Sun, Feb 1, 2015 at 9:55 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Steven D'Aprano wrote: > >> len tries to call __len__ if it exists, and if not, it tries walking the >> iterable counting items. > > Hmmm, I may have mis-remembered that. Perhaps I'm thinking of Ruby. I think you just got it backward. iter will call __iter__ if it exists, and will try to fall back on __len__ and __getitem__ to iterate otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-02-01 19:52 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <daf926fb-8794-4ac8-94cd-dedb4f492a4c@googlegroups.com> |
| In reply to | #85000 |
On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote: > Rustom Mody wrote: > > > The other day I was taking a class in which I was showing > > - introspection for discovering -- help, type, dir etc at the repl > > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b) > > > > And a student asked me the diff between > > dir([]) > > and > > [].__dir__() > > > > I didnt know what to say... > > Surely the right answer would have been "I don't know, let's check the > interactive interpreter first, and the docs second." > > Checking the REPL first would have revealed that [].__dir__ raises > AttributeError. In other words, lists don't have a __dir__ method. ?? $ python3 Python 3.4.2 (default, Oct 8 2014, 13:08:17) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [].__dir__ <built-in method __dir__ of list object at 0x7f5dd2209f48> >>> dir([]) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'] >>> [].__dir__() ['__rmul__', '__str__', '__gt__', 'remove', '__class__', '__getitem__', '__format__', '__ne__', '__sizeof__', '__contains__', '__reduce__', '__add__', 'sort', 'count', 'extend', '__mul__', '__imul__', '__reduce_ex__', '__setitem__', '__doc__', '__ge__', 'copy', '__init__', '__iadd__', '__hash__', '__delitem__', 'insert', '__iter__', '__repr__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', 'index', '__lt__', 'clear', '__subclasshook__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__'] >>> What you are describing seems to be true for python2 though
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-02-01 20:04 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <074ea090-708a-443a-b5f8-686c2dce8078@googlegroups.com> |
| In reply to | #85044 |
On Monday, February 2, 2015 at 9:22:51 AM UTC+5:30, Rustom Mody wrote:
> On Sunday, February 1, 2015 at 9:51:11 PM UTC+5:30, Steven D'Aprano wrote:
> > Rustom Mody wrote:
> >
> > > The other day I was taking a class in which I was showing
> > > - introspection for discovering -- help, type, dir etc at the repl
> > > - mapping of surface syntax to internals eg. a + b ←→ a.__add__(b)
> > >
> > > And a student asked me the diff between
> > > dir([])
> > > and
> > > [].__dir__()
> > >
> > > I didnt know what to say...
> >
> > Surely the right answer would have been "I don't know, let's check the
> > interactive interpreter first, and the docs second."
> >
> > Checking the REPL first would have revealed that [].__dir__ raises
> > AttributeError. In other words, lists don't have a __dir__ method.
>
> ??
>
> $ python3
> Python 3.4.2 (default, Oct 8 2014, 13:08:17)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> [].__dir__
> <built-in method __dir__ of list object at 0x7f5dd2209f48>
> >>> dir([])
> ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__sizeof__', '__str__', '__subclasshook__', 'append', 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort']
> >>> [].__dir__()
> ['__rmul__', '__str__', '__gt__', 'remove', '__class__', '__getitem__', '__format__', '__ne__', '__sizeof__', '__contains__', '__reduce__', '__add__', 'sort', 'count', 'extend', '__mul__', '__imul__', '__reduce_ex__', '__setitem__', '__doc__', '__ge__', 'copy', '__init__', '__iadd__', '__hash__', '__delitem__', 'insert', '__iter__', '__repr__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', 'index', '__lt__', 'clear', '__subclasshook__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__']
> >>>
>
> What you are describing seems to be true for python2 though
And since they *looked* different I believed they were different.
Evidently not…
>>> s1= set([].__dir__())
>>> s2=set(dir([]))
>>> s1
{'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__', '__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend', 'remove', '__mul__', '__reduce__', '__imul__', '__reduce_ex__', '__setitem__', 'insert', '__doc__', '__ge__', 'index', 'copy', '__subclasshook__', '__getitem__', '__init__', '__iadd__', '__hash__', '__delitem__', '__iter__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__lt__', 'clear', '__gt__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__'}
>>> s2
{'__rmul__', '__str__', '__class__', '__ne__', '__repr__', '__format__', '__sizeof__', '__contains__', '__add__', 'sort', 'count', 'extend', '__mul__', 'remove', '__imul__', '__reduce__', '__reduce_ex__', '__setitem__', 'insert', '__doc__', '__ge__', '__subclasshook__', 'copy', 'index', '__getitem__', '__iadd__', '__init__', '__hash__', '__delitem__', '__iter__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__lt__', 'clear', '__gt__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__'}
>>> len(s1)
45
>>> len(s2)
45
>>> s1 - s2
set()
>>> s2 - s1
set()
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web