Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #21634 > unrolled thread
| Started by | Kiuhnm <kiuhnm03.4t.yahoo.it> |
|---|---|
| First post | 2012-03-15 00:34 +0100 |
| Last post | 2012-03-18 18:19 +0000 |
| Articles | 20 on this page of 201 — 36 participants |
Back to article view | Back to comp.lang.python
Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 00:34 +0100
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-14 23:54 +0000
Re: Python is readable Tony the Tiger <tony@tiger.invalid> - 2012-03-14 19:18 -0500
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 11:27 +1100
Re: Python is readable Rick Johnson <rantingrickjohnson@gmail.com> - 2012-03-14 20:02 -0700
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-03-14 23:23 -0700
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 11:44 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 21:50 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:27 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 22:47 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:59 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 23:21 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-15 23:31 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-15 23:38 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 00:16 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 00:33 +1100
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 00:50 +1100
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-15 17:43 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:16 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 01:29 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:37 +0100
Re: Python is readable Roy Smith <roy@panix.com> - 2012-03-15 11:14 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:27 +1100
Re: Python is readable Roy Smith <roy@panix.com> - 2012-03-15 11:44 -0400
Re: Python is readable Alec Taylor <alec.taylor6@gmail.com> - 2012-03-16 03:01 +1100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 17:41 +0000
Re: Python is readable Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-15 12:14 +0100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 12:48 +0100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 14:06 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:19 +0100
Re: Python is readable Tim Golden <mail@timgolden.me.uk> - 2012-03-15 14:28 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:55 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:08 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 20:40 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-15 16:12 -0600
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 09:35 +1100
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-15 23:00 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 00:46 +0100
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-15 23:58 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 12:41 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 00:15 +0000
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-16 10:57 +1100
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-15 15:13 +0000
Re: Python is readable Serhiy Storchaka <storchaka@gmail.com> - 2012-03-15 21:43 +0200
Re: Python is readable Alec Taylor <alec.taylor6@gmail.com> - 2012-03-16 01:17 +1100
Re: Python is readable Duncan Booth <duncan.booth@invalid.invalid> - 2012-03-15 14:23 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 15:30 +0100
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-15 14:43 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 16:18 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-15 16:17 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 00:32 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 03:55 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:10 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:48 +0000
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-16 17:39 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 22:22 +0100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 20:59 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 08:20 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 22:28 +0100
Re: Python is readable Michael Torrie <torriem@gmail.com> - 2012-03-17 17:04 -0600
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:15 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 11:57 +0000
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-18 11:42 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 01:36 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:34 +0100
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 16:56 +1100
Re: Python is readable MRAB <python@mrabarnett.plus.com> - 2012-03-31 18:27 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 01:48 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-15 16:05 +0100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 02:14 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-15 23:52 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-16 14:12 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:36 +0100
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 12:50 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 13:03 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 13:08 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:28 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 17:53 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 18:50 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-16 19:35 +0000
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-16 20:04 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 21:54 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 00:57 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 12:07 +1100
Re: Python is readable Steven D'Aprano <steve+usenet@pearwood.info> - 2012-03-18 02:05 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-18 13:15 +1100
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-21 00:57 +0100
Re: Python is readable Mel Wilson <mwilson@the-wire.com> - 2012-03-16 16:01 -0400
Re: Python is readable Ethan Furman <ethan@stoneleaf.us> - 2012-03-16 13:30 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-17 07:59 +1100
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-17 01:09 -0400
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-19 11:26 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 11:51 +0000
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-19 12:53 +0000
Re: Python is readable Robert Kern <robert.kern@gmail.com> - 2012-03-19 14:38 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-17 21:23 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-18 01:46 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-19 12:44 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 15:27 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-21 00:27 +0100
Re: Python is readable Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-03-15 16:41 +0100
Re: Python is readable Duncan Booth <duncan.booth@invalid.invalid> - 2012-03-16 09:30 +0000
Re: Python is readable John Ladasky <ladasky@my-deja.com> - 2012-03-18 14:30 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-19 09:02 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 01:23 +0000
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-19 15:33 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-19 13:37 +0000
Re: Python is readable Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-20 12:20 +0000
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-03-18 20:15 -0700
Re: Python is readable Chris Rebert <clp2@rebertia.com> - 2012-03-18 21:14 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 12:55 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-20 17:48 +0000
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-20 14:09 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 15:28 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 00:22 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 18:28 -0700
Re: Python is readable Ben Finney <ben+python@benfinney.id.au> - 2012-03-21 13:28 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 19:44 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 15:16 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 21:58 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 16:40 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-20 23:52 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 17:59 +1100
Re: Python is readable Chris Rebert <clp2@rebertia.com> - 2012-03-21 00:16 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 00:57 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-21 19:15 +1100
Re: Re: Python is readable Evan Driscoll <driscoll@cs.wisc.edu> - 2012-03-21 11:22 -0500
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 09:30 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-21 14:06 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 18:35 -0700
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 08:56 +0000
Re: Python is readable (OT) Jon Clements <joncle@googlemail.com> - 2012-03-22 04:18 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 08:47 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 17:18 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 14:26 -0400
Re: Python is readable Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-29 13:44 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-29 14:37 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 01:42 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-29 22:26 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 03:36 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 00:38 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 10:47 +0000
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 09:46 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 03:20 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 14:15 -0400
Re: Python is readable Neil Cerutti <neilc@norwich.edu> - 2012-03-30 20:30 +0000
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-04-01 20:38 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 05:29 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 15:55 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 07:20 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 22:07 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-04-03 08:06 +1000
Re: Python is readable Dan Sommers <dan@tombstonezero.net> - 2012-03-30 16:51 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 16:58 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 08:45 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-30 19:01 -0400
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-31 00:03 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-31 19:05 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-31 10:43 -0400
Re: Python is readable rusi <rustompmody@gmail.com> - 2012-03-30 11:17 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 09:02 -0700
Re: Python is readable alex23 <wuwei23@gmail.com> - 2012-04-01 20:30 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-04-01 21:01 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-29 23:44 -0700
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-30 16:40 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-30 00:27 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:08 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 00:17 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 10:29 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 09:12 -0700
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-22 17:44 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 19:42 -0700
Re: Python is readable rusi <rustompmody@gmail.com> - 2012-03-22 20:20 -0700
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 21:16 -0700
Re: Python is readable MRAB <python@mrabarnett.plus.com> - 2012-03-23 04:43 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 23:58 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-23 00:20 -0400
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-22 08:33 -0700
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:21 +1100
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-22 15:33 -0400
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:48 +1100
Re: Python is readable Chris Angelico <rosuav@gmail.com> - 2012-03-23 06:49 +1100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 23:34 +0000
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-21 17:54 -0700
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 17:25 +1100
Re: Python is readable Steve Howell <showell30@yahoo.com> - 2012-03-31 09:59 -0700
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-21 00:55 -0400
Re: Python is readable Terry Reedy <tjreedy@udel.edu> - 2012-03-20 16:01 -0400
Re: Python is readable Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-03-20 16:34 -0400
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-21 00:01 +0000
Re: Python is readable Lie Ryan <lie.1296@gmail.com> - 2012-03-31 17:15 +1100
Re: Python is readable Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-03-15 13:51 -0400
Re: Python is readable Arnaud Delobelle <arnodel@gmail.com> - 2012-03-15 20:54 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 02:03 +0000
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 01:53 +0000
Re: Python is readable Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-03-16 02:16 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 13:55 +0100
Re: Python is readable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-16 16:25 +0000
Re: Python is readable Kiuhnm <kiuhnm03.4t.yahoo.it> - 2012-03-16 17:58 +0100
RE: Python is readable "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-03-16 17:01 +0000
Re: Python is readable alister <alister.ware@ntlworld.com> - 2012-03-18 18:19 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-23 06:48 +1100 |
| Message-ID | <mailman.902.1332445685.3037.python-list@python.org> |
| In reply to | #22010 |
On Fri, Mar 23, 2012 at 6:33 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > Pipes do not provide any fine grained control over the concurrent > behavior. If you want to change the order of calls, suddenly you have > to write a bash script (with its own set of issues), etc. Go back to my original post. I posited a means of communication which allows one module to "call" a function in another module, purely by writing to stdout. All four (or however many) modules would run concurrently, and be waiting on stdin most of the time. Of course, the same technique could be used for true concurrency; with such a simple message-passing technique, there's no reason to wait for your response before continuing. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-23 06:49 +1100 |
| Message-ID | <mailman.904.1332445797.3037.python-list@python.org> |
| In reply to | #22010 |
On Fri, Mar 23, 2012 at 6:33 AM, Nathan Rice <nathan.alexander.rice@gmail.com> wrote: > Pipes do not provide any fine grained control over the concurrent > behavior. If you want to change the order of calls... And to clarify: The "order of calls" in what I described is merely the order of initialization. It's like the order of your imports at the top of a Python script, and should have equally no significance. And a module can import other modules by dropping to another chain of pipes in exactly the same way. It'd work! I can't vouch for performance, of course... ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-21 23:34 +0000 |
| Message-ID | <4f6a6584$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21988 |
On Wed, 21 Mar 2012 11:22:01 -0500, Evan Driscoll wrote:
> On 01/-10/-28163 01:59 PM, Steve Howell wrote:
>> Code shouldn't necessarily follow the example of English prose, but it
>> seems that English has had some influence:
>>
>> 1 push(stack, item) # Push on the stack the item
>> 2 push(item, stack) # Push the item on the stack
>> 3 stack.push(item) # On the stack, push the item
>> 4 stack item push # On the stack, take the item and push it
>> 5 item stack push # Take the item and on the stack, push the
>> former.
>> 6 item push stack # Take the item; push it on the stack.
>>
>> The first three ways are the most common ways of arranging the grammar
>> in mainstream programming languages, and they are also the three most
>> natural ways in English (no pronouns required).
>>
>> #1/2 are imperative. #3 is OO.
>
> In my opinion, people who make statements such as "#1/2 are imperative,
> #3 is OO" are missing pretty much the entire point of what OO is.
>
> OO is much more about semantics and the way code is structured. The
> difference between #1/2 (especially #1, of course) and #3 is
> surface-level syntax only.
+1000
I like to talk about "object oriented SYNTAX" (emphasis added) to
distinguish the typical OO dotted syntax obj.attr (or obj->attr) from
other syntax varieties. But this must be understood as mere convention.
One could invent an OO language which used syntax "push(stack, item)" or
even something exotic like "item!push~stack" and it would remain OO, only
with unusual syntax.
Contrariwise, a purely functional language might use declarative or OO-
like syntax. Syntax is orthogonal to the data model, although some data
models naturally suggest some syntaxes over others.
(Syntaxes? Syntaxen? Syntacies?)
The first OO language I ever used was Hypertalk, which used a message-
passing model:
send mouseUp to button OK of card Prefs
and an optional function-call syntax like this:
put the average of field Values into field Average
which I guess makes Hypertalk a message-passing OO language with
imperative syntax.
> About the strongest statement you can make along those lines is that #3
> will allow you to do dynamic dispatch on the type of 'stack' while #1/2
> won't, but even that isn't true of course.
Of course. At runtime, the interpreter is able to dispatch to the correct
method of 'stack' regardless of where the tokens are in the source code.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-21 17:54 -0700 |
| Message-ID | <b5f2aebd-2e90-4465-b6cb-62b2357466fd@qg3g2000pbc.googlegroups.com> |
| In reply to | #22004 |
On Mar 21, 4:34 pm, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > On Wed, 21 Mar 2012 11:22:01 -0500, Evan Driscoll wrote: > > On 01/-10/-28163 01:59 PM, Steve Howell wrote: > >> Code shouldn't necessarily follow the example of English prose, but it > >> seems that English has had some influence: > > >> 1 push(stack, item) # Push on the stack the item > >> 2 push(item, stack) # Push the item on the stack > >> 3 stack.push(item) # On the stack, push the item > >> 4 stack item push # On the stack, take the item and push it > >> 5 item stack push # Take the item and on the stack, push the > >> former. > >> 6 item push stack # Take the item; push it on the stack. > > >> The first three ways are the most common ways of arranging the grammar > >> in mainstream programming languages, and they are also the three most > >> natural ways in English (no pronouns required). > > >> #1/2 are imperative. #3 is OO. > > > In my opinion, people who make statements such as "#1/2 are imperative, > > #3 is OO" are missing pretty much the entire point of what OO is. > > > OO is much more about semantics and the way code is structured. The > > difference between #1/2 (especially #1, of course) and #3 is > > surface-level syntax only. > > +1000 > > I like to talk about "object oriented SYNTAX" (emphasis added) to > distinguish the typical OO dotted syntax obj.attr (or obj->attr) from > other syntax varieties. But this must be understood as mere convention. > One could invent an OO language which used syntax "push(stack, item)" or > even something exotic like "item!push~stack" and it would remain OO, only > with unusual syntax. > Sorry if I caused confusion here. When I labelled certain syntaxes as "imperative" and certain syntaxes as "object-oriented," I never meant to imply anything about the semantic layer. (I think Evan misread my post a bit, and then went a little overboard with his comment that people like me "are missing the entire point of OO.") Clearly, I get the fact that there can be multiple valid syntaxes to express the same underlying operation, as evidenced by my presenting six permutations of stack/push/item. The discussion that I thought would be interesting is this--given six seemingly arbitrary ways of expressing the same idea, how do you decide? My hypothesis is that we all have prior conditioning such that the arrangement of words actually *does* matter. And the conditioning comes from multiple realms--we speak natural languages, we have familiarity with arithmetic notation, and we have traditions from programming itself. The place where token arrangement resonates best with me is arithmetic. I can deal with all of the expressions on a semantic level: 5 + 3 5 3 + + 5 3 On a purely theoretical level, the choice of syntax doesn't really matter (it's just a convention), but the convention is so strong, it matters on a readability level. Even though I can grok prefix/ postfix, I feel uncomfortable in programming languages that don't have "infix" sugar. Imagine if Python didn't support infix sugar. No semantic change, right? But it would still matter for some...
[toc] | [prev] | [next] | [standalone]
| From | Lie Ryan <lie.1296@gmail.com> |
|---|---|
| Date | 2012-03-31 17:25 +1100 |
| Message-ID | <mailman.1171.1333175170.3037.python-list@python.org> |
| In reply to | #21966 |
On 03/21/2012 01:44 PM, Steve Howell wrote: > Also, don't they call those thingies "object" for a reason? ;) A subject is (almost?) always a noun, and so a subject is also an object.
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-31 09:59 -0700 |
| Message-ID | <2419e9d9-b4c9-44ad-a280-9d05a357602b@ms3g2000pbb.googlegroups.com> |
| In reply to | #22410 |
On Mar 30, 11:25 pm, Lie Ryan <lie.1...@gmail.com> wrote: > On 03/21/2012 01:44 PM, Steve Howell wrote: > > > Also, don't they call those thingies "object" for a reason? ;) > > A subject is (almost?) always a noun, and so a subject is also an object. It's true that words that can act as a subject can also act like objects in other sentences. That doesn't really answer my question, though. Why do we call programming objects "objects" instead of calling them "subjects" or "nouns"?
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-21 00:55 -0400 |
| Message-ID | <mailman.852.1332305755.3037.python-list@python.org> |
| In reply to | #21963 |
>> One example is performing a series of transformations on a collection of >> data, with the intent of finding an element of that collection that >> satisfies a particular criterion. If you separate out the individual >> transformations, you need to understand generators or you will waste >> space and perform many unnecessary calculations. If you only ever do a >> single transformation with a clear conceptual meaning, you could create >> a "master transformation function," but what if you have a large number >> of potential permutations of that function? > > I'm sorry, that is far too abstract for me. Do you have a *concrete* > example, even an trivial one? How about a hypothetical log analyzer that parses a log file that is aggregated from multiple event sources with disparate record structures. You will need to perform a series of transformations on the data to convert record elements from text to specific formats, and your function for identifying "alarm" records is also dependent on record structure (and possibly system state, imagining an intrusion detection system). Of course you could go through a lot of trouble to dispatch and detect alarms over 6-7 statements, however given the description "for each log record you receive, convert text elements to native data types based on the value of the first three fields of the record, then trigger an alert if that record meets defined requirements" and assuming you have maps from record values to conversion functions for record elements, and a map from record types to alert criteria functions for record types already constructed, it seems like a one liner to me. >> What if you are composing >> three or four functions, each of which is conditional on the data? If >> you extract things from a statement and assign them somewhat arbitrary >> names, you've just traded horizontal bloat for vertical bloat (with a >> net increase in volume), while forcing a reader to scan back and forth >> to different statements to understand what is happening. > > First off, vertical bloat is easier to cope with than horizontal bloat, > at least for people used to reading left-to-right rather than vertically. > There are few anti-patterns worse that horizontal scrolling, especially > for text. I agree that if a line goes into horizontal scroll buffer, you have a problem. Of course, I often rail on parenthesized function-taking-arguments expression structure for the fact that it forces you to read inside out and right to left, and I'd prefer not to conflate the two issues here. My assertion is that given an expression structure that reads naturally regardless, horizontal bloat is better than larger vertical bloat, in particular when the vertical bloat does not fall along clean semantic boundaries. > Secondly, the human brain can only deal with a limited number of tokens > at any one time. It's easier to remember large numbers when they are > broken up into chunks: > > 824-791-259-401 versus 824791259401 > > (three tokens, versus twelve) > > Likewise for reading code. Chunking code into multiple lines instead of > one long expression, and temporary variables, make things easier to > understand, not harder. This is true, when the tokens are an abstraction. I read some of the research on chunking, basically it came down to people being able to remember multiple numbers efficiently in an auditory fashion using phonemes. Words versus random letter combinations have the same effect, only with visual images (which is why I think Paul Graham is full of shit with regards to his "shorter is better than descriptive" mantra in old essays). This doesn't really apply if storing the elements in batches doesn't provide a more efficient representation. Of course, if you can get your statements to read like sensible English sentences, there is definitely a reduction in cognitive load. > And thirdly, you're not "forcing" the reader to scan back and forth -- or > at least if you are, then you've chosen your functions badly. Functions > should have descriptive names and should perform a meaningful task, not > just an arbitrary collection of code. This is why I quoted Einstein. I support breaking compound logical statements down to simple statements, then combining those simple statements. The problem arises when your compound statement still looks like "A B C D E F G H I J K L M N", and portions of that compound statement don't have a lot of meaning outside the larger statement. You could say X = A B C D E, Y = F G H I J, Z = K L M N, then say X Y Z, but now you've created bloat and forced the reader to backtrack. > > When you read: > > x = range(3, len(sequence), 5) > > you're not forced to scan back and forth between that line and the code > for range and len to understand it, because range and len are good > abstractions that make sensible functions. > > There is a lot of badly written code in existence. Don't blame poor > execution of design principles on the design principle itself. I like to be fair and even handed, and I recognize that tool and language creators don't control users. At the same time, it is a fundamental truth that people are much more inclined to laziness and ignorance than their complements. Any exceptional design will recognize this and make doing the right thing the intuitive, expedient choice. From this perspective I feel morally obligated to lay some blame at the feet of language or tool creator when a person misuses their creation in a way easily predicted given his or her nature. > [...] >> Also, because of Sphinx, it is very common in the Python community weave >> documents and code together in a way that is convenient for authors but >> irritating for readers. > > I don't know about "very common". I suspect, given the general paucity of > documentation in the average software package, it is more like "very > rare, but memorable when it does happen". Well, as a textbook example, the Pocoo projects tend to this. FormAlchemy is another offender. This is just off the top of my head. >> I personally would prefer not to have to scroll >> past 100 lines of a tutorial with examples, tests and what not in order >> to go from one function to another. > > Agreed. Docstrings should use a minimal number of examples and tests. > Tutorials and extensive tests should be extracted into external documents. I don't even mind having tutorials and doctests in the same file, I just don't like them to be interleaved. I really like module level docstrings, and class docstrings are sometimes useful; it is function docstrings that I usually find irritating.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-03-20 16:01 -0400 |
| Message-ID | <mailman.839.1332273705.3037.python-list@python.org> |
| In reply to | #21865 |
On 3/20/2012 3:28 PM, Nathan Rice wrote: >>> This is one of my gripes with the dogmatic application of the "break it >>> into multiple statements" mantra of Python. >> >> I must admit I don't recognise that one, unless you're talking about "not >> everything needs to be a one liner". >> ... >> Perhaps you could give some examples (actual or contrived) of stuff where >> "breaking it into multiple statements" is a bad thing? > > One example is performing a series of transformations on a collection > of data, with the intent of finding an element of that collection that > satisfies a particular criterion. If you separate out the individual > transformations, you need to understand generators or you will waste > space and perform many unnecessary calculations. If you only ever do > a single transformation with a clear conceptual meaning, you could > create a "master transformation function," but what if you have a > large number of potential permutations of that function? What if you > are composing three or four functions, each of which is conditional on > the data? If you extract things from a statement and assign them > somewhat arbitrary names, you've just traded horizontal bloat for > vertical bloat (with a net increase in volume), while forcing a reader > to scan back and forth to different statements to understand what is > happening. > > To steal a line from Einstein, "Make things as simple as possible, but > not simpler" > >>> I agree, docstrings/code comments are a pretty obvious indication that >>> code (as it exists currently) fails as a human communication medium. >> >> >> The fact that scientific journal articles start with a documentation string >> called an abstract does not indicate that scientific English fails as a >> human communication medium. Function docstrings say what the function does >> and how to use it without reading the code. They can be pulled out and >> displayed elsewhere. They also guide the reading of the code. Abstracts >> serve the same functions. > > A paper, with topic introduction, methods exposition, data/results > description and discussion is a poor analog to a function. I would > compare the abstract of a scientific paper to the overview section of > a program's documentation. The great majority of the docstrings I see > are basically signature rehashes with added type information and > assertions, followed by a single sentence English gloss-over. If the > code were sufficiently intuitive and expressive, that would be > redundant. Of course, there will always be morbidly obese functions > and coders that like to wax philosophical or give history lessons in > comments. Both abstracts and doc strings are designed to be and are read independently of the stuff they summarize. Perhaps you do not use help(obj) as often as some other people do. > Also, because of Sphinx, it is very common in the Python community > weave documents and code together in a way that is convenient for > authors but irritating for readers. I personally would prefer not to > have to scroll past 100 lines of a tutorial with examples, tests and > what not in order to go from one function to another. If I understand you, some devs agree. Hence the increasing use of How-to docs with tutorial and example material for a module separate from the reference entries in its section of the Library Reference. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-20 16:34 -0400 |
| Message-ID | <mailman.842.1332275665.3037.python-list@python.org> |
| In reply to | #21865 |
>>> The fact that scientific journal articles start with a documentation >>> string >>> called an abstract does not indicate that scientific English fails as a >>> human communication medium. Function docstrings say what the function >>> does >>> and how to use it without reading the code. They can be pulled out and >>> displayed elsewhere. They also guide the reading of the code. Abstracts >>> serve the same functions. >> >> >> A paper, with topic introduction, methods exposition, data/results >> description and discussion is a poor analog to a function. I would >> compare the abstract of a scientific paper to the overview section of >> a program's documentation. The great majority of the docstrings I see >> are basically signature rehashes with added type information and >> assertions, followed by a single sentence English gloss-over. If the >> code were sufficiently intuitive and expressive, that would be >> redundant. Of course, there will always be morbidly obese functions >> and coders that like to wax philosophical or give history lessons in >> comments. > > > Both abstracts and doc strings are designed to be and are read independently > of the stuff they summarize. Perhaps you do not use help(obj) as often as > some other people do. I find help() to be mostly useless because of the clutter induced by double under methods. I use IPython, and I typically will either use tab name completion with the "?" feature or %edit <obj> if I really need to dig around. I teach Python to groups from time to time as part of my job, and I usually only mention help() as something of an afterthought, since typically people react to the output like a deer in headlights. Some sort of semantic function and class search from the interpreter would probably win a lot of fans, but I don't know that it is possible without a standard annotation format and the addition of a namespace cache to pyc files.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-21 00:01 +0000 |
| Message-ID | <4f691a55$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21949 |
On Tue, 20 Mar 2012 16:34:21 -0400, Nathan Rice wrote: > I find help() to be mostly useless because of the clutter induced by > double under methods. I feel your pain, but perhaps I've just learned how to skim the output without being bogged down in reading every line, or perhaps because I mostly call it on methods rather than on the class itself, I find help() is absolutely invaluable and would be lost without it. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Lie Ryan <lie.1296@gmail.com> |
|---|---|
| Date | 2012-03-31 17:15 +1100 |
| Message-ID | <mailman.1169.1333174571.3037.python-list@python.org> |
| In reply to | #21865 |
On 03/21/2012 03:55 AM, Nathan Rice wrote: > In mathematics, when you perform global optimization you must be > willing to make moves in the solution space that may result in a > temporary reduction of your optimality condition. If you just perform > naive gradient decent, only looking to the change that will induce the > greatest immediate improvement in optimality, you will usually end up > orbiting around a solution which is not globally optimal. I mention > this because any readability or usability information gained using > trained programmers is simultaneously measuring the readability or > usability and its conformance to the programmer's cognitive model of > programming. The result is local optimization around the > current-paradigm minimum. This is why we have so many nearly > identical curly brace C-like languages. I think you've just described that greedy algorithm can't always find the globally optimal solution.
[toc] | [prev] | [next] | [standalone]
| From | Devin Jeanpierre <jeanpierreda@gmail.com> |
|---|---|
| Date | 2012-03-15 13:51 -0400 |
| Message-ID | <mailman.692.1331833908.3037.python-list@python.org> |
| In reply to | #21634 |
On Wed, Mar 14, 2012 at 8:27 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Thu, Mar 15, 2012 at 10:54 AM, Arnaud Delobelle <arnodel@gmail.com> wrote: >> I don't know this book and there may be a pedagogical reason for the >> implementation you quote, but pairwise_sum is probably better >> implemented in Python 3.X as: >> >> def pairwise_sum(list1, list2): >> return [x1 + x2 for x1, x2 in zip(list1, list2)] > > Okay, here's something for debate. > > Should the readability of a language be gauged on the basis of its > standard library, or should you be comparing actual code? "Actual code" often uses the standard library. > For instance, a quine in C can be fairly complex and messy, and it can > be unobvious what it's doing - but in HQ9+ it's easy. Is it fair to > compare on that basis, or should you actually implement the same / > equivalent code in each before judging? It's fair. But it's also fair to note that the comparison is silly, because the easiness of writing quines doesn't correspond with the easiness of doing productive things. -- Devin
[toc] | [prev] | [next] | [standalone]
| From | Arnaud Delobelle <arnodel@gmail.com> |
|---|---|
| Date | 2012-03-15 20:54 +0000 |
| Message-ID | <mailman.703.1331844872.3037.python-list@python.org> |
| In reply to | #21634 |
On 15 March 2012 00:27, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, Mar 15, 2012 at 10:54 AM, Arnaud Delobelle <arnodel@gmail.com> wrote:
>> I don't know this book and there may be a pedagogical reason for the
>> implementation you quote, but pairwise_sum is probably better
>> implemented in Python 3.X as:
>>
>> def pairwise_sum(list1, list2):
>> return [x1 + x2 for x1, x2 in zip(list1, list2)]
>
> Okay, here's something for debate.
>
> Should the readability of a language be gauged on the basis of its
> standard library, or should you be comparing actual code?
But here's the code posted by the OP:
--- Python ---
def pairwise_sum(list1, list2):
result = []
for i in range(len(list1)):
result.append(list1[i] + list2[i])
return result
--- ---
The code I posted uses one builtin function (zip), the code posted by
the OP uses two (range and len). Neither uses the standard library.
--
Arnaud
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-16 02:03 +0000 |
| Message-ID | <4f629f8e$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21713 |
On Thu, 15 Mar 2012 20:54:30 +0000, Arnaud Delobelle wrote:
> On 15 March 2012 00:27, Chris Angelico <rosuav@gmail.com> wrote:
>> On Thu, Mar 15, 2012 at 10:54 AM, Arnaud Delobelle <arnodel@gmail.com>
>> wrote:
>>> I don't know this book and there may be a pedagogical reason for the
>>> implementation you quote, but pairwise_sum is probably better
>>> implemented in Python 3.X as:
>>>
>>> def pairwise_sum(list1, list2):
>>> return [x1 + x2 for x1, x2 in zip(list1, list2)]
>>
>> Okay, here's something for debate.
>>
>> Should the readability of a language be gauged on the basis of its
>> standard library, or should you be comparing actual code?
>
> But here's the code posted by the OP:
>
> --- Python ---
> def pairwise_sum(list1, list2):
> result = []
> for i in range(len(list1)):
> result.append(list1[i] + list2[i])
> return result
> --- ---
>
> The code I posted uses one builtin function (zip), the code posted by
> the OP uses two (range and len). Neither uses the standard library.
For beginners, code using range and len is MUCH easier to understand than
code using zip. len is obviously short for length, and range (at least in
the one-argument version) is simple to explain. But zip? To understand
zip, you need to have a good concept of iteration in your head. When
writing for beginners, you can't assume that.
For beginners, the most idiomatic code is not necessarily the simplest
code. I would never start beginners with a list comprehension:
result = [a+b for a,b in zip(list1, list2)]
which is likely to be just incomprehensible jargon. You need to
understand the syntax, which may not be obvious even to people with a
mathematics background. (List comps are copied from Haskell, where they
derive their syntax from mathematicians' set notation.) You need to
understand zip, which requires having a good mental model of element-wise
iteration. Although it is longer and less idiomatic, the Python1.5-ish
result = []
for i in range(len(list1)):
result.append(list1[i] + list2[i])
is likely to be simpler to understand.
The downside is that experienced programmers may roll their eyes at how
you are dumbing down the code, or worse, accusing you of deliberately
misrepresenting the language.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-16 01:53 +0000 |
| Message-ID | <4f629d27$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21634 |
On Thu, 15 Mar 2012 00:34:47 +0100, Kiuhnm wrote:
> I've just started to read
> The Quick Python Book (2nd ed.)
Is this the one?
http://manning.com/ceder/
> The author claims that Python code is more readable than Perl code and
> provides this example:
>
> --- Perl ---
> sub pairwise_sum {
> my($arg1, $arg2) = @_;
> my(@result) = ();
> @list1 = @$arg1;
> @list2 = @$arg2;
I don't understand the reason for $arg1 and $arg2. Is there some reason
why the code couldn't do this instead?
my(@list1, @list2) = @_;
> for($i=0; $i < length(@list1); $i++) {
> push(@result, $list1[$i] + $list2[$i]);
> }
> return(\@result);
> }
>
> --- Python ---
> def pairwise_sum(list1, list2):
> result = []
> for i in range(len(list1)):
> result.append(list1[i] + list2[i])
> return result
> --- ---
>
> It's quite clear that he knows little about Perl.
On the contrary -- it is quite clear that you are missing the point of
the comparison, which is not to compare the most idiomatic Perl with the
most idiomatic Python, but to make a direct comparison of syntax for the
purpose of teaching beginners.
The problem with idiomatic comparisons is that they often don't give you
a feel for the overall language syntax. Instead they end up comparing
built-ins. For example, here is how I would write the above pairwise
addition using idiomatic RPL, the Forth-like programming language used on
some Hewlett-Packard scientific calculators:
ADD
That's it. One word. Would you conclude from this that RPL is easier to
read and write than Python? I can tell you that it is not, and I *like*
stack-based languages that use reverse Polish Notation.
> Here's what I would've written:
>
> sub pairwise_sum {
> my ($list1, $list2) = @_;
> my @result;
> push @result, $list1->[$_] + $list2->[$_] for (0..@$list1-1);
> \@result;
> }
>
> Having said that, the Python code is still more readable, so there's no
> need to misrepresent Perl that way.
Speaking as somebody who doesn't know Perl, I think that your version
would do a great disservice to Perl. Your version is shorter, but
conciseness is often in opposition to readability. Without the author's
version above, and the function name, I would have literally NO IDEA what
your version does. It is virtually pure line-noise. I know enough Perl to
guess that @result might be an array, and so guess that push pushes a
value onto the array, but the rest might as well be written in Martian.
Or APL.
The author's version above, which you denigrate, is *much* more
understandable than your more idiomatic Perl, especially since I can
compare it feature to feature with the Python code.
Far from misrepresenting Perl, he has gone out of his way to show Perl in
the best possible light. Idiomatic Perl code, written by experts, is even
more incomprehensible and unreadable to non-Perl hackers than his example.
> Now I'm wondering whether the author will show me "good" or "bad" Python
> code throughout the book. Should I keep reading?
From what you have show, and the sample chapters on the link above, I am
impressed. The author is aiming to teach basic concepts and impart
*understanding* rather than just force-feed the reader idioms which would
be incomprehensible to them. Vern Cedar (the author) is an actual
professional teacher, and from the samples I have seen, he knows what he
is doing.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2012-03-16 02:16 +0000 |
| Message-ID | <mailman.713.1331864214.3037.python-list@python.org> |
| In reply to | #21728 |
On 16/03/2012 01:53, Steven D'Aprano wrote:
> On Thu, 15 Mar 2012 00:34:47 +0100, Kiuhnm wrote:
>
>> I've just started to read
>> The Quick Python Book (2nd ed.)
>
> Is this the one?
>
> http://manning.com/ceder/
>
>
>> The author claims that Python code is more readable than Perl code and
>> provides this example:
>>
>> --- Perl ---
>> sub pairwise_sum {
>> my($arg1, $arg2) = @_;
>> my(@result) = ();
>> @list1 = @$arg1;
>> @list2 = @$arg2;
>
> I don't understand the reason for $arg1 and $arg2. Is there some reason
> why the code couldn't do this instead?
>
> my(@list1, @list2) = @_;
>
>
>> for($i=0; $i< length(@list1); $i++) {
>> push(@result, $list1[$i] + $list2[$i]);
>> }
>> return(\@result);
>> }
>>
>> --- Python ---
>> def pairwise_sum(list1, list2):
>> result = []
>> for i in range(len(list1)):
>> result.append(list1[i] + list2[i])
>> return result
>> --- ---
>>
>> It's quite clear that he knows little about Perl.
>
> On the contrary -- it is quite clear that you are missing the point of
> the comparison, which is not to compare the most idiomatic Perl with the
> most idiomatic Python, but to make a direct comparison of syntax for the
> purpose of teaching beginners.
>
> The problem with idiomatic comparisons is that they often don't give you
> a feel for the overall language syntax. Instead they end up comparing
> built-ins. For example, here is how I would write the above pairwise
> addition using idiomatic RPL, the Forth-like programming language used on
> some Hewlett-Packard scientific calculators:
>
> ADD
>
> That's it. One word. Would you conclude from this that RPL is easier to
> read and write than Python? I can tell you that it is not, and I *like*
> stack-based languages that use reverse Polish Notation.
>
>
>> Here's what I would've written:
>>
>> sub pairwise_sum {
>> my ($list1, $list2) = @_;
>> my @result;
>> push @result, $list1->[$_] + $list2->[$_] for (0..@$list1-1);
>> \@result;
>> }
>>
>> Having said that, the Python code is still more readable, so there's no
>> need to misrepresent Perl that way.
>
> Speaking as somebody who doesn't know Perl, I think that your version
> would do a great disservice to Perl. Your version is shorter, but
> conciseness is often in opposition to readability. Without the author's
> version above, and the function name, I would have literally NO IDEA what
> your version does. It is virtually pure line-noise. I know enough Perl to
> guess that @result might be an array, and so guess that push pushes a
> value onto the array, but the rest might as well be written in Martian.
> Or APL.
>
> The author's version above, which you denigrate, is *much* more
> understandable than your more idiomatic Perl, especially since I can
> compare it feature to feature with the Python code.
>
> Far from misrepresenting Perl, he has gone out of his way to show Perl in
> the best possible light. Idiomatic Perl code, written by experts, is even
> more incomprehensible and unreadable to non-Perl hackers than his example.
>
>
>> Now I'm wondering whether the author will show me "good" or "bad" Python
>> code throughout the book. Should I keep reading?
>
>> From what you have show, and the sample chapters on the link above, I am
> impressed. The author is aiming to teach basic concepts and impart
> *understanding* rather than just force-feed the reader idioms which would
> be incomprehensible to them. Vern Cedar (the author) is an actual
> professional teacher, and from the samples I have seen, he knows what he
> is doing.
>
>
Well put Sir. And (seriously) when making your comments you show the
killer instincts of a great bowler in an Ashes Test Match, now could
there be anything more important in life or showing greater esteem than
that?
--
Cheers.
Mark Lawrence.
[toc] | [prev] | [next] | [standalone]
| From | Kiuhnm <kiuhnm03.4t.yahoo.it> |
|---|---|
| Date | 2012-03-16 13:55 +0100 |
| Message-ID | <4f63382b$0$1375$4fafbaef@reader1.news.tin.it> |
| In reply to | #21728 |
On 3/16/2012 2:53, Steven D'Aprano wrote:
> On Thu, 15 Mar 2012 00:34:47 +0100, Kiuhnm wrote:
>
>> I've just started to read
>> The Quick Python Book (2nd ed.)
>
> Is this the one?
>
> http://manning.com/ceder/
>
>
>> The author claims that Python code is more readable than Perl code and
>> provides this example:
>>
>> --- Perl ---
>> sub pairwise_sum {
>> my($arg1, $arg2) = @_;
>> my(@result) = ();
>> @list1 = @$arg1;
>> @list2 = @$arg2;
>
> I don't understand the reason for $arg1 and $arg2. Is there some reason
> why the code couldn't do this instead?
>
> my(@list1, @list2) = @_;
@_ contains references to arrays. You can't pass two arrays to a function.
Kiuhnm
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-16 16:25 +0000 |
| Message-ID | <4f63697c$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21747 |
On Fri, 16 Mar 2012 13:55:06 +0100, Kiuhnm wrote: >> I don't understand the reason for $arg1 and $arg2. Is there some reason >> why the code couldn't do this instead? >> >> my(@list1, @list2) = @_; > > @_ contains references to arrays. You can't pass two arrays to a > function. Why ever not? That seems like basic functionality to me. I can't imagine any modern language that lacks such a simple feature. Even Pascal allows you to pass arrays as arguments to functions. Is there some design principle that I'm missing that explains why Perl lacks this feature? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Kiuhnm <kiuhnm03.4t.yahoo.it> |
|---|---|
| Date | 2012-03-16 17:58 +0100 |
| Message-ID | <4f63713d$0$1374$4fafbaef@reader1.news.tin.it> |
| In reply to | #21757 |
On 3/16/2012 17:25, Steven D'Aprano wrote:
> On Fri, 16 Mar 2012 13:55:06 +0100, Kiuhnm wrote:
>
>
>>> I don't understand the reason for $arg1 and $arg2. Is there some reason
>>> why the code couldn't do this instead?
>>>
>>> my(@list1, @list2) = @_;
>>
>> @_ contains references to arrays. You can't pass two arrays to a
>> function.
>
>
> Why ever not? That seems like basic functionality to me. I can't imagine
> any modern language that lacks such a simple feature. Even Pascal allows
> you to pass arrays as arguments to functions.
>
> Is there some design principle that I'm missing that explains why Perl
> lacks this feature?
Perl uses references only when explicitly told so.
For instance,
my @a = (1,2,3);
my @b = @a;
creates two distinct arrays and you can modify @b without touching @a at
all.
Another odd thing is that Perl "flattens" lists or arrays. If you write
my @a = (1,2,3);
my @b = (0,@a,4);
you'll end up with @b = (0,1,2,3,4).
If you want nested data structures, you'll need to use explicit references:
my @b = (0,\@a,4); # '\' = take the ref of
Now you can write
$b[1][0]
but that's short-hand for
$b[1]->[0] # deref. $b[1] and get the first elem
which is short-hand for
${$b[1]}[0]
Square brackets build an array and return a reference to it:
my $ref = [0,1,2];
(Notice that, in Perl, '$' means one ($ref is one reference), while '@'
means many.)
Now you can write
my @a = (1,[2,3,4],5)
because you're putting a reference into $a[1]!
So, let's go back to this code:
sub pairwise_sum {
my($arg1, $arg2) = @_;
my(@result) = ();
@list1 = @$arg1;
@list2 = @$arg2;
for($i=0; $i < length(@list1); $i++) {
push(@result, $list1[$i] + $list2[$i]);
}
return(\@result);
}
Here @list1 and @list2 are copies. No careful Perl programmer would do
such extra copies. And no Perl programmer would use a C-style for loop.
Kiuhnm
[toc] | [prev] | [next] | [standalone]
| From | "Prasad, Ramit" <ramit.prasad@jpmorgan.com> |
|---|---|
| Date | 2012-03-16 17:01 +0000 |
| Message-ID | <mailman.728.1331917304.3037.python-list@python.org> |
| In reply to | #21757 |
> >> I don't understand the reason for $arg1 and $arg2. Is there some reason > >> why the code couldn't do this instead? > >> > >> my(@list1, @list2) = @_; > > > > @_ contains references to arrays. You can't pass two arrays to a > > function. > > > Why ever not? That seems like basic functionality to me. I can't imagine > any modern language that lacks such a simple feature. Even Pascal allows > you to pass arrays as arguments to functions. > > Is there some design principle that I'm missing that explains why Perl > lacks this feature? My understanding is that it assigns each scalar argument until it finds a list to assign and then it assigns everything remaining to the list. my @arr = ( 'test', 'blah', '1234', 'boop', 'foo', 'bar' ); my @arr2 = ( 'adsf', 'qwerty' ); print "@arr\n"; my @arr3 = (@arr, @arr2); print "arr3:@arr3\n"; my ($arg1, $arg2, @arg3) = @arr3; print "arg3:@arg3\n"; bash-3.2$ perl temp.pl testblah1234boopfoobar arr3:test blah 1234 boop foo bar adsf qwerty arg3:1234 boop foo bar adsf qwerty I assume this is because it combines both elements of the list into one giant list and then if you try and assign two lists it does not know where to split it. Now if you pass a reference to the two arrays instead of the values it should work as expected, but now you are dealing with pointers / references. bash-3.2$ cat temp.pl my @arr = ( 'test', 'blah', '1234', 'boop', 'foo', 'bar' ); my @arr2 = ( 'adsf', 'qwerty' ); print "@arr\n"; my @arr3 = (\@arr, \@arr2); print "arr3:@arr3\n"; my ($arg1, $arg2, @arg3) = @arr3; print "arg1:@$arg1\narg2:@$arg2\narg3:@arg3\n"; bash-3.2$ perl temp.pl test blah 1234 boop foo bar arr3:ARRAY(0xb2f0f90) ARRAY(0xb2f1020) arg1:test blah 1234 boop foo bar arg2:adsf qwerty arg3: Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 216 - 5423 -- This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web