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 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-02-01 20:22 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <dc4d8671-23c4-46cf-b861-247adbf40957@googlegroups.com> |
| In reply to | #85045 |
On Monday, February 2, 2015 at 9:34:53 AM UTC+5:30, Rustom Mody wrote:
> 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()
Well I continue to be fooled
>>> d1 = {k:getattr([],k) for k in [].__dir__()}
>>> d2 = {k:getattr([],k) for k in dir([])}
>>> d1 == d2
False
>>> len(d1)
45
>>> len(d2)
45
>>> d1.keys()
dict_keys(['__rmul__', '__str__', '__gt__', '__mul__', '__class__', '__ne__', '__format__', '__sizeof__', '__contains__', '__imul__', '__add__', 'sort', 'count', 'extend', 'remove', '__init__', 'insert', '__setitem__', 'index', '__subclasshook__', 'copy', '__getitem__', '__iadd__', '__hash__', '__delitem__', '__reduce_ex__', '__iter__', '__repr__', '__le__', '__setattr__', 'reverse', '__new__', '__eq__', '__len__', '__doc__', '__lt__', 'clear', '__ge__', 'append', '__dir__', '__reversed__', '__getattribute__', 'pop', '__delattr__', '__reduce__'])
>>> d1.keys() == d2.keys()
True
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-02 17:55 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cj8e9sFb09iU1@mid.individual.net> |
| In reply to | #85000 |
Steven D'Aprano wrote: > [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. It says "method", not "attribute", so technically it's correct. The methods of an object are defined by what's in its class. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 18:15 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf242d$0$12991$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85051 |
Gregory Ewing wrote: > Steven D'Aprano wrote: >> [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. > > It says "method", not "attribute", so technically > it's correct. The methods of an object are defined > by what's in its class. Citation please. I'd like to see where that is defined. Even if it is so defined, the definition is wrong. You can define methods on an instance. I showed an example of an instance with its own personal __dir__ method, and showed that dir() ignores it if the instance belongs to a new-style class but uses it if it is an old-style class. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-02-01 23:41 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18394.1422862939.18130.python-list@python.org> |
| In reply to | #85061 |
-- Devin On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Gregory Ewing wrote: > >> Steven D'Aprano wrote: >>> [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. >> >> It says "method", not "attribute", so technically >> it's correct. The methods of an object are defined >> by what's in its class. > > Citation please. I'd like to see where that is defined. https://docs.python.org/3/glossary.html#term-method > Even if it is so defined, the definition is wrong. You can define methods on > an instance. I showed an example of an instance with its own personal > __dir__ method, and showed that dir() ignores it if the instance belongs to > a new-style class but uses it if it is an old-style class. You didn't define a method, you defined a callable attribute. Old-style classes will call those for special method overriding, because it's the simplest thing to do. New-style classes look methods up on the class as an optimization, but it also really complicates the attribute semantics. The lookup strategy is explicitly defined in the docs. pydoc is, like always, incomplete or inaccurate. See https://docs.python.org/2/reference/datamodel.html#special-method-names -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 23:06 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf6836$0$12996$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85064 |
Devin Jeanpierre wrote:
> -- Devin
>
> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Gregory Ewing wrote:
>>
>>> Steven D'Aprano wrote:
>>>> [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.
>>>
>>> It says "method", not "attribute", so technically
>>> it's correct. The methods of an object are defined
>>> by what's in its class.
>>
>> Citation please. I'd like to see where that is defined.
>
> https://docs.python.org/3/glossary.html#term-method
Run this code using any version of Python from 1.5 onwards, and you will see
that the definition is wrong:
# === cut ===
class K:
def f(self): pass
# Define a function OUTSIDE of a class body.
def g(self): pass
K.g = g
instance = K()
assert type(instance.f) is type(instance.g)
print(type(instance.f))
print(type(instance.g))
# === cut ===
Both K.f and K.g are methods, even though only one meets the definition
given in the glossary. The glossary is wrong.
Or rather, it is not so much that it is *wrong*, but that it is incomplete
and over-simplified. It describes how methods are normally (but not always)
defined, but not what they are. It is rather like defining "coffee" as the
milky drink you buy from Starbucks, then insisting that the black liquid
that you drank in an Italian restaurant cannot be coffee because you didn't
buy it from Starbucks.
Glossary entries are typically simplified, not exhaustive. It is not wise to
take a three line glossary entry as a complete, definite explanation. In
this case the glossary fails to tell you that methods are not *required* to
be defined inside a class body, that is merely the usual way to do it.
>> Even if it is so defined, the definition is wrong. You can define methods
>> on an instance. I showed an example of an instance with its own personal
>> __dir__ method, and showed that dir() ignores it if the instance belongs
>> to a new-style class but uses it if it is an old-style class.
>
> You didn't define a method, you defined a callable attribute.
That is wrong. I defined a method:
py> from types import MethodType
py> type(instance.f) is MethodType
True
instance.f is a method by the glossary definition. Its type is identical to
types.MethodType, which is what I used to create a method by hand.
I could also call the descriptor __get__ method by hand, if you prefer:
py> def h(self): pass
...
py> method = h.__get__(K, instance)
py> assert type(method) is type(instance.f)
py> print(method)
<bound method type.h of <class '__main__.K'>>
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 23:09 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf68eb$0$12996$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85071 |
Steven D'Aprano wrote: > Both K.f and K.g are methods, even though only one meets the definition > given in the glossary. The glossary is wrong. Oh I'm sure somebody is going to pick me up on this... In Python 2, they are methods. In Python 3, they are functions, and aren't converted into methods until you access them via the instance: K.f returns the function f instance.f typically retrieves the function f from K, and converts it to a method object bound to instance -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 00:58 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjbrfsF7kqgU1@mid.individual.net> |
| In reply to | #85072 |
Steven D'Aprano wrote: > In Python 2, they are methods. In Python 3, they are functions, and aren't > converted into methods until you access them via the instance: They're methods in both cases. They don't have to be "converted into methods"; they already are, by virtue of their location and intended usage. The wrapper that gets created on attribute access isn't the method (despite being called MethodType!) -- the method is the function that it wraps. The wrapper is just part of the machinery that passes the self argument to the method. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-02-02 05:00 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18398.1422882065.18130.python-list@python.org> |
| In reply to | #85071 |
On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
> Both K.f and K.g are methods, even though only one meets the definition
> given in the glossary. The glossary is wrong.
I agree, it oversimplified and has made a useless distinction here.
>>> Even if it is so defined, the definition is wrong. You can define methods
>>> on an instance. I showed an example of an instance with its own personal
>>> __dir__ method, and showed that dir() ignores it if the instance belongs
>>> to a new-style class but uses it if it is an old-style class.
>>
>> You didn't define a method, you defined a callable attribute.
>
> That is wrong. I defined a method:
>
> py> from types import MethodType
> py> type(instance.f) is MethodType
> True
>
>
> instance.f is a method by the glossary definition. Its type is identical to
> types.MethodType, which is what I used to create a method by hand.
You are assuming that they are both methods, just because they are
instances of a type called "MethodType". This is like assuming that a
Tree() object is made out of wood.
The documentation is free to define things in terms other than types
and be correct. There are many properties of functions-on-classes that
callable instance attributes that are instances of MethodType do not
have, as we've already noticed. isinstance can say one thing, and the
documentation another, and both can be right, because they are saying
different things.
For an example we can all agree on, this is not an instance of
collections.Iterable, but the docs claim it is iterable:
https://docs.python.org/2/glossary.html#term-iterable
class MyIterable(object):
def __getitem__(self, i): return i
The docs are not "wrong", they are just making a distinction for
humans that is separate from the python types involved. This is OK.
-- Devin
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-03 01:07 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf849d$0$13005$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85076 |
Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> instance.f is a method by the glossary definition. Its type is identical
>> to types.MethodType, which is what I used to create a method by hand.
>
> You are assuming that they are both methods, just because they are
> instances of a type called "MethodType". This is like assuming that a
> Tree() object is made out of wood.
No. It is "assuming" that a Tree() object is a Tree() object.
Run this code:
# === cut ===
class K(object):
def f(self): pass
def f(self): pass
instance = K()
things = [instance.f, f.__get__(instance, K)]
from random import shuffle
shuffle(things)
print(things)
# === cut ===
You allege that one of these things is a method, and the other is not. I
challenge you to find any behavioural or functional difference between the
two. (Object IDs don't count.)
If you can find any meaningful difference between the two, I will accept
that methods have to be created as functions inside a class body.
Otherwise you are reduced to claiming that there is some sort of mystical,
undetectable "essence" or "spirit" that makes one of those two objects a
real method and the other one a fake method, even though they have the same
type, the same behaviour, and there is no test that can tell you which is
which.
> The documentation is free to define things in terms other than types
> and be correct.
If you wanted to argue that "method" is a generic term, and we have instance
methods, class methods, static methods, and any other sort of method we
care to create using the descriptor protocol, then I would agree you have a
point.
But since we're just talking about instance methods, Python doesn't care how
they came into existence. You can use def to create a function inside a
class body, inject a function into the class, call the descriptor __get__
method, or use the types.MethodType type object, it is all the same. You
can use a def statement, or a lambda, or types.FunctionType if you are
really keen. It makes no difference.
Do I expect the glossary to go into such pedantic detail? No, of course not.
But I do expect anyone with a few years of Python programming experience to
be able to understand that what makes a method be a method is its type and
behaviour, not where it came from.
> There are many properties of functions-on-classes that
> callable instance attributes that are instances of MethodType do not
> have, as we've already noticed. isinstance can say one thing, and the
> documentation another, and both can be right, because they are saying
> different things.
>
>
> For an example we can all agree on, this is not an instance of
> collections.Iterable, but the docs claim it is iterable:
> https://docs.python.org/2/glossary.html#term-iterable
>
> class MyIterable(object):
> def __getitem__(self, i): return i
"Iterable" is a generic term, not a type. Despite the existence of the
collections.Iterable ABC, "iterable" refers to any type which can be
iterated over, using either of two different protocols.
As I said above, if you wanted to argue that "method" was a general term for
any callable attached to an instance or class, then you might have a point.
But you're doing something much weirder: you are arguing that given two
objects which are *identical* save for their object ID, one might be called
a method, and the other not, due solely to where it was created. Not even
where it was retrieved from, but where it was created.
If you believe that "method or not" depends on where the function was
defined, then this will really freak you out:
py> class Q:
... def f(self): pass # f defined inside the class
...
py> def f(self): pass # f defined outside the class
...
py> f, Q.f = Q.f, f # Swap the "inside" f and the "outside" f.
py> instance = Q()
py> instance.f # Uses "outside" f, so not a real method!
<bound method Q.f of <__main__.Q object at 0xb7b8fcec>>
py> MethodType(f, instance) # Uses "inside" f, so is a real method!
<bound method Q.f of <__main__.Q object at 0xb7b8fcec>>
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-02-03 01:24 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18417.1422955528.18130.python-list@python.org> |
| In reply to | #85084 |
On Mon, Feb 2, 2015 at 6:07 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Run this code: > > # === cut === > > class K(object): > def f(self): pass > > def f(self): pass > > instance = K() > things = [instance.f, f.__get__(instance, K)] > from random import shuffle > shuffle(things) > print(things) > > # === cut === > > > You allege that one of these things is a method, and the other is not. I > challenge you to find any behavioural or functional difference between the > two. (Object IDs don't count.) > > If you can find any meaningful difference between the two, I will accept > that methods have to be created as functions inside a class body. In this particular case, there is none. What if the body of the "method" was super().f() ? Some methods can be defined outside of the body and still work exactly the same, but others won't. > Otherwise you are reduced to claiming that there is some sort of mystical, > undetectable "essence" or "spirit" that makes one of those two objects a > real method and the other one a fake method, even though they have the same > type, the same behaviour, and there is no test that can tell you which is > which. It isn't mystical. There are differences in semantics of defining methods inside or outside of a class that apply in certain situations (e.g. super(), metaclasses). You have cherrypicked an example that avoids them. If one wants to say "A method can (...) by using super()", then methods must be defined to only exist inside of class bodies. Obviously, once you construct the correct runtime values, behavior might be identical. The difference is in whether you can do different things, not in behavior. >> For an example we can all agree on, this is not an instance of >> collections.Iterable, but the docs claim it is iterable: >> https://docs.python.org/2/glossary.html#term-iterable >> >> class MyIterable(object): >> def __getitem__(self, i): return i > > "Iterable" is a generic term, not a type. Despite the existence of the > collections.Iterable ABC, "iterable" refers to any type which can be > iterated over, using either of two different protocols. > > As I said above, if you wanted to argue that "method" was a general term for > any callable attached to an instance or class, then you might have a point. > But you're doing something much weirder: you are arguing that given two > objects which are *identical* save for their object ID, one might be called > a method, and the other not, due solely to where it was created. Not even > where it was retrieved from, but where it was created. > > If you believe that "method or not" depends on where the function was > defined, then this will really freak you out: > > > py> class Q: > ... def f(self): pass # f defined inside the class > ... > py> def f(self): pass # f defined outside the class > ... > py> f, Q.f = Q.f, f # Swap the "inside" f and the "outside" f. > py> instance = Q() > py> instance.f # Uses "outside" f, so not a real method! > <bound method Q.f of <__main__.Q object at 0xb7b8fcec>> > py> MethodType(f, instance) # Uses "inside" f, so is a real method! > <bound method Q.f of <__main__.Q object at 0xb7b8fcec>> You are really missing the point, if you think that surprises me. -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-02-03 12:38 +0200 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <87zj8vgtzk.fsf@elektro.pacujo.net> |
| In reply to | #85125 |
Devin Jeanpierre <jeanpierreda@gmail.com>: > It isn't mystical. There are differences in semantics of defining > methods inside or outside of a class that apply in certain situations > (e.g. super(), metaclasses). You have cherrypicked an example that > avoids them. It's slightly sad that Python exposes the two-level attribute lookup. It would be more elegant if, conceptually, all methods were retrieved from the object's attribute dict. That way, the class would be simply a mundane optimization trick instead of a metaphysical entity. A class instance has a namespace implemented as a dictionary which is the first place in which attribute references are searched. When an attribute is not found there, and the instance’s class has an attribute by that name, the search continues with the class attributes. [<URL: https://docs.python.org/3/reference/datamodel.html>] Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-03 21:49 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18419.1422960580.18130.python-list@python.org> |
| In reply to | #85129 |
On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa <marko@pacujo.net> wrote: > It's slightly sad that Python exposes the two-level attribute lookup. It > would be more elegant if, conceptually, all methods were retrieved from > the object's attribute dict. That way, the class would be simply a > mundane optimization trick instead of a metaphysical entity. > That's the ECMAScript model of classes - prototype-based. It's not Python's. There are many different ways to do things. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-02-03 13:27 +0200 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <87vbjjgrpj.fsf@elektro.pacujo.net> |
| In reply to | #85131 |
Chris Angelico <rosuav@gmail.com>: > On Tue, Feb 3, 2015 at 9:38 PM, Marko Rauhamaa <marko@pacujo.net> wrote: >> It's slightly sad that Python exposes the two-level attribute lookup. >> It would be more elegant if, conceptually, all methods were retrieved >> from the object's attribute dict. That way, the class would be simply >> a mundane optimization trick instead of a metaphysical entity. > > That's the ECMAScript model of classes - prototype-based. It's not > Python's. There are many different ways to do things. For (almost) all practical purposes, that is the Python way as well. If object instantiation (conceptually) copied the class's methods into the object's dict, you'd get the semantics I'm looking for. Marko
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 10:12 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjcrutFggcfU1@mid.individual.net> |
| In reply to | #85137 |
Marko Rauhamaa wrote: > For (almost) all practical purposes, that is the Python way as well. If > object instantiation (conceptually) copied the class's methods into the > object's dict, you'd get the semantics I'm looking for. If things worked the way you want, it would be impossible to store a function in an instance attribute and get it out again *without* it being treated as a method and getting 'self' added to its arguments. That would be a considerable nuisance when dealing with callbacks and the like. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-02-03 23:28 +0200 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <87egq6adm1.fsf@elektro.pacujo.net> |
| In reply to | #85172 |
Gregory Ewing <greg.ewing@canterbury.ac.nz>: > Marko Rauhamaa wrote: >> For (almost) all practical purposes, that is the Python way as well. If >> object instantiation (conceptually) copied the class's methods into the >> object's dict, you'd get the semantics I'm looking for. > > If things worked the way you want, it would be impossible to store a > function in an instance attribute and get it out again *without* it > being treated as a method and getting 'self' added to its arguments. > That would be a considerable nuisance when dealing with callbacks and > the like. Sorry, you'll have to elaborate. I don't quite follow you. Right now Python generates the trampoline from the class prototype every time you call a method. If the semantics allowed, you could create the trampoline at instantiation time (for better or worse). That way, the problem you seem to be referring to wouldn't materialize. Marko
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 11:43 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjd197FhtssU1@mid.individual.net> |
| In reply to | #85174 |
Marko Rauhamaa wrote: > Right now Python generates the trampoline from the class prototype every > time you call a method. If the semantics allowed, you could create the > trampoline at instantiation time (for better or worse). That way, the > problem you seem to be referring to wouldn't materialize. Sorry, I misinterpreted what you were suggesting. You seem to be suggesting an optimisation that pre-creates bound methods when the instance is created. Keeping a cache of bound methods would achieve the same thing without changing the semantics. I think CPython might already be doing that, but I'm not sure. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2015-02-04 01:32 +0200 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <878ugea7wh.fsf@elektro.pacujo.net> |
| In reply to | #85182 |
Gregory Ewing <greg.ewing@canterbury.ac.nz>:
> You seem to be suggesting an optimisation that pre-creates bound
> methods when the instance is created. Keeping a cache of bound methods
> would achieve the same thing without changing the semantics. I think
> CPython might already be doing that, but I'm not sure.
No, I'm saying Python should behave differently.
Python:
>>> class A:
... def f(self):
... print("f")
... def g(self):
... print("g")
...
>>> a = A()
>>> a.__class__.f = a.__class__.g
>>> a.f()
g
In my preferred semantics, a.f() would print
>>> a.f()
f
Marko
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-04 10:39 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18449.1423006789.18130.python-list@python.org> |
| In reply to | #85184 |
On Wed, Feb 4, 2015 at 10:32 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> No, I'm saying Python should behave differently.
>
> Python:
>
> >>> class A:
> ... def f(self):
> ... print("f")
> ... def g(self):
> ... print("g")
> ...
> >>> a = A()
> >>> a.__class__.f = a.__class__.g
> >>> a.f()
> g
>
> In my preferred semantics, a.f() would print
>
> >>> a.f()
> f
Yeeeouch. So either it has to actually copy everything in on
instantiation (stupid cost for the tiny chance that it'll actually
ever matter), or else have some kind of versioning that means that it
knows that 'a' was created from the pre-changed class.
What's the advantage?!?
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-02-03 23:41 +0000 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18450.1423006909.18130.python-list@python.org> |
| In reply to | #85184 |
On 03/02/2015 23:32, Marko Rauhamaa wrote:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>
>> You seem to be suggesting an optimisation that pre-creates bound
>> methods when the instance is created. Keeping a cache of bound methods
>> would achieve the same thing without changing the semantics. I think
>> CPython might already be doing that, but I'm not sure.
>
> No, I'm saying Python should behave differently.
>
> Python:
>
> >>> class A:
> ... def f(self):
> ... print("f")
> ... def g(self):
> ... print("g")
> ...
> >>> a = A()
> >>> a.__class__.f = a.__class__.g
> >>> a.f()
> g
>
> In my preferred semantics, a.f() would print
>
> >>> a.f()
> f
IMHO as clear as mud.
--
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 | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2015-02-03 15:55 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18451.1423007720.18130.python-list@python.org> |
| In reply to | #85184 |
[Multipart message — attachments visible in raw view] — view raw
On 02/03/2015 03:32 PM, Marko Rauhamaa wrote:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>
>> You seem to be suggesting an optimisation that pre-creates bound
>> methods when the instance is created. Keeping a cache of bound methods
>> would achieve the same thing without changing the semantics. I think
>> CPython might already be doing that, but I'm not sure.
>
> No, I'm saying Python should behave differently.
>
> Python:
>
> >>> class A:
> ... def f(self):
> ... print("f")
> ... def g(self):
> ... print("g")
> ...
> >>> a = A()
> >>> a.__class__.f = a.__class__.g
> >>> a.f()
> g
>
> In my preferred semantics, a.f() would print
>
> >>> a.f()
> f
That is, as you acknowledge, not Python.
Thankfully, it will also never be Python.
However, because Python is so awesome, you can twist your own code to behave that way, to a point: simply have your
__init__ ( or __new__) populate the instance dict with all non-dunder methods.
Or even better, implement your own proto(mumble) type stack in Python, so there is some warning that your instances
don't behave quite like normal Python instances.
--
~Ethan~
[toc] | [prev] | [next] | [standalone]
Page 9 of 14 — ← Prev page 1 … 7 8 [9] 10 11 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web