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 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-27 22:35 +0100 |
| Message-ID | <MPG.2f3222dbf8501a419896a5@nntp.aioe.org> |
| In reply to | #84673 |
In article <mailman.18187.1422393854.18130.python-list@python.org>, rosuav@gmail.com says... > > Sure you can! But this is *itself* a weak argument, unless you > actually have a codebase that uses it. Wait. Are you saying that unless I show you a codebase that requires marshalling and static analysis, you will ignore the fact that a project, no matter its size, may require more than one annotation type? In other words, lets suggest function annotations as a restrictive feature, instead of a feature that can adapt to more than one use case. > 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? That is your price. My price is seeing my executable code cluttered with static fluff. Very pythonesc, I suppose...
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-27 22:39 +0100 |
| Message-ID | <MPG.2f3223d5959d93b9896a6@nntp.aioe.org> |
| In reply to | #84674 |
I can now start to understand the criticism of how Python is evolving coming from many corners, either long term python educators like Mark Lutz.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-28 08:53 +1100 |
| Message-ID | <mailman.18188.1422395602.18130.python-list@python.org> |
| In reply to | #84674 |
On Wed, Jan 28, 2015 at 8:35 AM, Mario Figueiredo <marfig@gmail.com> wrote: > In other words, lets suggest function annotations as a restrictive > feature, instead of a feature that can adapt to more than one use case. PEP 3107 made a feature that can adapt to more than one use case. It's been years now, and the use-cases originally suggested are the only ones actually seen in the wild. Apparently nobody has actually come up with a need for the flexibility. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-28 13:05 +1100 |
| Message-ID | <54c843fe$0$12984$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84669 |
Mario Figueiredo 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? You cannot simultaneously follow two competing standards. If you have a library that expects annotations to represent (let's say) parameter marshalling, and another library that expects annotations to represent documentation, and a third library that expects annotations to represent hyperlinks to external resources, and a fourth that expects them to be used for range checking, would you expect to be able to use all four competing and incompatible uses of annotations in the same function at the same time? Or even any two such libraries at the same time? Of course not. At best, each library will ignore annotations that it doesn't understand. Possibly they will print warnings, or raise exceptions, and force you to choose between them. At worst, the libraries will misinterpret the annotation and do the wrong thing, with consequences ranging from annoying to disastrous. But unless all four libraries are designed from the start to cooperate, you cannot expect them to cooperate. Why should type hints be held to a higher (and impossible) standard? If you use annotations for some other purposes, your choices post-PEP 484 will become: - Do absolutely nothing different, and your annotations will continue to work exactly as they currently do. You're not currently running a type-checker which expects annotations to be type-hints, so you merely continue *not running* such a type-checker. Or, if you decide that you do want to run a type-checker: - Find a type-checker that doesn't use annotations, and use whatever rules it uses. I believe some linters (obiwan comes to mind?) may use type hints in docstrings to do simple type checking. Find such a tool, or write your own, and use it. - Find a type-checker which can cooperatively interoperate with your existing use of annotations, if such a thing exists. Feel free to write one if you wish, or pony up the money to pay somebody else to do so. - Use a stub file, and a type-checker which will ignore the annotations and use the stub file instead. - Give up on your dream of lexical analysis of Python. You can't have everything, and your Python experience will be just like 2014 all over again. - Give up on your current use of annotations, and replace them with type-hints. - Change to some other language that does everything you want, and re-write your entire application in this new language. - Stamp your feet and hold your breath until you collapse and see if that helps. (It probably won't, but my two year old nephew[1] thinks it does.) PEP 484 gives you many choices, starting with "do absolutely nothing, and absolutely nothing will change". [1] Actually, that's a gross slander. For somebody right in the middle of the terrible twos, he's relatively sweet natured and well behaved. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-28 12:26 +1100 |
| Message-ID | <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84658 |
Mario Figueiredo wrote: > Static analysis cannot and should not clutter executable code. (1) It isn't clutter. The human reader uses that information as well as the compiler, interpreter, type-checker, IDE, text editor, correctness tester, etc. (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens (hundreds?) of other languages disagree with you. > Let [type-hints] reside in comments, docstrings, external files, whatever. Didn't you criticise the use of type-hints in comments earlier? Or am I confusing you with somebody else? > 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. That *absolutely is not true*. I don't know where you get this from. Python 3 has supported function annotations for over five years now. The only change required with PEP 484 is to give those annotations a standard meaning and encourage people to use them for type-checking instead of whatever other uses they have or haven't (mostly haven't) thought of. > 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. Again, this is wrong. PEP 484 requires *no* update to the interpreter. It adds a single library file to the standard library, but use of that is optional. It requires *nobody* to rewrite or reformate their function headers. The only people who will do so are those who want to run type-checkers which support type-hints. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Skip Montanaro <skip.montanaro@gmail.com> |
|---|---|
| Date | 2015-01-28 08:10 -0600 |
| Message-ID | <mailman.18218.1422454252.18130.python-list@python.org> |
| In reply to | #84700 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Jan 27, 2015 at 7:26 PM, Steven D'Aprano < steve+comp.lang.python@pearwood.info> wrote: > (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, > Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens > (hundreds?) of other languages disagree with you. > Well, sure. But that's always been one of the nice things about Python, less visual clutter. While I understand where all the type hinting activity is coming from (and accept it as inevitable), I'm also sympathetic to Mario's perspective. Python-1.5-anyone?-ly, y'rs, Skip
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-28 16:04 +0100 |
| Message-ID | <MPG.2f3318cb4d02fd059896b2@nntp.aioe.org> |
| In reply to | #84700 |
In article <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com>,
steve+comp.lang.python@pearwood.info says...
>
> Mario Figueiredo wrote:
>
> > Static analysis cannot and should not clutter executable code.
>
> (1) It isn't clutter. The human reader uses that information as well as the
> compiler, interpreter, type-checker, IDE, text editor, correctness tester,
> etc.
>
> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go,
> Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens
> (hundreds?) of other languages disagree with you.
>
Sorry. Somehow I missed this post. Only realized now from the Skip
answer.
This is simply not true!
For most of the strongly typed languages (e.g. static typed languages)
in that list -- C, C++, C# and Scala, the ones I know best from that
list -- require little to no annotations in the code (and certainly no
new explicit function or class based syntax) in order for static
analysers to perform their thing, except perhaps on the most exotic
static analysers.
Being a strongly typed language, there is no need for added information
in the function signatures. From that list you can safely exclude all
strongly-typed languages.
For dynamically typed languages, what I have seen being implemented on
almost all cases is doc-like features for type annotation. Of the list
you provide (few there are dynamically typed, btw) Julia is the one I
know of. Julia implements a similar type annotation to type annotations
in Python. In fact I see a lot of Julia in PEP 484. But with different
objectives:
function add(a::Int, b::Int)
a + b
end
Here the :: annotation is meant to attribute a type in an otherwise
dynamically typed language and that function signature is executed at
runtime with all the implications of a statically typed signature.
Static analysis in Julia admitedly can only be performed if those
annotations are present, and of the entire list you provide this is the
only example language that more closely matches your argument. The
others simply are not true.
But in any case, in Julia type annotations, contrary to Python, are
evaluated at runtime. It then makes all sense for them to coexist with
the language syntax.
[toc] | [prev] | [next] | [standalone]
| From | wxjmfauth@gmail.com |
|---|---|
| Date | 2015-01-28 07:40 -0800 |
| Message-ID | <bb056488-5ebb-485a-8ecb-77b7d3836806@googlegroups.com> |
| In reply to | #84760 |
Le mercredi 28 janvier 2015 16:04:35 UTC+1, Mario Figueiredo a écrit : > In article <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com>, > steve+comp.lang.python@pearwood.info says... > > > > Mario Figueiredo wrote: > > > > > Static analysis cannot and should not clutter executable code. > > > > (1) It isn't clutter. The human reader uses that information as well as the > > compiler, interpreter, type-checker, IDE, text editor, correctness tester, > > etc. > > > > (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, > > Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens > > (hundreds?) of other languages disagree with you. > > > > Sorry. Somehow I missed this post. Only realized now from the Skip > answer. > > This is simply not true! > > For most of the strongly typed languages (e.g. static typed languages) > in that list -- C, C++, C# and Scala, the ones I know best from that > list -- require little to no annotations in the code (and certainly no > new explicit function or class based syntax) in order for static > analysers to perform their thing, except perhaps on the most exotic > static analysers. > > Being a strongly typed language, there is no need for added information > in the function signatures. From that list you can safely exclude all > strongly-typed languages. > > For dynamically typed languages, what I have seen being implemented on > almost all cases is doc-like features for type annotation. Of the list > you provide (few there are dynamically typed, btw) Julia is the one I > know of. Julia implements a similar type annotation to type annotations > in Python. In fact I see a lot of Julia in PEP 484. But with different > objectives: > > function add(a::Int, b::Int) > a + b > end > > Here the :: annotation is meant to attribute a type in an otherwise > dynamically typed language and that function signature is executed at > runtime with all the implications of a statically typed signature. > > Static analysis in Julia admitedly can only be performed if those > annotations are present, and of the entire list you provide this is the > only example language that more closely matches your argument. The > others simply are not true. > > But in any case, in Julia type annotations, contrary to Python, are > evaluated at runtime. It then makes all sense for them to coexist with > the language syntax. I toyed with Julia (0.3.0rc3) only to see what this language has to offer on the side of Unicode. A very good suprise. Contrary to Python, it works. jmf
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-01-28 10:33 -0700 |
| Message-ID | <mailman.18224.1422466472.18130.python-list@python.org> |
| In reply to | #84760 |
On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo <marfig@gmail.com> wrote:
> In article <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com>,
> steve+comp.lang.python@pearwood.info says...
>>
>> Mario Figueiredo wrote:
>>
>> > Static analysis cannot and should not clutter executable code.
>>
>> (1) It isn't clutter. The human reader uses that information as well as the
>> compiler, interpreter, type-checker, IDE, text editor, correctness tester,
>> etc.
>>
>> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go,
>> Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens
>> (hundreds?) of other languages disagree with you.
>>
>
> Sorry. Somehow I missed this post. Only realized now from the Skip
> answer.
>
> This is simply not true!
>
> For most of the strongly typed languages (e.g. static typed languages)
Python is a strongly typed language. It checks types at runtime and
does little implicit type conversion. Strong != static.
> in that list -- C, C++, C# and Scala, the ones I know best from that
> list -- require little to no annotations in the code (and certainly no
> new explicit function or class based syntax) in order for static
> analysers to perform their thing, except perhaps on the most exotic
> static analysers.
The languages you cite don't require extra type annotations because
they already have the types in the function signatures. Here's an
example function signature in Scala:
def addInt( a:Int, b:Int ) : Int
How is that significantly different from a Python function that uses
the proposed annotations?
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-29 11:37 +1100 |
| Message-ID | <54c980cd$0$12981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84768 |
Ian Kelly wrote: > On Wed, Jan 28, 2015 at 8:04 AM, Mario Figueiredo <marfig@gmail.com> > wrote: >> In article <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com>, >> steve+comp.lang.python@pearwood.info says... >>> >>> Mario Figueiredo wrote: >>> >>> > Static analysis cannot and should not clutter executable code. >>> >>> (1) It isn't clutter. The human reader uses that information as well as >>> the compiler, interpreter, type-checker, IDE, text editor, correctness >>> tester, etc. >>> >>> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, >>> Go, Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens >>> (hundreds?) of other languages disagree with you. >>> >> >> Sorry. Somehow I missed this post. Only realized now from the Skip >> answer. >> >> This is simply not true! >> >> For most of the strongly typed languages (e.g. static typed languages) > > Python is a strongly typed language. It checks types at runtime and > does little implicit type conversion. Strong != static. > >> in that list -- C, C++, C# and Scala, the ones I know best from that >> list -- require little to no annotations in the code (and certainly no >> new explicit function or class based syntax) in order for static >> analysers to perform their thing, except perhaps on the most exotic >> static analysers. > > The languages you cite don't require extra type annotations because > they already have the types in the function signatures. Here's an > example function signature in Scala: > > def addInt( a:Int, b:Int ) : Int > > How is that significantly different from a Python function that uses > the proposed annotations? Ian, that's obvious. Just open your eyes: Scala def addInt( a:Int, b:Int ) : Int Python def addInt( a:int, b:int ) -> int: They're COMPLETELY different. In Scala they are *type declarations*, not annotations. We're talking about annotations, not declarations. They're as different as cheese and a very slightly different cheese. Do try to keep up. *wink* -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2015-01-29 11:43 +1100 |
| Message-ID | <mailman.18249.1422492226.18130.python-list@python.org> |
| In reply to | #84796 |
On Thu, Jan 29, 2015 at 11:37 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > They're as > different as cheese and a very slightly different cheese. Do try to keep > up. As different as brie and camembert? ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-29 09:34 +0100 |
| Message-ID | <MPG.2f340edca45427349896b4@nntp.aioe.org> |
| In reply to | #84796 |
In article <54c980cd$0$12981$c3e8da3$5496439d@news.astraweb.com>, steve+comp.lang.python@pearwood.info says... > > Ian, that's obvious. Just open your eyes: > > Scala > def addInt( a:Int, b:Int ) : Int > > Python > def addInt( a:int, b:int ) -> int: > > > They're COMPLETELY different. In Scala they are *type declarations*, not > annotations. We're talking about annotations, not declarations. They're as > different as cheese and a very slightly different cheese. Do try to keep > up. > > *wink* The sarcasm is unnecessary. They are different yes. Are you on purpose confusing the syntax of a feature with its meaning? Because while you have a very similar syntax between Julia, Scala and Python. Their meanings are very different. I think it is obvious to anyone that if a feature like type annotations are meant to be EVALUATED AT RUNTIME (and I myself gave you another example of Julia), it makes every sense for that feature to be a part of the programming language syntax. I could never argue against Julia or Scala type annotations on that basis. The syntax is an integral part of the executable code. But when a feature is not meant for runtime evaluation, why should it clutter your executable code? Make me understand your reasoning? Your list of programming languages is just plain wrong. To my knowledge (there's a few languages there I don't know and never used), none of those languages implement anything like Python. Type annotations in python are entirely ignored by the interpreter except to make them available to external libraries. This is a feature that I have seen implemented in numerous languages as a part of doc-like comments. Never, ever, as a part ofthe language syntax.
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2015-01-29 09:30 -0700 |
| Message-ID | <mailman.18266.1422549052.18130.python-list@python.org> |
| In reply to | #84808 |
On Thu, Jan 29, 2015 at 1:34 AM, Mario Figueiredo <marfig@gmail.com> wrote: > In article <54c980cd$0$12981$c3e8da3$5496439d@news.astraweb.com>, > steve+comp.lang.python@pearwood.info says... >> >> Ian, that's obvious. Just open your eyes: >> >> Scala >> def addInt( a:Int, b:Int ) : Int >> >> Python >> def addInt( a:int, b:int ) -> int: >> >> >> They're COMPLETELY different. In Scala they are *type declarations*, not >> annotations. We're talking about annotations, not declarations. They're as >> different as cheese and a very slightly different cheese. Do try to keep >> up. >> >> *wink* > > The sarcasm is unnecessary. They are different yes. Are you on purpose > confusing the syntax of a feature with its meaning? Because while you > have a very similar syntax between Julia, Scala and Python. Their > meanings are very different. > > I think it is obvious to anyone that if a feature like type annotations > are meant to be EVALUATED AT RUNTIME (and I myself gave you another > example of Julia), it makes every sense for that feature to be a part of > the programming language syntax. I could never argue against Julia or > Scala type annotations on that basis. The syntax is an integral part of > the executable code. Okay, I don't know enough about Scala's type system to discuss that example in this context, so I won't try to. Let's instead focus on another of the languages you listed: C. C includes types in its syntax, which it uses for static analysis at compile time. At runtime, it uses them for ... nothing. In fact, if you examine a compiled C binary, you won't even find any type information in there. If you dynamically load a C library containing a function that takes a double, and you pass it a long, it won't even blink. It will just assume that the data it received represents a double and proceed from there. Now with PEP 484 type annotations on the other hand, while the suggested static analysis tools aren't used at runtime, the annotations themselves are available to be evaluated at runtime. If you want to write a decorator that examines the types of the arguments of the function it decorates and does something nifty with them (automatic registration of overloaded functions using PEP 443 generics, perhaps), there is absolutely nothing stopping you from doing that.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-30 03:41 +1100 |
| Message-ID | <54ca62ca$0$13000$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84808 |
Mario Figueiredo wrote:
> In article <54c980cd$0$12981$c3e8da3$5496439d@news.astraweb.com>,
> steve+comp.lang.python@pearwood.info says...
>>
>> Ian, that's obvious. Just open your eyes:
>>
>> Scala
>> def addInt( a:Int, b:Int ) : Int
>>
>> Python
>> def addInt( a:int, b:int ) -> int:
>>
>>
>> They're COMPLETELY different. In Scala they are *type declarations*, not
>> annotations. We're talking about annotations, not declarations. They're
>> as different as cheese and a very slightly different cheese. Do try to
>> keep up.
>>
>> *wink*
>
> The sarcasm is unnecessary. They are different yes. Are you on purpose
> confusing the syntax of a feature with its meaning? Because while you
> have a very similar syntax between Julia, Scala and Python. Their
> meanings are very different.
No they aren't. Their primary meaning is to declare the type used by the
parameter.
> I think it is obvious to anyone that if a feature like type annotations
> are meant to be EVALUATED AT RUNTIME (and I myself gave you another
> example of Julia), it makes every sense for that feature to be a part of
> the programming language syntax. I could never argue against Julia or
> Scala type annotations on that basis. The syntax is an integral part of
> the executable code.
Ah, you mean just like Python, where annotations are evaluated at runtime,
just like Julia:
py> def spam(n:int)-> getattr(sys, 'version'):
... return "spam"*n
...
py> spam.__annotations__
{'n': <class 'int'>, 'return': '3.3.0rc3 (default, Sep 27 2012, 18:44:58)
\n[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)]'}
Python has had annotations for over five years. They are evaluated at
runtime. They will continue to be evaluated at runtime.
One of the benefits of this system is that people may write *runtime*
type-checkers that use the same annotations that the lexical analysis tools
will use.
It is possible that you aren't following the meaning of this. The idea
behind PEP 484 is that Python will standardise on a single expected syntax
for type-hints, so that all of the following tools can agree on a set of
basic rules for interpreting the annotations:
- lexical type-checkers (those that operate on only the source code,
with no runtime information)
- alternate Python compilers, like MyPy, which perform compile-time
type checking
- IDEs and text editors, which may use lexical type info available
in the source code to flag errors and offer auto-completion
- stand-alone tools such as correctness provers
- documentation generators
- runtime type-checkers
- runtime introspection tools
and more.
One of the rules is that the *standard* type-hints have to be simple enough
that a purely lexical tool like an IDE or editor can understand it without
needing to run arbitrary code. But the annotations themselves can be
arbitrarily complex Python expressions. Its just that then the tools
expecting type-hints won't be able to process those annotations from the
source code alone. Runtime introspection tools will not care, because they
don't see the expression, they only see the result of evaluating that
expression.
> But when a feature is not meant for runtime evaluation, why should it
> clutter your executable code? Make me understand your reasoning?
Perhaps you should ask the designers of Pascal, Go, Scheme, C, D, F# and all
those dozens and hundreds of other languages. They have a feature which is
not evaluated at runtime -- the type declarations -- and they put it in the
source code.
And why shouldn't they? Type declarations are source code!
> Your list of programming languages is just plain wrong. To my knowledge
> (there's a few languages there I don't know and never used), none of
> those languages implement anything like Python.
Not so.
> Type annotations in
> python are entirely ignored by the interpreter except to make them
> available to external libraries.
That is incorrect.
Perhaps you are confusing by the fact that the Python interpreter doesn't
give any meaning to annotations? It still evaluates them at runtime, and
stores the result in the function object.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-01-28 18:16 +0000 |
| Message-ID | <mailman.18229.1422469034.18130.python-list@python.org> |
| In reply to | #84760 |
On 28/01/2015 15:04, Mario Figueiredo wrote: > In article <54c83ab4$0$12982$c3e8da3$5496439d@news.astraweb.com>, > steve+comp.lang.python@pearwood.info says... >> >> Mario Figueiredo wrote: >> >>> Static analysis cannot and should not clutter executable code. >> >> (1) It isn't clutter. The human reader uses that information as well as the >> compiler, interpreter, type-checker, IDE, text editor, correctness tester, >> etc. >> >> (2) Algol, Ada, Boo, C, C#, C++, Cobol, Cobra, D, F#, Fantom, Fortran, Go, >> Haskell, Java, Julia, Kotlin, Oberon, Pascal, Rust, Scala and dozens >> (hundreds?) of other languages disagree with you. >> > > Sorry. Somehow I missed this post. Only realized now from the Skip > answer. > > This is simply not true! > > For most of the strongly typed languages (e.g. static typed languages) > in that list -- C, C++, C# and Scala, the ones I know best from that > list -- require little to no annotations in the code (and certainly no > new explicit function or class based syntax) in order for static > analysers to perform their thing, except perhaps on the most exotic > static analysers. C and C++ are weakly and statically typed languages. Python is a strongly and dynamically typed language. Therefore anything following based on the above paragraph alone is wrong. > > Being a strongly typed language, there is no need for added information > in the function signatures. From that list you can safely exclude all > strongly-typed languages. > > For dynamically typed languages, what I have seen being implemented on > almost all cases is doc-like features for type annotation. Of the list > you provide (few there are dynamically typed, btw) Julia is the one I > know of. Julia implements a similar type annotation to type annotations > in Python. In fact I see a lot of Julia in PEP 484. But with different > objectives: > > function add(a::Int, b::Int) > a + b > end > > Here the :: annotation is meant to attribute a type in an otherwise > dynamically typed language and that function signature is executed at > runtime with all the implications of a statically typed signature. > > Static analysis in Julia admitedly can only be performed if those > annotations are present, and of the entire list you provide this is the > only example language that more closely matches your argument. The > others simply are not true. > > But in any case, in Julia type annotations, contrary to Python, are > evaluated at runtime. It then makes all sense for them to coexist with > the language syntax. > -- 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 | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-29 09:23 +0100 |
| Message-ID | <MPG.2f340c6ea39d9f3f9896b3@nntp.aioe.org> |
| In reply to | #84776 |
In article <mailman.18229.1422469034.18130.python-list@python.org>, breamoreboy@yahoo.co.uk says... > > C and C++ are weakly and statically typed languages. Python is a > strongly and dynamically typed language. Therefore anything following > based on the above paragraph alone is wrong. > Indeed. I confused strongly/weakly with static. I feel a a bit embarrased by it. My apologies. But no. Nothing that follows from that paragraph is wrong, just because of that mistake. It still stands that list was artifically created to make it look like type annotations on top of executable code is a feature of nearly every language in the book. When it is not! Most particularly when it comes to statically typed languages, wich Steven didn't feel guilty of including there.
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2015-01-29 08:49 +0000 |
| Message-ID | <mailman.18257.1422521412.18130.python-list@python.org> |
| In reply to | #84806 |
On 29/01/2015 08:23, Mario Figueiredo wrote: > In article <mailman.18229.1422469034.18130.python-list@python.org>, > breamoreboy@yahoo.co.uk says... >> >> C and C++ are weakly and statically typed languages. Python is a >> strongly and dynamically typed language. Therefore anything following >> based on the above paragraph alone is wrong. >> > > Indeed. I confused strongly/weakly with static. I feel a a bit > embarrased by it. My apologies. Accepted, from me anyhow. Please remember the only person who never makes a mistake never does anything :) > > But no. Nothing that follows from that paragraph is wrong, just because > of that mistake. I should have emphasied the word *alone*, sorry about that. > > It still stands that list was artifically created to make it look like > type annotations on top of executable code is a feature of nearly every > language in the book. When it is not! > > Most particularly when it comes to statically typed languages, wich > Steven didn't feel guilty of including there. > I don't know enough about most other languages to comment, I'll leave that to the various gurus. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2015-01-30 03:11 +1100 |
| Message-ID | <54ca5bbf$0$12992$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #84806 |
Mario Figueiredo wrote: > In article <mailman.18229.1422469034.18130.python-list@python.org>, > breamoreboy@yahoo.co.uk says... >> >> C and C++ are weakly and statically typed languages. Python is a >> strongly and dynamically typed language. Therefore anything following >> based on the above paragraph alone is wrong. >> > > Indeed. I confused strongly/weakly with static. I feel a a bit > embarrased by it. My apologies. > > But no. Nothing that follows from that paragraph is wrong, just because > of that mistake. > > It still stands that list was artifically created to make it look like > type annotations on top of executable code is a feature of nearly every > language in the book. When it is not! > > Most particularly when it comes to statically typed languages, wich > Steven didn't feel guilty of including there. Why should I feel guilty? You wrote: "Static analysis cannot and should not clutter executable code." But what are type declarations in statically typed languages like C, Pascal, Haskell, etc.? They are used by the compiler for static analysis. The same applies to type declarations in dynamically typed languages like Cobra and Julia. And yet, there they are, in the executable code. So there are a whole lot of languages, going all the way back to 1950s languages like Fortran, to some of the newest languages which are only a few years old like Go, both dynamically typed and statically typed, which do exactly what you say languages "cannot and should not" do: they put type information used for static analysis there in the code. As I said, these languages disagree with you. You are not just arguing against Guido, but against the majority of programming language designers for 60+ years. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2015-01-29 13:12 -0800 |
| Message-ID | <0f28e2c1-55d2-41fa-b18b-c8d4ca474809@googlegroups.com> |
| In reply to | #84822 |
On Thursday, January 29, 2015 at 10:11:56 AM UTC-6, Steven D'Aprano wrote:
>
> But what are type declarations in statically typed
> languages like C, Pascal, Haskell, etc.? They are used by
> the compiler for static analysis. The same applies to type
> declarations in dynamically typed languages like Cobra and
> Julia. And yet, there they are, in the executable code.
>
> So there are a whole lot of languages, going all the way
> back to 1950s languages like Fortran, to some of the
> newest languages which are only a few years old like Go,
> both dynamically typed and statically typed, which do
> exactly what you say languages "cannot and should not" do:
> they put type information used for static analysis there
> in the code.
>
> As I said, these languages disagree with you. You are not
> just arguing against Guido, but against the majority of
> programming language designers for 60+ years.
Are we really going to base our design decisions on the same
emotional "need to belong" that a 14 year girl bases clothing
purchases on? Following your logic, it's high time we adopt
braces, since they have been just as long!
===================================================================
WELCOME TO COMPUTER LANGUAGE JEOPARDY!
===================================================================
|--------------------------|---------------|-doot------------|----|
|--------------------------|---------------|-----do----------|----|
|--------------------------|---------------|-------do--------|----|
|--dah-----------dah-------|----dah----dah-|---------do------|----|
|--------------------------|---------------|-----------do----|----|
|do---doo-----do-----dooooo|-do----do------|-------------do--|----|
|---------doo--------------|---------------|-----------------|doot|
===================================================================
@2nd skip-------> D.C.
"And here is your host: Alex Trebek!
TREBEK: I swear i was not drunk when i sideswiped an array of mailboxes and ended up kissing a telephone pole in a ditch 45 feet away... so shut up about it already!
[snip: totally scripted introductions]
TREBEK: Okay let's begin!
PLAYER1: Alex, i'll take "Language Devolution" for 500 please.
TREBEK: Okay, and the answer is: "Python Type Hints"
(CHIME) PLAYER1: What does a book-licking contest look like?
*WAAAANK*
TREBEK: Sorry, while your answer certainly is a product of such a proposal, we're looking for something more specific to the category of: "Language Devolution".
(CHIME) PLAYER2: Python Insanity Proposal?
*WAAAANK*
TREBEK: Again, technically correct, but your answer must be in the form of a question!
(CHIME) PLAYER3: What happens after an emperor forsakes his clothing?
*DING-DING-DING*
TREBEK: Congrats, you're this weeks winner! Please stay tuned for a special episode of "Keeping Up With The Kewl Kids". Good night folks!
[This episode was sponsored by Alex's AA group]
[toc] | [prev] | [next] | [standalone]
| From | Mario Figueiredo <marfig@gmail.com> |
|---|---|
| Date | 2015-01-30 19:36 +0100 |
| Message-ID | <MPG.2f34ebd12b42ff6f9896b5@nntp.aioe.org> |
| In reply to | #84822 |
In article <54ca5bbf$0$12992$c3e8da3$5496439d@news.astraweb.com>, steve+comp.lang.python@pearwood.info says... > > Why should I feel guilty? You wrote: > > > "Static analysis cannot and should not clutter executable code." > > > But what are type declarations in statically typed languages like C, Pascal, > Haskell, etc.? They are used by the compiler for static analysis. The same > applies to type declarations in dynamically typed languages like Cobra and > Julia. And yet, there they are, in the executable code. > > So there are a whole lot of languages, going all the way back to 1950s > languages like Fortran, to some of the newest languages which are only a > few years old like Go, both dynamically typed and statically typed, which > do exactly what you say languages "cannot and should not" do: they put type > information used for static analysis there in the code. You are confusing static analysis with compile time checking which produces side-effects like implicit conversion for instance and that affects the resulting binary code. Something that Python won't do with type annotations. And something that Julia, Scala or C does. This is also the first time I hear compilation time mentioned as static analysis. To be clear, type declarations in Julia, Scala, C have the potential to produce side-effects, can result in optimized code and can result in compile time errors or warnings. Type annotations in Python are instead completely ignored by the interpreter. They do nothing of the above. They do not participate in code execution. > As I said, these languages disagree with you. You are not just arguing > against Guido, but against the majority of programming language designers > for 60+ years. You are right. I'm not arguing against Guido. I have yet to hear his opinion on your or mine arguments. I'm not arguing against the majority of programming languages either, because they agree with me. I'm arguing with you.
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.python
csiph-web