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 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-04 13:30 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54d18439$0$13011$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85182 |
Gregory Ewing wrote: > 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. It's not. py> class K(object): ... def f(self): pass ... py> k = K() py> k.f is k.f False -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-04 12:57 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54d17c7a$0$2890$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #85172 |
Gregory Ewing wrote:
> 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.
Not impossible, just inconvenient. Assuming that the descriptor protocol
runs on access to instance attributes as well as class attribute, the
solution is to use a custom descriptor to return the bare function.
class function(object):
def __init__(self, func):
self.func = func
def __get__(self, obj, cls=None):
return self.func
instance.callback = function(mycallback)
Or you can possibly use staticmethod.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 19:04 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjdr47FnkijU1@mid.individual.net> |
| In reply to | #85189 |
Steven D'Aprano wrote: > Gregory Ewing wrote: > >>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 > > Not impossible, just inconvenient... the > solution is to use a custom descriptor But then it's not a plain function any more. Obviously you can wrap your function in something else, but that's the "nuisance" I was talking about. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-04 04:40 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54d10807$0$13002$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85125 |
Devin Jeanpierre wrote:
> 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() ?
What of it? The zero-argument form of super() is a compiler hack documented
as only working inside classes. Most methods don't even use super *at all*,
let alone the Python3-only zero argument form. Surely you cannot be serious
that the defining characteristic of what is or is not a method is whether
or not an explicit hack works?
But you know, I can duplicate the compiler hack and still use the
zero-argument form of super in a method defined on the outside of the
class.
py> class A(object):
... pass
...
py> def magic(): # Don't do this at home!
... __class__ = A
... def f(self):
... __class__
... return super() # Magic zero-argument form.
... return f
...
py> A.f = magic()
py> a = A()
py> a.f()
<super: <class 'A'>, <A object>>
So to answer your question:
What if the body of the "method" was super().f() ?
It would still work correctly. Because Python is just that awesome.
> Some methods can be defined outside of the body and still work exactly
> the same, but others won't.
"Some methods can be defined outside of the body".
AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS!
If some methods can be defined outside of the body of a class, then being
defined inside the body of a class does not define a method.
You say "some methods", but the reality is that *all methods* can do so.
Even if they use super. Even if they use the zero-argument form of super
(although that one is rather inconvenient).
The class statement is syntactic sugar for calling type(name, bases, ns):
class A(bases):
x = 100
f = lambda self: self.x + 1
is equivalent to:
A = type("A", bases, {'x': 100, 'f': lambda self: self.x + 1})
*ANY* class you create with the class statement can be created (less
conveniently) with type (or the appropriate metaclass).
Obviously the class statement form is convenient because it allows you to
define the items of the namespace in place, which you can't always do using
type itself. With type, you may have to prepare the items first, insert
them into a dict, and pass it as the namespace argument. It also offers
convenient syntax for changing the metaclass. Most importantly, it is
simply more readable and nicer to be able to define the methods indented
inside the class statement. This is the natural way to define classes, and
given that the glossary need not be 100% complete and definitive, "function
defined inside a class body" is close enough to the truth.
But it is not *the whole truth*.
Not only can methods be defined outside of a class, but with a little
preparation functions defined inside of classes can remain functions.
py> class function(object):
... def __init__(self, func):
... self.func = func
... def __get__(self, obj, cls=None):
... return self.func
...
py> class B(object):
... @function
... def f(x, y): # No self.
... return x + y
...
py> B.f(23, 42)
65
py> b = B()
py> b.f(23, 42)
65
py> type(b.f)
<class 'function'>
(Alternatively, I could change the metaclass, although that's trickier.
Using a custom descriptor is just too easy.)
>> 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.
Out of the millions, billions of methods people write, how many do you think
use super? 1% 0.1%? 10%?
And you accuse *me* of cherrypicking.
Not that it matters. As I have shown, even the zero argument form of super
can be used.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 10:39 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjcthcFguddU1@mid.individual.net> |
| In reply to | #85166 |
Steven D'Aprano wrote: > If some methods can be defined outside of the body of a class, then being > defined inside the body of a class does not define a method. Nobody's disputing that. The business about super() is just a possible reason for the glossary to define the word 'method' in a more restricted way -- because it simplifies the wording of *other* parts of the docs that talk about super(). Another thing to consider is that while tricks like manually inserting __class__ into a function may work today with CPython, they might not work in future versions or other implementations. So there are good reasons for the docs to be conservative about what they promise. Also, with Python being so dynamic, just about *anything* you can say about its usual behaviour can be circumvented with enough hackery. If the docs were to pedantically take all of those possibilities into account at every turn, they would be so dense and impenetrable as to be nearly useless to anyone other than language lawyers. All this started when I pointed out that *if* you take the glossary definition of the term 'method' at its word, then what the docs say about the __dir__ method won't lead you to think that attaching it to an instance would work. That's true regardless of whether you think the glossary definition is too restrictive or not. I wouldn't have thought that this obvservation would be so controversial. But maybe I'm wrong, and Python really is doomed -- to death by language lawyering!-) -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-02-03 15:04 -0700 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18443.1423001119.18130.python-list@python.org> |
| In reply to | #85166 |
On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS! Careful there, you're starting to sound like Ranting Rick. ;-)
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2015-02-03 18:31 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <af418e29-e4db-4329-b742-9610e8f667c0@googlegroups.com> |
| In reply to | #85177 |
On Tuesday, February 3, 2015 at 4:05:57 PM UTC-6, Ian wrote: > On Tue, Feb 3, 2015 at 10:40 AM, Steven D'Aprano wrote: > > AT LONG LAST THE LIGHT DAWNS! THE PENNY DROPS! > > Careful there, you're starting to sound like Ranting Rick. ;-) Ha! My meme's are far more catchy and intellectual. But as they say, intimation *IS* the ultimate form of flattery!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-04 09:19 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18446.1423001979.18130.python-list@python.org> |
| In reply to | #85166 |
On Wed, Feb 4, 2015 at 4:40 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > given that the glossary need not be 100% complete and definitive, "function > defined inside a class body" is close enough to the truth. * This * We are arguing, not about an element in a formal grammar, but about a glossary entry. If one of my Python students asks me, "What's a method?", I'm not going to go into a technical explanation like this; I want to answer with a single sentence that covers the bit that matters. (Though I'd probably define it from the other perspective - it's "an object attribute that you can call", perhaps - but if the question came from a class definition, "a function defined inside a class" would be fine.) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-04 13:30 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54d1842c$0$13011$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85180 |
Chris Angelico wrote: > On Wed, Feb 4, 2015 at 4:40 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> given that the glossary need not be 100% complete and definitive, >> "function defined inside a class body" is close enough to the truth. > > * This * > > We are arguing, not about an element in a formal grammar, but about a > glossary entry. I'm not arguing about the glossary entry. The glossary entry is fine, so long as you understand that it is incomplete and simplified. I'm arguing with those who insist that objects of type MethodType aren't methods, and objects of type FunctionType aren't functions but methods, except when they are, based on that simplified, incomplete glossary entry. > If one of my Python students asks me, "What's a > method?", I'm not going to go into a technical explanation like this; Surely it depends on whether they are a beginner or an advanced student? Code injection is a legitimate design pattern, albeit not one I'd teach beginners. I can inject methods into a class or even an instance. If you think that methods *must* be defined in the class body, you're missing out on a very powerful technique. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-04 15:58 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54d1a6f5$0$11096$c3e8da3@news.astraweb.com> |
| In reply to | #85191 |
Steven D'Aprano wrote:
> Code injection is a legitimate design pattern, albeit not one I'd teach
> beginners. I can inject methods into a class or even an instance. If you
> think that methods must be defined in the class body, you're missing out
> on a very powerful technique.
Er, perhaps "code injection" is not the best name for this, on account of it
also being the name for a security vulnerability anti-pattern:
http://cwe.mitre.org/data/definitions/94.html
https://www.owasp.org/index.php/Code_Injection
I'm talking about a variety of dependency injection where you either add an
entirely new method to an instance, or give the instance it's own custom
method overriding the one declared in the class. Ruby makes it even easier
than Python -- perhaps too easy:
# Ruby code
class Foo
def bar(x)
puts "#{self}.bar received #{x}"
end
end
f = Foo.new()
g = Foo.new()
def f.bar(x)
puts "Instance #{self}.bar received #{x}"
end
f.bar(23); g.bar(42)
Running that prints:
Instance #<Foo:0xb74303c0>.bar received 23
#<Foo:0xb7428288>.bar received 42
I'm also lead to believe that this technique is quite similar to what is
done in Aspect Oriented Programming.
Anyhoo... enough about Ruby. This technique is possible in Python too,
albeit a tiny bit less conveniently. And it doesn't work for overriding
__dunder__ attributes in new-style classes.
--
Steve
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 19:22 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjds5cFnqjkU2@mid.individual.net> |
| In reply to | #85196 |
Steven D'Aprano wrote: > Er, perhaps "code injection" is not the best name for this, on account of it > also being the name for a security vulnerability anti-pattern: > > I'm talking about a variety of dependency injection where you either add an > entirely new method to an instance, or give the instance it's own custom > method overriding the one declared in the class. I think the term you're after is "monkeypatching". -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 19:22 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjds50FnqjkU1@mid.individual.net> |
| In reply to | #85191 |
Steven D'Aprano wrote: > I'm arguing with those who insist that objects of type MethodType aren't > methods, and objects of type FunctionType aren't functions but methods, > except when they are, based on that simplified, incomplete glossary entry. I'm not arguing that based on the glossary entry. I'm arguing it based on my experience of how the term 'method' is used in the Python community. > I can inject methods into a class or even an instance. If you > think that methods *must* be defined in the class body, you're missing out > on a very powerful technique. I'm willing to accept 'method' as a legitimate term for a function injected into a class body, *if it's used as a method* once it gets there. This is what you don't seem to understand. It's not about the type of the object. You can't write a piece of code to test whether a given object is a method or not, because it's not an intrinsic property of the object. It's a matter of how it's *used*. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-02-02 05:02 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18399.1422882208.18130.python-list@python.org> |
| In reply to | #85071 |
On Mon, Feb 2, 2015 at 5:00 AM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote: > 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. Oops, I just realized why such a claim might be made: the documentation probably wants to be able to say that any method can use super(). So that's why it claims that it isn't a method unless it's defined inside a class body. -- Devin >>>> 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:20 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf87b8$0$12991$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85077 |
Devin Jeanpierre wrote: > Oops, I just realized why such a claim might be made: the > documentation probably wants to be able to say that any method can use > super(). So that's why it claims that it isn't a method unless it's > defined inside a class body. You can use super anywhere, including outside of classes. The only thing you can't do is use the Python 3 "super hack" which automatically fills in the arguments to super if you don't supply them. That is compiler magic which truly does require the function to be defined inside a class body. But you can use super outside of classes: py> class A(list): ... pass ... py> x = super(A) # Unbound super object! py> x.__get__(A).append <method 'append' of 'list' objects> py> a = A() py> x.__get__(a).append <built-in method append of A object at 0xb7b8beb4> -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2015-02-03 01:25 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18418.1422955577.18130.python-list@python.org> |
| In reply to | #85085 |
On Mon, Feb 2, 2015 at 6:20 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > Devin Jeanpierre wrote: >> Oops, I just realized why such a claim might be made: the >> documentation probably wants to be able to say that any method can use >> super(). So that's why it claims that it isn't a method unless it's >> defined inside a class body. > > You can use super anywhere, including outside of classes. The only thing you > can't do is use the Python 3 "super hack" which automatically fills in the > arguments to super if you don't supply them. That is compiler magic which > truly does require the function to be defined inside a class body. But you > can use super outside of classes: Obviously, I was referring to no-arg super. Please assume good faith and non-ignorance on my part. -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2015-02-04 00:32 +1300 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <cjbptsF78e9U1@mid.individual.net> |
| 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. > > Or rather, it is not so much that it is *wrong*, but that it is incomplete > and over-simplified. I agree with that; a more complete definition would be "a function that is found in a class as a result of an attribute lookup on an instance of that class". > I defined a method: > > py> from types import MethodType > py> type(instance.f) is MethodType > True Being of type MethodType is not the defining characterisic of a method. MethodType is actually misnamed; an instance of MethodType is *not* a method, in the same way that an eggcup is not an egg. A better name would be MethodWrapper, but that still doesn't mean that anything you wrap with it is a method. An eggcup *usually* contains an egg, but it could contain something else. > instance.f is a method by the glossary definition. Not by the glossary definition as written, since the function you wrapped in a MethodType was not defined inside a class body. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Vito De Tullio <vito.detullio@gmail.com> |
|---|---|
| Date | 2015-02-02 06:26 +0100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18391.1422854832.18130.python-list@python.org> |
| In reply to | #85000 |
Steven D'Aprano wrote: > Checking the REPL first would have revealed that [].__dir__ raises > AttributeError. In other words, lists don't have a __dir__ method. ? Python 3.4.2 (default, Nov 29 2014, 00:45:45) [GCC 4.8.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [].__dir__() ['sort', '__contains__', '__init__', '__ge__', 'count', '__class__', '__format__', '__mul__', 'index', '__rmul__', '__hash__', '__iter__', 'clear', '__subclasshook__', '__getitem__', 'reverse', 'append', '__ne__', 'pop', '__reduce__', '__add__', 'extend', '__gt__', '__sizeof__', '__setattr__', '__imul__', '__dir__', '__le__', 'insert', '__repr__', '__str__', '__getattribute__', '__len__', '__lt__', 'remove', '__new__', '__reduce_ex__', 'copy', '__reversed__', '__delattr__', '__eq__', '__setitem__', '__iadd__', '__doc__', '__delitem__'] >>> -- By ZeD
[toc] | [prev] | [next] | [standalone]
| From | Rustom Mody <rustompmody@gmail.com> |
|---|---|
| Date | 2015-02-02 04:27 -0800 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <29c73890-f2f2-4e81-8391-07ff5f1b1c7d@googlegroups.com> |
| In reply to | #85053 |
On Monday, February 2, 2015 at 10:57:27 AM UTC+5:30, Vito De Tullio wrote: > Steven D'Aprano wrote: > > > Checking the REPL first would have revealed that [].__dir__ raises > > AttributeError. In other words, lists don't have a __dir__ method. > > ? > > Python 3.4.2 (default, Nov 29 2014, 00:45:45) > [GCC 4.8.3] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> [].__dir__() > ['sort', '__contains__', '__init__', '__ge__', 'count', '__class__', > '__format__', '__mul__', 'index', '__rmul__', '__hash__', '__iter__', > 'clear', '__subclasshook__', '__getitem__', 'reverse', 'append', '__ne__', > 'pop', '__reduce__', '__add__', 'extend', '__gt__', '__sizeof__', > '__setattr__', '__imul__', '__dir__', '__le__', 'insert', '__repr__', > '__str__', '__getattribute__', '__len__', '__lt__', 'remove', '__new__', > '__reduce_ex__', 'copy', '__reversed__', '__delattr__', '__eq__', > '__setitem__', '__iadd__', '__doc__', '__delitem__'] > >>> Sure But as I said (and probably Steven checked): $ python Python 2.7.8 (default, Oct 20 2014, 15:05:19) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> [].__dir__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'list' object has no attribute '__dir__' --------------- My point was more methodological/sociological than technical: Are these dunder methods as 'internal' as say the register-allocation used by a C compiler? In which case the language implementer is entitled to tell the vanilla programmer: "Dunder methods (and their changingness) is none of your business" If however they are more on the public façade of the language then some better docs would be nice
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-02-02 23:43 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <54cf7104$0$12986$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #85074 |
Rustom Mody wrote: > My point was more methodological/sociological than technical: > > Are these dunder methods as 'internal' as say the register-allocation used > by a C compiler? Dunder methods are implementation, not interface. If you are the class author, then you care about the implementation, and write dunder methods. But as the class user, you should not call dunder methods directly, instead always go through the public interface: # Not these. a.__dir__() seq.__len__() x.__add__(y) spam.__eq__(ham) # Use these dir(a) len(seq) x + y spam == ham -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-02-02 07:45 +1100 |
| Subject | Re: dunder-docs (was Python is DOOMED! Again!) |
| Message-ID | <mailman.18378.1422823564.18130.python-list@python.org> |
| In reply to | #84981 |
On Sun, Feb 1, 2015 at 4:36 PM, Rustom Mody <rustompmody@gmail.com> 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... Simple answer: You write dunder methods and the interpreter calls them. You don't call them yourself. I can't currently think of any situation where it's appropriate to call a dunder method manually (cue the swamping of such situations on the list); you just call dir() or the + operator or whatever it be. ChrisA
[toc] | [prev] | [next] | [standalone]
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web