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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-01-25 02:28 +0000 |
| Message-ID | <mailman.18124.1422152930.18130.python-list@python.org> |
| In reply to | #84534 |
On 25/01/2015 01:00, Rick Johnson wrote: > On Saturday, January 24, 2015 at 5:56:02 PM UTC-6, Mark Lawrence wrote: >> For at least the third time the PEP was written by three >> people, one of whom was the BDFL. Why do you keep >> insisting that "he" is wrong, surely it should be "they" ? > > TWO REASONS: > > (1) I don't know either of those people. And they have > never attempted to contact me, or even participate in > discussions on this list. > > BUT MORE IMPORTANTLY: > > (2) Final decisions for additions to Python are via GvR. > Why should i waste my time "appealing for sanity" to > numerous people, when i can focus my attention on the only > one that matters? > > But why must Guido be sheltered from dissent? With power > comes responsibility! > >> A substantial number of people on both lists are perfectly >> happy to speak their mind, to the extent that Guido has >> been known to do u-turns. Nobody has any need to lick >> anybody's boots, and to suggest that this is the case I >> find highly insulting to the entire Python community. > > Enough with the spin-doctoring of my words, only boot > lickers would be offended by what i said, and that is the > whole point of saying it! Do you think boot lickers are a > valuable resource of this (or any) community? Or could it > be that you just cannot accept an inconvenient truth. > >> You (singular) have to *EARN* respect, you do not deserve >> it. If you were to stick to subjects that you have >> knowledge of, such as tkinter/IDLE, > > Oh i see. I'm allowed to participate so long as i don't step > on YOUR toes or offend YOUR delicate sensibilities? So long > as i volunteer to be locked in YOUR little rat cage, and do > exactly what YOU say. Sorry Mark, but YOUR secret > aspirations for tyrannical rule are not going to be > "entertained" by THIS community. > > This character assassination of me has to stop, and your one > of the prolific assassins on this list. Show me one time > that i have *EVER* intentionally misled a noob on this > list? You may find a sample where i've made an honest > mistake, or mis-comprehended a question, but don't you > *DARE* question my morals! > > I am one of the most honest and trustworthy people in this > community. You may find my style to be annoying, (that is > your opinion), but you have no right (and no evidence) to > question my integrity. > > You can call me any name in the book you want; you can curse > me; you can ridicule me; and all of it i can ignore; but i > will NOT allow you to paint me as dishonest. I hold honesty > as the most important of *ALL* virtues. > > You owe me an apology for slandering my integrity! > You are now getting what I should have done some time ago as my patience with you has run out. *plonk* -- 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 | wxjmfauth@gmail.com |
|---|---|
| Date | 2015-01-25 10:57 -0800 |
| Message-ID | <b02fae32-08b5-42c0-b275-f8be73b1b0ad@googlegroups.com> |
| In reply to | #84513 |
Le dimanche 25 janvier 2015 00:20:30 UTC+1, Rick Johnson a écrit : Do not complain too much. These brave Python devs have already succeeded to create an anti unicode product.
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-26 10:01 -0500 |
| Message-ID | <mailman.18150.1422284487.18130.python-list@python.org> |
| In reply to | #84313 |
On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote: > Rick Johnson wrote: > > > The solution is move the type > > hinting syntax completely out of the source file and into > > another file -- think of it as a "Python Type Hinting Header > > File". > > The 1970s called, they want their bad ideas back. > > I can do no better than to quote from the Go FAQs: > > Dependency management is a big part of software development > today but the “header files” of languages in the C tradition > are antithetical to clean dependency analysis—and fast > compilation. This is more along the lines of a lint library than a header file (header files in the 1970s didn't even actually include function signature information) - which did not even participate in compilation at all.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-27 11:11 +1100 |
| Message-ID | <54c6d7c2$0$12992$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84604 |
random832@fastmail.us wrote: > On Thu, Jan 22, 2015, at 23:23, Steven D'Aprano wrote: >> Rick Johnson wrote: >> >> > The solution is move the type >> > hinting syntax completely out of the source file and into >> > another file -- think of it as a "Python Type Hinting Header >> > File". >> >> The 1970s called, they want their bad ideas back. >> >> I can do no better than to quote from the Go FAQs: >> >> Dependency management is a big part of software development >> today but the “header files” of languages in the C tradition >> are antithetical to clean dependency analysis—and fast >> compilation. > > This is more along the lines of a lint library than a header file Stub files are a second-rate solution for the problem of annotating functions where you are unable (or unwilling) to annotate the source code directly. They suffer from similar problems: - you have to manage the stub file independently of the source code it belongs with - type information is about as far away from the variable as it is possible to get (a completely different file!) - lexical analysis has to look for twice as many files (it has to hit the hard drive for a stub file before looking at the source), and we know from importing that file system access is a significant and expensive part of the process. But, when the first-rate solution cannot be used, a second-rate solution is better than nothing. > (header files in the 1970s didn't even actually include function > signature information) - which did not even participate in compilation > at all. If C compilers didn't use the header files, what were they for? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dan Sommers <dan@tombstonezero.net> |
|---|---|
| Date | 2015-01-27 01:09 +0000 |
| Message-ID | <ma6og2$hb9$1@dont-email.me> |
| In reply to | #84624 |
On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote: > random832@fastmail.us wrote: >> (header files in the 1970s didn't even actually include function >> signature information) - which did not even participate in >> compilation at all. > If C compilers didn't use the header files, what were they for? The compiler did use the header files, but only for functions' return types and other non-function-signature things (like macros and type definitions). Dan
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-27 17:36 +1100 |
| Message-ID | <54c731fc$0$2910$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #84626 |
Dan Sommers wrote: > On Tue, 27 Jan 2015 11:11:45 +1100, Steven D'Aprano wrote: > >> random832@fastmail.us wrote: > >>> (header files in the 1970s didn't even actually include function >>> signature information) - which did not even participate in >>> compilation at all. > >> If C compilers didn't use the header files, what were they for? > > The compiler did use the header files, but only for functions' return > types and other non-function-signature things (like macros and type > definitions). I consider return type to be part of the function signature. The signature of a function is the parameters it accepts and the result it returns. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-27 18:59 +1100 |
| Message-ID | <mailman.18165.1422345585.18130.python-list@python.org> |
| In reply to | #84633 |
On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > I consider return type to be part of the function signature. The signature > of a function is the parameters it accepts and the result it returns. It is, but there are times when it isn't significant. For instance, C++ overloaded functions are distinguished by their function signatures, but *not* including the return values (nor several other aspects). ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-27 19:03 +1100 |
| Message-ID | <54c74640$0$12980$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84634 |
Chris Angelico wrote: > On Tue, Jan 27, 2015 at 5:36 PM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >> I consider return type to be part of the function signature. The >> signature of a function is the parameters it accepts and the result it >> returns. > > It is, but there are times when it isn't significant. For instance, > C++ overloaded functions are distinguished by their function > signatures, but *not* including the return values (nor several other > aspects). C++ is an unholy abomination unto Nuggan :-) -- Steve
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-27 12:26 -0500 |
| Message-ID | <mailman.18176.1422379571.18130.python-list@python.org> |
| In reply to | #84633 |
On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote: > I consider return type to be part of the function signature. The > signature > of a function is the parameters it accepts and the result it returns. It's part of it, but not the whole of it, and early C compilers had no information about the parameters except from the call site itself. You could even call the same function multiple different ways (this was later formalized with variadic functions).
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-01-27 17:40 +0000 |
| Message-ID | <mailman.18179.1422380456.18130.python-list@python.org> |
| In reply to | #84633 |
On 27/01/2015 17:26, random832@fastmail.us wrote: > On Tue, Jan 27, 2015, at 01:36, Steven D'Aprano wrote: >> I consider return type to be part of the function signature. The >> signature >> of a function is the parameters it accepts and the result it returns. > > It's part of it, but not the whole of it, and early C compilers had no > information about the parameters except from the call site itself. You > could even call the same function multiple different ways (this was > later formalized with variadic functions). > Back to that old Whitesmith's compiler. It's certainly very interesting to see what the assembler looks like when you forget the ampersand, the compiler doesn't throw an error, and so the entire structure instead of a single pointer gets passed into your function. Not so much passed by value, or reference, or object, but complete foul up :) -- 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 | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2015-01-26 17:10 -0800 |
| Message-ID | <ca841d92-09c6-4735-a63a-16bb806e7155@googlegroups.com> |
| In reply to | #84624 |
On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote:
> Stub files are a second-rate solution for the problem of
> annotating functions where you are unable (or unwilling)
> to annotate the source code directly. They suffer from
> similar problems:
>
> - you have to manage the stub file independently of the
> source code it belongs with
>
> - type information is about as far away from the variable as it
> is possible to get (a completely different file!)
>
> - lexical analysis has to look for twice as many files (it has to
> hit the hard drive for a stub file before looking at the source),
> and we know from importing that file system access is a
> significant and expensive part of the process.
Funny how your example logically leads to the solution of
your own "partisan problem".
At an early stage in the design process, most wise designers
would realize that: since stub files are optional, and
therefore searching for stub files *EVERY TIME* Python is
reading a script is superfluous, then the solution is to
require a declaration in every file that wants typehinting.
In other words, put the onerous on the "typehint author" by
requiring a "typehint declaration" at the top of every file
that has a corresponding typehints stub.
usestypehints scriptA.typehints
Of course, there are much better alternatives than to
introduce *another* keyword. Shebangs, strings, whatever....
So don't take my example too literally!
> But, when the first-rate solution cannot be used, a
> second-rate solution is better than nothing.
Your synthetic "first rate vs second rate" dichotomy is
nothing more than a highly subjective and one sided
interpretation meant to paint the opposition as wrong without
offering any real evidence of "wrongfulness". Are you
attempting to polarize this issue? And if you are, what
possible good could come from injecting emotion into a
technical debate?
To find truths one must remain open to new ideas, *only*
follow logical paths, and *defiantly* reject the corrupting
influence of emotion. Does impartiality mean *anything* to
you? Have you ever wondered why lady justice wears a
blindfold?
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2015-01-27 06:32 +0000 |
| Message-ID | <54c730e2$0$2738$c3e8da3$76491128@news.astraweb.com> |
| In reply to | #84627 |
On Mon, 26 Jan 2015 17:10:18 -0800, Rick Johnson wrote: > On Monday, January 26, 2015 at 6:12:00 PM UTC-6, Steven D'Aprano wrote: > >> Stub files are a second-rate solution for the problem of annotating >> functions where you are unable (or unwilling) to annotate the source >> code directly. They suffer from similar problems: >> >> - you have to manage the stub file independently of the source code it >> belongs with >> >> - type information is about as far away from the variable as it >> is possible to get (a completely different file!) >> >> - lexical analysis has to look for twice as many files (it has to >> hit the hard drive for a stub file before looking at the source), and >> we know from importing that file system access is a significant and >> expensive part of the process. > > Funny how your example logically leads to the solution of your own > "partisan problem". > > At an early stage in the design process, most wise designers would > realize that: since stub files are optional, and therefore searching for > stub files *EVERY TIME* Python is reading a script is superfluous, then > the solution is to require a declaration in every file that wants > typehinting. In other words, put the onerous on the "typehint author" by > requiring a "typehint declaration" at the top of every file that has a > corresponding typehints stub. Unfortunately that doesn't work. Stubs will be needed for extension modules written in C (or some other language), or built-in modules such as sys (which are built into the interpreter). So modules which will need your declaration won't have anywhere to put it! Likewise for byte-code only libraries (no source code distributed, just the .pyc files). And it does nothing to solve the problem that the type declaration is as far away from the parameters as it is possible to be. [...] >> But, when the first-rate solution cannot be used, a second-rate >> solution is better than nothing. > > Your synthetic "first rate vs second rate" dichotomy I'm sure that there are worse solutions that stub/header files. But splitting information about a single function over two files is by any standard sub-optimal. > is nothing more > than a highly subjective and one sided interpretation Just because I have considered and rejected your solution doesn't mean I haven't given it the thought it deserves. Rick, I'll admit that I was being a smart arse with my quip about the seventies wanting their bad ideas back. A separate header file is a reasonable solution to the problem of type hinting when you cannot or will not annotate the actual source. That makes it "bad" merely in a relative sense: it has serious disadvantages compared to in-place annotations, but it is still a workable solution when you can't annotate the source. Analogy: a spoon makes a really poor knife, but if you have nothing else on hand, you can cut vegetables and even the softer cuts of meat using the side of a spoon. > meant to paint the > opposition as wrong without offering any real evidence of > "wrongfulness". Rick, you just quoted me giving three reasons why stub files are less suitable than in-place annotations. How can you justify claiming that I'm not giving evidence of wrongfulness? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-27 12:35 -0500 |
| Message-ID | <mailman.18177.1422380140.18130.python-list@python.org> |
| In reply to | #84624 |
On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote: > > (header files in the 1970s didn't even actually include function > > signature information) - which did not even participate in compilation > > at all. > > If C compilers didn't use the header files, what were they for? My sentence may have been phrased in a confusing way. C compilers did use the header files, and the header files did not include _most_ function signature information (they only included the return type of functions whose return type was not int. Any function not declared was assumed to return int). Lint libraries did contain function signature information, and were not used for compilation (but rather only for running lint). The void type didn't exist either - a function with no declared return type could either return int or return nothing at all. A call site attempting to use the value of such a function would get whatever arbitrary value was in r0. Lint libraries also included return statements for such functions to determine if they returned values or not. Here is an example of a lint library: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/llib-lc Here is stdio.h from the same era. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include/stdio.h Headers also would often not include function declarations even for functions that did have non-int return types. For example, time.h had no function declarations despite many of the time library functions returning pointers, it only contained the definition of struct tm. There was no stdlib.h at all - you were expected to declare e.g. "char *malloc();" yourself if you needed it.
[toc] | [prev] | [next] | [standalone]
| From | random832@fastmail.us |
|---|---|
| Date | 2015-01-27 12:37 -0500 |
| Message-ID | <mailman.18178.1422380228.18130.python-list@python.org> |
| In reply to | #84624 |
On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote: > random832@fastmail.us wrote: > - lexical analysis has to look for twice as many files (it has to > hit the hard drive for a stub file before looking at the source), > and we know from importing that file system access is a > significant and expensive part of the process. The idea is that the type hinting files would not participate in execution at all, only static analysis, so the interpreter doesn't need to look for these things at all, it only needs to ignore them.
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-27 18:59 +0100 |
| Message-ID | <MPG.2f31f0482d3837cb98969f@nntp.aioe.org> |
| In reply to | #84655 |
In article <mailman.18178.1422380228.18130.python-list@python.org>, random832@fastmail.us says... > > On Mon, Jan 26, 2015, at 19:11, Steven D'Aprano wrote: > > random832@fastmail.us wrote: > > - lexical analysis has to look for twice as many files (it has to > > hit the hard drive for a stub file before looking at the source), > > and we know from importing that file system access is a > > significant and expensive part of the process. > > The idea is that the type hinting files would not participate in > execution at all, only static analysis, so the interpreter doesn't need > to look for these things at all, it only needs to ignore them. Like Steven, I do not agree with the idea of adding files for the purposes of static analysis. But you make an important point. Static analysis cannot and should not clutter executable code. Static analysis doesn't require code execution. The Python interpreter doesn't need to be called in. It is for this reason that it makes absolutely no sense to for type hints to be mixed with our code. Let them reside in comments, docstrings, external files, whatever. But never in our code. I'm actually baffled that PEP 484 came into existence, let alone it having any kind of supporter. Here we have a syntax that even requires changes to the interpreter so it can safely ignore all the type hinting clutter that is going to be added by anyone wanting to perform static analysis. And we should also be careful around the argument that type hints are optional. An optional feature says nothing of its requirements. The requirements for PEP 484 are heavy. Not only will they force an update to the interpreter, but will also force many users to reformate their function headers in order for them to become bareable to the eye. In fact, no longer will you look at function definitions like you did before. And an optional feature says nothing of its usage patterns. Type hints may be optional, but they may become a requirement for many projects. In fact, the more complex your project, the more likely you are of wanting to perform static analysis. It's not because type hints are optional that I have some kind of choice about the matter. I may force myself, or be forced, to use them. And if that is the case, I would rather prefer having a syntax that doesn't clutter my ezxecutable code.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-28 07:40 +1100 |
| Message-ID | <mailman.18185.1422391238.18130.python-list@python.org> |
| In reply to | #84658 |
On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo <marfig@gmail.com> wrote: > An optional feature says nothing of its requirements. The requirements > for PEP 484 are heavy. Not only will they force an update to the > interpreter, but will also force many users to reformate their function > headers in order for them to become bareable to the eye. In fact, no > longer will you look at function definitions like you did before. What updates are needed to the interpreter? https://www.python.org/dev/peps/pep-3107/ Already happened, long ago. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-27 21:58 +0100 |
| Message-ID | <MPG.2f321a3382f9c42d9896a2@nntp.aioe.org> |
| In reply to | #84667 |
In article <mailman.18185.1422391238.18130.python-list@python.org>, rosuav@gmail.com says... > > On Wed, Jan 28, 2015 at 4:59 AM, Mario Figueiredo <marfig@gmail.com> wrote: > > An optional feature says nothing of its requirements. The requirements > > for PEP 484 are heavy. Not only will they force an update to the > > interpreter, but will also force many users to reformate their function > > headers in order for them to become bareable to the eye. In fact, no > > longer will you look at function definitions like you did before. > > What updates are needed to the interpreter? > > https://www.python.org/dev/peps/pep-3107/ > > Already happened, long ago. I wasn't aware the interpreter was already able to parse PEP 484. Thank you. Strike that phrase of that paragraph. But what a royal mess! Looking at PEP 3107, i'm left wondering: what if I have for instance already annotated my functions for parameter marshalling, following the syntax expected of that specific library, and now I want to annotate them for type hinting for the purposes of static analysis?
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-28 08:08 +1100 |
| Message-ID | <mailman.18186.1422392925.18130.python-list@python.org> |
| In reply to | #84669 |
On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo <marfig@gmail.com> wrote: > Looking at PEP 3107, i'm left wondering: what if I have for instance > already annotated my functions for parameter marshalling, following the > syntax expected of that specific library, and now I want to annotate > them for type hinting for the purposes of static analysis? This is the kind of argument that keeps on coming up. Everyone has a "What if" scenario about function annotations... and almost nobody actually has a codebase that uses them. It's equivalent to asking: "What if I already used docstrings to control URL routing, and now I want to use them for function documentation?". Well, simple. You move your other-use-of-annotations out to something else (probably a decorator) before you add type hints. Until that time, you're welcome to continue using annotations for something other than type hinting; you just can't do both at once on the same function. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-27 22:19 +0100 |
| Message-ID | <MPG.2f321f4b69ff42fe9896a4@nntp.aioe.org> |
| In reply to | #84671 |
In article <mailman.18186.1422392925.18130.python-list@python.org>,
rosuav@gmail.com says...
>
> On Wed, Jan 28, 2015 at 7:58 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> > Looking at PEP 3107, i'm left wondering: what if I have for instance
> > already annotated my functions for parameter marshalling, following the
> > syntax expected of that specific library, and now I want to annotate
> > them for type hinting for the purposes of static analysis?
>
> This is the kind of argument that keeps on coming up. Everyone has a
> "What if" scenario about function annotations... and almost nobody
> actually has a codebase that uses them. It's equivalent to asking:
> "What if I already used docstrings to control URL routing, and now I
> want to use them for function documentation?". Well, simple. You move
> your other-use-of-annotations out to something else (probably a
> decorator) before you add type hints. Until that time, you're welcome
> to continue using annotations for something other than type hinting;
> you just can't do both at once on the same function.
>
> ChrisA
I'm sorry Chris. But that's a weak argument and you know it. If I use
those decorators inside properly formated docstrings, I can do both
things, and more! And I don't have to move anything anywhere.
def func(a, b, c):
"""
This function does something very interesting and returns a surprise
:a: an integer, also known as whole number (lies!)
:b: a float on a string so it can't escape
:c: an unicode string with some bad language
@typehint@ some crazy syntax for static analysis
@marshallib@ more crazy syntax for the marshall lib
@anotherlib@ Whoohoo! a 3rd annotation for another lib
"""
Are you telling me this is not a viable alternative. That somehow we
should ignore the possibility of potentially different annotations
having to coexist on a project? C'mon!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-28 08:24 +1100 |
| Message-ID | <mailman.18187.1422393854.18130.python-list@python.org> |
| In reply to | #84672 |
On Wed, Jan 28, 2015 at 8:19 AM, Mario Figueiredo <marfig@gmail.com> wrote: > @typehint@ some crazy syntax for static analysis > @marshallib@ more crazy syntax for the marshall lib > @anotherlib@ Whoohoo! a 3rd annotation for another lib > """ > > Are you telling me this is not a viable alternative. That somehow we > should ignore the possibility of potentially different annotations > having to coexist on a project? C'mon! Sure you can! But this is *itself* a weak argument, unless you actually have a codebase that uses it. YAGNI comes to mind. When do you actually need to annotate with multiple styles like this, and should everyone pay the price (the disconnect from from the function name) even though this is almost never needed? ChrisA
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web