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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> |
|---|---|
| Date | 2012-03-15 16:41 +0100 |
| Message-ID | <jjt2jl$76c$1@r03.glglgl.gl> |
| In reply to | #21656 |
Am 15.03.2012 12:48 schrieb Kiuhnm:
> On 3/15/2012 12:14, Thomas Rachel wrote:
>> Am 15.03.2012 11:44 schrieb Kiuhnm:
>>
>>> Let's try that.
>>> Show me an example of "list comprehensions" and "with" (whatever they
>>> are).
>>
>> with open("filename", "w") as f:
>> f.write(stuff)
>
> Here f is created before executing the block and destroyed right after
> leaving the block. f's destructor will probably close the file handle.
No, that is the point here: with calls __enter__ on entry and __exit__
on, well, exit.
In the case of files, __enter__ doesn't probably do anything special,
but returns the object again in order to be assigned to f. In __exit__,
the file is closed.
with open("/tmp/filename", "w") as f:
print f
print f
<open file '/tmp/filename', mode 'w' at 0xb74e6d30>
<closed file '/tmp/filename', mode 'w' at 0xb74e6d30>
So after the with clause, f is actually closed, but still present as object.
>> with lock:
>> do_something_exclusively()
> It's clear what it does, but I don't know if that's special syntax.
If you call "with" special syntax, it is.
> Maybe objects can have two special methods that are called respect. on
> entering and leaving the with-block.
Exactly, see above.
Here, on entry __enter__ is called which acquires the lock.
__exit__ releases it again.
> Or, more likely, lock creates an object which keeps the lock "acquired".
> The lock is released when we leave the block.
> So we could inspect the lock with
> with lock as l:
> inspect l...
> do_some.....
Or just inspect l - I don't know if a lock's __enter__ methos returns it
again for assignment with "as"...
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Duncan Booth <duncan.booth@invalid.invalid> |
|---|---|
| Date | 2012-03-16 09:30 +0000 |
| Message-ID | <XnsA01860AACB8ACduncanbooth@127.0.0.1> |
| In reply to | #21690 |
Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915 @spamschutz.glglgl.de> wrote: >> Or, more likely, lock creates an object which keeps the lock "acquired". >> The lock is released when we leave the block. >> So we could inspect the lock with >> with lock as l: >> inspect l... >> do_some..... > > Or just inspect l - I don't know if a lock's __enter__ methos returns it > again for assignment with "as"... > No, if you do `with lock as l:` then l will get the boolean True. The lock's __enter__ method is the same as lock.acquire(). That method takes an optional argument which can be used to conditionally acquire the lock and return a boolean indicating success or failure. When used inside a `with` statement you can't pass in the optional argument so it acquires it unconditionally but still returns the success status which is either True or it never returns. -- Duncan Booth http://kupuguy.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | John Ladasky <ladasky@my-deja.com> |
|---|---|
| Date | 2012-03-18 14:30 -0700 |
| Message-ID | <cafdcc3e-96e4-4fb5-8885-a3f8115bc903@x10g2000pbi.googlegroups.com> |
| In reply to | #21646 |
On Mar 14, 11:23 pm, alex23 <wuwe...@gmail.com> wrote: > The idea that Python code has to be obvious to non-programmers is an > incorrect and dangerous one. Incorrect? Probably. Dangerous? You'll have to explain what you mean. What I would say is that, when PROGRAMMERS look at Python code for the first time, they will understand what it does more readily than they would understand other unfamiliar programming languages. That has value.
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-19 09:02 +1100 |
| Message-ID | <mailman.789.1332108130.3037.python-list@python.org> |
| In reply to | #21865 |
On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky@my-deja.com> wrote: > What I would say is that, when PROGRAMMERS look at Python code for the > first time, they will understand what it does more readily than they > would understand other unfamiliar programming languages. That has > value. This is something that's never truly defined. Everyone talks of how this language or that language is readable, but if you mean that you can look at a line of code and know what *that line* does, then Python suffers badly and assembly language wins out; but if you mean that you should be able to glance over an entire function and comprehend its algorithm, then I have yet to see any language in which it's not plainly easy to write bad code. Even with good code, anything more than trivial can't be eyeballed in that way - if you could, what would docstrings be for? Really, the metric MUST be Python programmers. Intuitiveness is of value, but readability among experienced programmers is far more useful. If I write a whole lot of code today, and next year I'm dead and someone else has replaced me, I frankly don't mind if he has to learn the language before he can grok my code. I _do_ mind if, even after he's learned the language, he can't figure out what my code's doing; and that's where Python's placed itself at about the right level - not so high that it's all in airy-fairy conceptual work, but not so low that it gets bogged down. There's a handful of other languages that are similarly placed, and they're the languages that I would call "readable". Here's an analogy: One statement (aka line of code, etc) corresponds to one sentence in English. Massive one-liners are like some of the sentences in Paul's epistles; assembly language is like "The cat sat on the mat". Both are valid; both are hard to read. There, have fun tearing thaat to shreds :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-19 01:23 +0000 |
| Message-ID | <4f668a9d$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21867 |
On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote: > On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky@my-deja.com> > wrote: >> What I would say is that, when PROGRAMMERS look at Python code for the >> first time, they will understand what it does more readily than they >> would understand other unfamiliar programming languages. That has >> value. > > This is something that's never truly defined. I'm sorry, I don't understand what part of John's sentence you mean by "this". "Programmers"? "Value"? "Understand"? > Everyone talks of how this > language or that language is readable, but if you mean that you can look > at a line of code and know what *that line* does then Python suffers > badly and assembly language wins out; This is at least the second time you've alleged that assembly language is more readable than Python. I think you're a raving nutter, no offence Chris :-) Assignment (name binding) is close to the absolute simplest thing you can do in a programming language. In Python, the syntax is intuitive to anyone who has gone through high school, or possibly even primary school, and been introduced to the equals sign. x = 1234 y = "Hello" In assembly language, not so much. I wouldn't even have begun to guess how to assign variables in assembly, or even whether such a thing is possible, but a few minutes of googling gave me this: # 8086 assembly x dw 1234 y db 'Hello', 0 # MIPS assembly x: .word 1234 y: .asciiz "Hello" I don't know about anyone else, but I wouldn't have guessed that the way to get x=1234 was with "x dw 1234". What's more, with Python, one example hints on how to do other examples. Having seen x=1234, most people would guess that x=1.234 would also work. I'm pretty sure that "x dw 1.234" will do something surprising, although I don't know what, but it certainly won't be to assign the float 1.234 to a variable x. So there we have another measure of "readability" -- discoverability. Having seen one example, how easy is it to predict slightly modified examples? In assembly's case, not very predictable. What's the difference between these two lines? a db 127 b db 327 For that matter, what will the second line actually do? The thing is, these aren't "advanced features" of assembly language. It's not like trying to understand metaclasses in Python. These are the basic foundations. You can read vast swathes of simple Python code without needing to learn the gory details of Python's data model (name binding of objects, everything is an object), but you can't even *begin* reading assembly language without a good grasp of the data model and jargon. Assembly has a very steep learning curve. Python has a shallow curve. Here's another indication of readability. There have been occasional suggestions on Wikipedia that they standardize on Python as "executable pseudo-code" for code samples. Now replace "Python" with assembly language. Unless you're Donald Knuth, the idea is ridiculous. Another factor related to readability is the primitiveness of the toolset. Assembly has a very low-level, primitive toolset. How would you write this in assembly? print(sorted(somelist)) If all you have is a hammer, the instructions you get are easy to understand because there's not much you can do with it. How complicated can "hit the nail with the hammer" get? But the right measure is not the simplicity of the tasks you *can* do, but the comprehensibility of the tasks you *want* to do. "How do I build a tree house using nothing but a hammer?" I'm sure that, given sufficient ingenuity, you could build a tree house with nothing but a hammer, lumber and nails, but the detailed instructions would be complicated and difficult. How much simpler it becomes with a more powerful set of tools. Assembly is simple, like a hammer. (Well, perhaps not *quite* as simple as a hammer.) > but if you mean that you should be > able to glance over an entire function and comprehend its algorithm, > then I have yet to see any language in which it's not plainly easy to > write bad code. Even with good code, anything more than trivial can't be > eyeballed in that way - if you could, what would docstrings be for? The measure of the readability of a language should not be obfuscated or badly written code, but good, idiomatic code written by an experienced practitioner in the art. Note that there is a deliberate asymmetry there: when judging "readability" (comprehensibility), we take idiomatic code written by somebody who knows the language well, and give it to a novice to interpret it. On this measure, Python has actually become *less* readable in recent years, with the addition of powerful new idioms such as generators, list comprehensions, with statement, etc. They are very expressive, and Python is much better off with them, but they are less readable in the sense I am talking about: readable to somebody who is not an expert in the language. For this reason, when dealing with beginners, or writing code intended as "executable pseudo-code", I try to stick with features that worked in Python 1.5 where possible. E.g. for-loops rather than list comprehensions. > Really, the metric MUST be Python programmers. Intuitiveness is of > value, but readability among experienced programmers is far more useful. But by that metric, Brainf*** is readable, since an experienced expert in the art of writing BF code will be able to recognise BF idioms and interpret them correctly. No, I'm sorry, I disagree that the standard of readability should be the experienced programmer. By that standard, "readability" is a no-op. All languages are, more or less, equally readable, to those who can read them well. I don't think it is useful to judge the readability of Forth on the ability of Charles Moore to read it. How does that help me decide whether to use Forth for my next project? > If I write a whole lot of code today, and next year I'm dead and someone > else has replaced me, I frankly don't mind if he has to learn the > language before he can grok my code. I _do_ mind if, even after he's > learned the language, he can't figure out what my code's doing; Then he hasn't learned the language *sufficiently well*. Either that, or your code is obfuscated, unidiomatic crap. Perhaps you're trying to write BF in Python :) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-19 15:33 +1100 |
| Message-ID | <mailman.795.1332131633.3037.python-list@python.org> |
| In reply to | #21871 |
On Mon, Mar 19, 2012 at 12:23 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote:
>
>> On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky@my-deja.com>
>> wrote:
>>> What I would say is that, when PROGRAMMERS look at Python code for the
>>> first time, they will understand what it does more readily than they
>>> would understand other unfamiliar programming languages. That has
>>> value.
>>
>> This is something that's never truly defined.
>
> I'm sorry, I don't understand what part of John's sentence you mean by
> "this". "Programmers"? "Value"? "Understand"?
I should have rewritten that into the next paragraph. Anyhow. Further
explanation below.
>> Everyone talks of how this
>> language or that language is readable, but if you mean that you can look
>> at a line of code and know what *that line* does then Python suffers
>> badly and assembly language wins out;
>
> This is at least the second time you've alleged that assembly language is
> more readable than Python. I think you're a raving nutter, no offence
> Chris :-)
None taken; guilty as charged. And unashamedly so. With that dealt
with, though: My calling assembly "readable" is a form of argument by
drawing to logical, but absurd, conclusion - by the given definition
of readability, assembly is readable, ergo the definition sucks.
(That's a term all logicians use, you know. Proper and formal jargon.)
> Assignment (name binding) is close to the absolute simplest thing you can
> do in a programming language. In Python, the syntax is intuitive to
> anyone who has gone through high school, or possibly even primary school,
> and been introduced to the equals sign.
>
> x = 1234
> y = "Hello"
Not quite. In mathematics, "x = 1234" is either a declaration of fact,
or a statement that can be either true or false. In mathematics, "x =
x + 1" is absurd and/or simply false. That's why Pascal has its :=
operator, supposed to be read as "becomes" and not "equals". IMHO this
is simply proof of one of the differences between programming and
mathematics.
> I don't know about anyone else, but I wouldn't have guessed that the way
> to get x=1234 was with "x dw 1234".
Except that it's not quite the same thing. That 8086 Assembly
statement is more like the C statement:
int x=1234;
The nearest equivalent of assignment is:
mov x,1234
although that differs slightly from assembler to assembler (NASM, if I
recall correctly, calls for "mov [x],1234"). You're right, though,
that it's nothing like as clear.
> What's more, with Python, one example hints on how to do other examples.
> Having seen x=1234, most people would guess that x=1.234 would also work.
Yes, which brings up the old favorite arguments about whether
computers work with integers, floats, rationals, Real Numbers, or
Numbers. But, that aside...
> I'm pretty sure that "x dw 1.234" will do something surprising, although
> I don't know what, but it certainly won't be to assign the float 1.234 to
> a variable x.
Perhaps not usefully, but "x dd 1.234" ought to work. You just can't
fit a float into a dw. (NASM does support "half precision", but most
operations want a doubleword for a float.) Assembly language requires
variable sizes to be declared.
Of course, what it *really* does is declare a doubleword-sized patch
of memory, initializes it to the IEEE representation of the nearest
possible float to the real number 1.234, and assigns the label 'x' to
point to the lowest memory address used by that doubleword... but
mostly you don't need to care about that.
> So there we have another measure of "readability" -- discoverability.
> Having seen one example, how easy is it to predict slightly modified
> examples?
>
> In assembly's case, not very predictable. What's the difference between
> these two lines?
>
> a db 127
> b db 327
>
> For that matter, what will the second line actually do?
I'm not 100% sure, but since assembly is much stricter than most HLLs
with data sizes, it's a concern that you don't have with Python's long
ints. But the same thing can come up in a HLL - struct.pack("i") can't
handle a long int, because, like an assembler, it's concerned about
exact byte sizes.
> Assembly has a very steep learning curve. Python has a shallow curve.
Of course. But computer programming generally has a fairly stiff
learning curve; you have to get your head around all sorts of concepts
that simply do not exist anywhere else.
> Here's another indication of readability. There have been occasional
> suggestions on Wikipedia that they standardize on Python as "executable
> pseudo-code" for code samples. Now replace "Python" with assembly
> language. Unless you're Donald Knuth, the idea is ridiculous.
I am not, and it is. But I could make you a set of NASM macros that
allow you to write assembly code that looks like pseudo-code. Does
that make assembly code readable? Maybe. Does it make it worth using
as a HLL? No.
> If all you have is a hammer, the instructions you get are easy to
> understand because there's not much you can do with it. How complicated
> can "hit the nail with the hammer" get? But the right measure is not the
> simplicity of the tasks you *can* do, but the comprehensibility of the
> tasks you *want* to do.
Right, which is why NO language can be described as "readable" or
"easy to work with" unless you define a problem domain. SQL is an
excellent language... as long as you want to query a relational
database.
> The measure of the readability of a language should not be obfuscated or
> badly written code, but good, idiomatic code written by an experienced
> practitioner in the art. Note that there is a deliberate asymmetry there:
> when judging "readability" (comprehensibility), we take idiomatic code
> written by somebody who knows the language well, and give it to a novice
> to interpret it.
Sure. You can write bad code in any language, and that doesn't mean
anything. But still, if you're writing for a novice, you write quite
different code from what you'd write normally. Language tutorials are
written by experts for novices; language tutorials do not look like
the language's own standard library (assuming it has one written in
itself).
>> Really, the metric MUST be Python programmers. Intuitiveness is of
>> value, but readability among experienced programmers is far more useful.
>
> But by that metric, Brainf*** is readable, since an experienced expert in
> the art of writing BF code will be able to recognise BF idioms and
> interpret them correctly.
Not really. The BF code to do one simple high level operation could
easily span several pages. You can't "recognize" those. Now, BF with
macros/subroutines might be more plausible - if you could define a new
opcode that represents some huge slab of BF code and use that - but in
its native form, I don't think anyone could recognize what BF is
doing.
> No, I'm sorry, I disagree that the standard of readability should be the
> experienced programmer. By that standard, "readability" is a no-op. All
> languages are, more or less, equally readable, to those who can read them
> well. I don't think it is useful to judge the readability of Forth on the
> ability of Charles Moore to read it. How does that help me decide whether
> to use Forth for my next project?
>
>> If I write a whole lot of code today, and next year I'm dead and someone
>> else has replaced me, I frankly don't mind if he has to learn the
>> language before he can grok my code. I _do_ mind if, even after he's
>> learned the language, he can't figure out what my code's doing;
>
> Then he hasn't learned the language *sufficiently well*. Either that, or
> your code is obfuscated, unidiomatic crap. Perhaps you're trying to write
> BF in Python :)
And that's where the nub of the question is. How well is sufficiently
well? Clearly you do not require your code to be comprehensible to a
non-programmer, or you would not write code at all. If you don't
demand that the reader learn basic keywords of the language, then it's
equally impossible to expect them to comprehend your code. If you're
writing production code, I see no reason to avoid language features
like Python's list comps, Pike's %{ %} sprintf codes, or C's pointer
arithmetic, just because they can confuse people. Learn the language,
THEN start hacking on the code.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-19 13:37 +0000 |
| Message-ID | <4f673680$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21875 |
On Mon, 19 Mar 2012 15:33:51 +1100, Chris Angelico wrote:
>> This is at least the second time you've alleged that assembly language
>> is more readable than Python. I think you're a raving nutter, no
>> offence Chris :-)
>
> None taken; guilty as charged. And unashamedly so. With that dealt with,
> though: My calling assembly "readable" is a form of argument by drawing
> to logical, but absurd, conclusion - by the given definition of
> readability, assembly is readable, ergo the definition sucks. (That's a
> term all logicians use, you know. Proper and formal jargon.)
Which definition of readability are you using? Because I have given, if
not a formal definition, at least a good explanation of what I consider
to be the usual meaning of "readability" in the context of programming
languages. I haven't seen anyone propose an alternative.
Readability, as I see it, is a misnomer. What people actually mean by
"Ruby is more readable than Forth" (say) is that Ruby is more
comprehensible to some idealised non-expert reader. I also gave a list of
characteristics of this idealised reader -- check the archives.
I don't see how "assembly is readable" is the logical conclusion of my
definition. It certainly is the logical conclusion if you make expert
practitioners in the language as the judge of readability, but that's not
my argument, that's yours.
>> Assignment (name binding) is close to the absolute simplest thing you
>> can do in a programming language. In Python, the syntax is intuitive to
>> anyone who has gone through high school, or possibly even primary
>> school, and been introduced to the equals sign.
>>
>> x = 1234
>> y = "Hello"
>
> Not quite. In mathematics, "x = 1234" is either a declaration of fact,
> or a statement that can be either true or false.
[snip differences between assignment and equality]
Granted there are differences. Nevertheless, even mathematicians have a
form of assignment, using almost the same notation many programming
languages use:
let c = 42
Sometimes the "let" is left out.
The point is not that programming assignment and mathematical equality
are identical, but that most people have been exposed to maths = in
school and so can intuit the meaning of programming = .
Admittedly not always *correctly* :)
[...]
>> Assembly has a very steep learning curve. Python has a shallow curve.
>
> Of course. But computer programming generally has a fairly stiff
> learning curve; you have to get your head around all sorts of concepts
> that simply do not exist anywhere else.
Sure. That brings us to the perennial conflict between power/
expressibility versus readability/comprehensibility. Except for languages
aimed purely as a teaching language for beginners, or perhaps an
application scripting language, readability should not be the *only* aim
in a language. The trick is to add as much power as you need without
losing too much readability.
The more powerful an abstraction or programming construct, the less non-
experts will be able to intuit what it does. Or for that matter, the less
likely they will be able to understand it even after explanations. I
still have no idea what Haskell monads are.
Contrariwise, the simpler and more comprehensible a tool is for non-
experts, the less likely it will be interesting to experts. Either there
will be too much syntactic sugar (e.g. "add 3 to x" instead of x += 3) or
it simply won't do much ("x + 3" is understandable but not very
interesting, and it doesn't help you talk to a database).
Somewhere between those extremes of Forth and Hypertalk is a happy
medium. It is my position that Python is somewhat closer to that peak
than close neighbours like Ruby and Javascript, but I'm willing to accept
that a certain amount of that is mere personal taste.
Of course my personal taste is right and theirs is wrong.
*wink*
>> If all you have is a hammer, the instructions you get are easy to
>> understand because there's not much you can do with it. How complicated
>> can "hit the nail with the hammer" get? But the right measure is not
>> the simplicity of the tasks you *can* do, but the comprehensibility of
>> the tasks you *want* to do.
>
> Right, which is why NO language can be described as "readable" or "easy
> to work with" unless you define a problem domain. SQL is an excellent
> language... as long as you want to query a relational database.
And so long as you stick to simple examples, it is relatively
comprehensible:
SELECT COLUMN2 FROM TABLE WHERE COLUMN1 = 42;
But then you have stuff like this:
SELECT * FROM (
SELECT
RANK() OVER (ORDER BY age ASC) AS ranking,
person_id,
person_name,
age
FROM person
) foo
WHERE ranking <= 10
Try asking your dear ol' granny to explain what that does.
>> The measure of the readability of a language should not be obfuscated
>> or badly written code, but good, idiomatic code written by an
>> experienced practitioner in the art. Note that there is a deliberate
>> asymmetry there: when judging "readability" (comprehensibility), we
>> take idiomatic code written by somebody who knows the language well,
>> and give it to a novice to interpret it.
>
> Sure. You can write bad code in any language, and that doesn't mean
> anything. But still, if you're writing for a novice, you write quite
> different code from what you'd write normally. Language tutorials are
> written by experts for novices; language tutorials do not look like the
> language's own standard library (assuming it has one written in itself).
Absolutely.
One of my pet peeves is the number of people who give answers to
questions *far* over the experience level of the person asking the
question. Like if Joe Noob asked how to read a number from three files
and calculate the sum, and I gave an answer involving spawning a bunch of
threads to read the files.
If your aim is to *teach*, then "that's how I would do it" is not
necessarily a good answer is the person you are trying to teach knows
less than you.
>>> Really, the metric MUST be Python programmers. Intuitiveness is of
>>> value, but readability among experienced programmers is far more
>>> useful.
>>
>> But by that metric, Brainf*** is readable, since an experienced expert
>> in the art of writing BF code will be able to recognise BF idioms and
>> interpret them correctly.
>
> Not really. The BF code to do one simple high level operation could
> easily span several pages. You can't "recognize" those. Now, BF with
> macros/subroutines might be more plausible - if you could define a new
> opcode that represents some huge slab of BF code and use that - but in
> its native form, I don't think anyone could recognize what BF is doing.
Dude, there are people who can recite pi to ten thousand digits, or tell
you the 23rd phone number on page 348 of the White Pages from memory.
Somewhere out there is a guy who can glance at eight pages of BF code and
tell you what it does and where the bugs are.
>> No, I'm sorry, I disagree that the standard of readability should be
>> the experienced programmer. By that standard, "readability" is a no-op.
>> All languages are, more or less, equally readable, to those who can
>> read them well. I don't think it is useful to judge the readability of
>> Forth on the ability of Charles Moore to read it. How does that help me
>> decide whether to use Forth for my next project?
>>
>>> If I write a whole lot of code today, and next year I'm dead and
>>> someone else has replaced me, I frankly don't mind if he has to learn
>>> the language before he can grok my code. I _do_ mind if, even after
>>> he's learned the language, he can't figure out what my code's doing;
>>
>> Then he hasn't learned the language *sufficiently well*. Either that,
>> or your code is obfuscated, unidiomatic crap. Perhaps you're trying to
>> write BF in Python :)
>
> And that's where the nub of the question is. How well is sufficiently
> well? Clearly you do not require your code to be comprehensible to a
> non-programmer, or you would not write code at all. If you don't demand
> that the reader learn basic keywords of the language, then it's equally
> impossible to expect them to comprehend your code. If you're writing
> production code, I see no reason to avoid language features like
> Python's list comps, Pike's %{ %} sprintf codes, or C's pointer
> arithmetic, just because they can confuse people. Learn the language,
> THEN start hacking on the code.
Certainly. I don't mean to imply that code should always be written for
beginners. Code is primarily written for other programmers, and only
secondly for the compiler, so you must choose your audience. Every piece
of code needs to weigh up many different characteristics, some of which
are in conflict:
* fast to run
* fast to write
* efficient use of memory or other resources
* easy to add functionality
* easy to debug
* understandable to non-experts
* useful
* correct
The last two are especially interesting. Some problems can't be solved
correctly in any reasonable timeframe, but heuristics can give an answer
which may not be strictly correct but still useful. Many optimization
problems are like that. Sometimes a close answer is better than no answer
at all.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-03-20 12:20 +0000 |
| Message-ID | <m16nle.hwc@spenarnc.xs4all.nl> |
| In reply to | #21875 |
In article <mailman.795.1332131633.3037.python-list@python.org>,
Chris Angelico <rosuav@gmail.com> wrote:
>On Mon, Mar 19, 2012 at 12:23 PM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> wrote:
>> On Mon, 19 Mar 2012 09:02:06 +1100, Chris Angelico wrote:
>>
>>> On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky@my-deja.com>
>>> wrote:
>>>> What I would say is that, when PROGRAMMERS look at Python code for the
>>>> first time, they will understand what it does more readily than they
>>>> would understand other unfamiliar programming languages. =A0That has
>>>> value.
>>>
>>> This is something that's never truly defined.
>>
>> I'm sorry, I don't understand what part of John's sentence you mean by
>> "this". "Programmers"? "Value"? "Understand"?
>
>I should have rewritten that into the next paragraph. Anyhow. Further
>explanation below.
>
>>> Everyone talks of how this
>>> language or that language is readable, but if you mean that you can look
>>> at a line of code and know what *that line* does then Python suffers
>>> badly and assembly language wins out;
>>
>> This is at least the second time you've alleged that assembly language is
>> more readable than Python. I think you're a raving nutter, no offence
>> Chris :-)
>
>None taken; guilty as charged. And unashamedly so. With that dealt
>with, though: My calling assembly "readable" is a form of argument by
>drawing to logical, but absurd, conclusion - by the given definition
>of readability, assembly is readable, ergo the definition sucks.
>(That's a term all logicians use, you know. Proper and formal jargon.)
>
>> Assignment (name binding) is close to the absolute simplest thing you can
>> do in a programming language. In Python, the syntax is intuitive to
>> anyone who has gone through high school, or possibly even primary school,
>> and been introduced to the equals sign.
>>
>> x =3D 1234
>> y =3D "Hello"
>
>Not quite. In mathematics, "x =3D 1234" is either a declaration of fact,
>or a statement that can be either true or false. In mathematics, "x =3D
>x + 1" is absurd and/or simply false. That's why Pascal has its :=3D
>operator, supposed to be read as "becomes" and not "equals". IMHO this
>is simply proof of one of the differences between programming and
>mathematics.
>
>> I don't know about anyone else, but I wouldn't have guessed that the way
>> to get x=3D1234 was with "x dw 1234".
>
>Except that it's not quite the same thing. That 8086 Assembly
>statement is more like the C statement:
>int x=3D1234;
>The nearest equivalent of assignment is:
>mov x,1234
I tried to mentally translate that to my ciasdis assembler syntax
and discovered that there is no instruction in the 8086 for that.
It would require using a scratch register like AX.
In my very precise ciasdis assembler syntax it would be 1]
XXXXXX: DL 0
MOVI, X| R| AX| 1234 IL,
MOV, X| F| R| [AX] XXXXXX L,
If you were restricted to the 8086, (not 80386 or better)
you could not have chosen AX, and you would have used BX instead.
[ The first MOVI, could be replaced by a LEA, instruction
LEA, AX'| MEM| XXXXXX L,
(Go figure!) ]
So a realistic fragment could have been
PUSH|X BX,
MOVI, X| R| BX| 1234 IL,,
MOV, X| F| R| [BX] XXXXXX L,
POP|X BX,
The real unreadability comes from the fact that the novice would
ask herself why on earth the BX register was freed while the AX
register was free to use. And she is lucky, because no flags
were harmed in this sequence, another pitfall.
You can't blame me for the unreadibility of the ciasdis-syntax.
It merely reflects the abomination that the 8086/80386/Pentium
is.
Bottom line. A comparison between a HLL where the goal is abstraction
and assembly where the goal is precision and control, is unproductive.
And if you insist to do it, you better be a real expert.
<SNIP>
>
>And that's where the nub of the question is. How well is sufficiently
>well? Clearly you do not require your code to be comprehensible to a
>non-programmer, or you would not write code at all. If you don't
>demand that the reader learn basic keywords of the language, then it's
>equally impossible to expect them to comprehend your code. If you're
>writing production code, I see no reason to avoid language features
>like Python's list comps, Pike's %{ %} sprintf codes, or C's pointer
>arithmetic, just because they can confuse people. Learn the language,
>THEN start hacking on the code.
Can we just agree, that it is a compromise?
>
>ChrisA
1] ciasdis.html on the site in my sig.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | alex23 <wuwei23@gmail.com> |
|---|---|
| Date | 2012-03-18 20:15 -0700 |
| Message-ID | <3904be71-335e-43a9-9e82-024abb1729b5@ni10g2000pbc.googlegroups.com> |
| In reply to | #21865 |
John Ladasky <lada...@my-deja.com> wrote: > > The idea that Python code has to be obvious to non-programmers is an > > incorrect and dangerous one. > > Incorrect? Probably. Dangerous? You'll have to explain what you > mean. The classic "obvious" behaviour to new Python programmers that causes problems would be mutable default arguments. At this point you have two options: improve the "readability" to new users so their expectations are met, or ask them to modify those expectations and understand what's really happening under the surface. As it stands, you tend to hit this problem pretty early on, learn about it, and walk away with a deeper knowledge of Python's mechanics. The danger, I feel, is that changing it to better fit the mind-set that non-Python programmers bring with them could mask that necessary understanding for longer.
[toc] | [prev] | [next] | [standalone]
| From | Chris Rebert <clp2@rebertia.com> |
|---|---|
| Date | 2012-03-18 21:14 -0700 |
| Message-ID | <mailman.794.1332130470.3037.python-list@python.org> |
| In reply to | #21873 |
On Sun, Mar 18, 2012 at 8:15 PM, alex23 <wuwei23@gmail.com> wrote: > John Ladasky <lada...@my-deja.com> wrote: >> > The idea that Python code has to be obvious to non-programmers is an >> > incorrect and dangerous one. >> >> Incorrect? Probably. Dangerous? You'll have to explain what you >> mean. > > The classic "obvious" behaviour to new Python programmers that causes > problems would be mutable default arguments. At this point you have > two options: improve the "readability" to new users so their > expectations are met, or ask them to modify those expectations and > understand what's really happening under the surface. As it stands, > you tend to hit this problem pretty early on, learn about it, and walk > away with a deeper knowledge of Python's mechanics. The mechanics of default arguments maybe, but that's tautological. If you mean call-by-object, any time you pass both mutable and immutable things around, you will learn the same lesson. If you mean the more general principle that "Python doesn't ever copy things unless you explicitly ask", working with lists (and particularly their multiplication operator) again tends to also teach that lesson. > The danger, I > feel, is that changing it to better fit the mind-set that non-Python > programmers bring with them could mask that necessary understanding > for longer. I disagree. Just add a keyword for each default argument evaluation behavior (evaluate-once-at-definition-time [e.g. "once", "static"] and evaluate-at-call-time [e.g. "fresh"]) and don't have there be a default behavior; make the choice explicit. They'll be confronted with the issue as soon as they're shown default arguments, and keywords are easy to look up the meaning of. And as I said previously, there are other common ways to learn any of the "lessons" that default arguments might "teach". If-I-had-my-druthers-ly yours, Chris (R.)
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-20 12:55 -0400 |
| Message-ID | <mailman.835.1332262511.3037.python-list@python.org> |
| In reply to | #21865 |
Just to troll the discussion a little bit more... On Sun, Mar 18, 2012 at 6:02 PM, Chris Angelico <rosuav@gmail.com> wrote: > On Mon, Mar 19, 2012 at 8:30 AM, John Ladasky <ladasky@my-deja.com> wrote: >> What I would say is that, when PROGRAMMERS look at Python code for the >> first time, they will understand what it does more readily than they >> would understand other unfamiliar programming languages. That has >> value. > > This is something that's never truly defined. Everyone talks of how > this language or that language is readable, but if you mean that you > can look at a line of code and know what *that line* does, then Python > suffers badly and assembly language wins out; but if you mean that you > should be able to glance over an entire function and comprehend its > algorithm, then I have yet to see any language in which it's not > plainly easy to write bad code. Even with good code, anything more > than trivial can't be eyeballed in that way - if you could, what would > docstrings be for? I agree, docstrings/code comments are a pretty obvious indication that code (as it exists currently) fails as a human communication medium. I suppose that I could make an exception for elaboration on statement with subtle implications. This seems like something people should think more about fixing. > Really, the metric MUST be Python programmers. Intuitiveness is of > value, but readability among experienced programmers is far more > useful. If I write a whole lot of code today, and next year I'm dead > and someone else has replaced me, I frankly don't mind if he has to > learn the language before he can grok my code. I _do_ mind if, even > after he's learned the language, he can't figure out what my code's > doing; and that's where Python's placed itself at about the right > level - not so high that it's all in airy-fairy conceptual work, but > not so low that it gets bogged down. There's a handful of other > languages that are similarly placed, and they're the languages that I > would call "readable". 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. In my opinion, language readability and usability should be determined based on the following tests: - Given users with no programming experience: -- What is the probability that they can correctly guess the result of a program, and how long does it take? -- What is the probability that they can take a program and correctly modify it to change its output to another specified output, or modify it to support another input representation, and how long does it take? - Given users with no programming experience who are provided with a controlled training period: -- What is the probability that they can produce a program that correctly implements a simple, completely described algorithm for solving a puzzle or winning a game, and how long does it take? - Given users with previous (but not extensive) programming experience who are provided with a controlled training period: -- What is the probability that they can produce a program that correctly implements a simple, partially described algorithm for solving a puzzle or winning a game, and how long does it take? -- What is the probability that they can produce a program that correctly implements a complex, completely described algorithm for solving a puzzle or winning a game, and how long does it take? It would probably also be worth examining user behavior relating to code organization and composition under a variety of circumstances. It seems likely that if proper organization and composition are intuitive, productivity would scale well with program size. > Here's an analogy: One statement (aka line of code, etc) corresponds > to one sentence in English. Massive one-liners are like some of the > sentences in Paul's epistles; assembly language is like "The cat sat > on the mat". Both are valid; both are hard to read. This is one of my gripes with the dogmatic application of the "break it into multiple statements" mantra of Python. Not only are you forced to use generators to maintain semantic equivalence in many cases, in some cases a partial statement fragment doesn't have any intuitive meaning. The result is that readers are forced to hold the value of intermediate_variable in their head while reading another statement, then translate the statement to the conceptually complete form. A statement should be an encoding from a conceptual space to a operation space, and ideally the two should be as similar as possible. If a concept is atomic, it should not be comprised of multiple statements.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-20 17:48 +0000 |
| Message-ID | <4f68c2db$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21935 |
On Tue, 20 Mar 2012 12:55:07 -0400, 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". > Not only are you forced to > use generators to maintain semantic equivalence in many cases, in some > cases a partial statement fragment doesn't have any intuitive meaning. > The result is that readers are forced to hold the value of > intermediate_variable in their head while reading another statement, > then translate the statement to the conceptually complete form. A > statement should be an encoding from a conceptual space to a operation > space, and ideally the two should be as similar as possible. > If a concept is atomic, it should not be comprised of multiple > statements. Perhaps you could give some examples (actual or contrived) of stuff where "breaking it into multiple statements" is a bad thing? -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-03-20 14:09 -0400 |
| Message-ID | <mailman.837.1332266975.3037.python-list@python.org> |
| In reply to | #21865 |
On 3/20/2012 12:55 PM, Nathan Rice wrote: > 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. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Nathan Rice <nathan.alexander.rice@gmail.com> |
|---|---|
| Date | 2012-03-20 15:28 -0400 |
| Message-ID | <mailman.838.1332271709.3037.python-list@python.org> |
| In reply to | #21865 |
>> 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. 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. It would be really awesome if everyone used links to that material in docstrings, and the default sphinx theme created an inline collapsible iframe that included that material for the HTML version. Don't get me wrong, I adore Sphinx, the problem here is people who are lazy or don't know the right way to structure docs.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2012-03-21 00:22 +0000 |
| Message-ID | <4f691f3d$0$29981$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #21942 |
On Tue, 20 Mar 2012 15:28:25 -0400, 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? I'm sorry, that is far too abstract for me. Do you have a *concrete* example, even an trivial one? > 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. 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. http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two 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. 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. [...] > 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". > 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. > It would be really awesome if > everyone used links to that material in docstrings, and the default > sphinx theme created an inline collapsible iframe that included that > material for the HTML version. Don't get me wrong, I adore Sphinx, the > problem here is people who are lazy or don't know the right way to > structure docs. +1000 -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-20 18:28 -0700 |
| Message-ID | <b1b53639-05fd-45a9-81be-3f19213d17d8@ur9g2000pbc.googlegroups.com> |
| In reply to | #21963 |
On Mar 20, 5:22 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 20 Mar 2012 15:28:25 -0400, Nathan Rice wrote:
>
> > 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 with Steven that horizontal bloat hurts readability more than
vertical bloat. Of course, it's a subjective thing, and I get the
fact that the remedy to horizontal bloat often means more volume of
code overalls (i.e. introducing locals).
My main problem with horizontal bloat is that you often have to read
inside-outside or right to left:
verb3(verb2(verb1(noun)))
verb2(verb1(noun, adverb1), adverb2)
The vertical versions tend to be more verbose, but entirely
sequential:
noun1 = verb1(noun)
noun2 = verb2(noun1)
verb3(noun2)
and
noun1 = verb1(noun, adverb1)
verb2(noun1, adverb2)
There is a bit of an inflection point when the number of lines in the
"local" code exceeds the vertical real estate of your monitor. I feel
like vertical real estate is still mostly constrained by the way we
build our monitors and our editors, and it's not so much a "human
brain" limitation. With horizontally stretched code, I always feel
like my brain is the bottleneck.
The one place where I don't mind the horizontal approach is when code
is truly laid out in the order of execution:
noun.verb1(adverb1).verb2(adverb2).verb3(adverb3).verb4(adverb4)
Even then, I'd prefer it to read vertically. Also, while the above
idiom puts the verbs in the right order, it is still backward to me to
say "noun.verb." You don't noun a verb. You verb a noun.
[toc] | [prev] | [next] | [standalone]
| From | Ben Finney <ben+python@benfinney.id.au> |
|---|---|
| Date | 2012-03-21 13:28 +1100 |
| Message-ID | <87d386lmai.fsf@benfinney.id.au> |
| In reply to | #21964 |
Steve Howell <showell30@yahoo.com> writes: > Also, while the above idiom puts the verbs in the right order, it is > still backward to me to say "noun.verb." You don't noun a verb. You > verb a noun. When calling a method, the program object is the grammatical subject. You don't verb the noun, and you don't noun a verb. The noun verbs. -- \ “Last year I went fishing with Salvador Dali. He was using a | `\ dotted line. He caught every other fish.” —Steven Wright | _o__) | Ben Finney
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-20 19:44 -0700 |
| Message-ID | <8a77bf8d-b12f-442b-a1a3-479b5d66d366@tx8g2000pbc.googlegroups.com> |
| In reply to | #21965 |
On Mar 20, 7:28 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > Steve Howell <showel...@yahoo.com> writes: > > Also, while the above idiom puts the verbs in the right order, it is > > still backward to me to say "noun.verb." You don't noun a verb. You > > verb a noun. > > When calling a method, the program object is the grammatical subject. > You don't verb the noun, and you don't noun a verb. The noun verbs. > I think it's a matter of perspective, so there's no right answer, but I always think of the program object as also being the grammatical object, with the implied subject/actor being Python itself. For example, consider this code: stack.push(item) It's not the stack that's pushing. It's the stack being pushed on to. So "stack" is the direct object, and "item" is the indirect object. When you say "stack.push(item)", I think of it as being that Python pushes an item on to the stack. I suppose you would argue that the stack pushes item on to itself? And even then, isn't it still the grammatical object in the "itself" case? Also, don't they call those thingies "object" for a reason? ;)
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2012-03-21 15:16 +1100 |
| Message-ID | <mailman.851.1332303399.3037.python-list@python.org> |
| In reply to | #21966 |
On Wed, Mar 21, 2012 at 1:44 PM, Steve Howell <showell30@yahoo.com> wrote: > I think it's a matter of perspective, so there's no right answer, but > I always think of the program object as also being the grammatical > object, with the implied subject/actor being Python itself. For > example, consider this code: > > stack.push(item) > > It's not the stack that's pushing. It's the stack being pushed on > to. In code, though, the push() method is defined in and on the stack object (or more likely, on the class that instantiated it, but near enough). So the stack is being asked to push something onto itself. It is still viably the subject. Yes, the implied subject could be the language interpreter; but it could just as easily be the CPU, or those friendly nanobots, or that guy moving the rocks in XKCD 505. But in the abstraction of the line of code, you don't care how CPython goes about loading globals, calling bound methods, and incrementing object reference counts - you just care that the stack is pushing this item onto itself. Some method names are definitely written as though their primary argument is the object, not the subject. Either option works. Do you think about code as the subject+verb and a data structure as the object, or the object as the subject and the method as the verb? Fundamentally no difference. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steve Howell <showell30@yahoo.com> |
|---|---|
| Date | 2012-03-20 21:58 -0700 |
| Message-ID | <e43dbdbf-2e6b-420a-b66a-7f5f756a5cb5@pg2g2000pbb.googlegroups.com> |
| In reply to | #21969 |
On Mar 20, 9:16 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 1:44 PM, Steve Howell <showel...@yahoo.com> wrote:
> > I think it's a matter of perspective, so there's no right answer, but
> > I always think of the program object as also being the grammatical
> > object, with the implied subject/actor being Python itself. For
> > example, consider this code:
>
> > stack.push(item)
>
> > It's not the stack that's pushing. It's the stack being pushed on
> > to.
>
> In code, though, the push() method is defined in and on the stack
> object (or more likely, on the class that instantiated it, but near
> enough). [...]
The interpretation that the "subject" is the Stack class itself leads
to this coding style:
Stack.push(stack, item)
The above code takes duck-typing to an extreme--you don't have to
assume that "stack" was instantiated from "Stack" in order to apply
"Stack.push" to "stack" (where "Stack" acts a the subject and "stack"
acts as a grammatical direct object).
Of course, 99% of the time, we want some sugar that makes Stack be the
implicit subject (given that "stack" was instantiated from "Stack"):
stack.push(item) # push comes from Stack via stack
> Yes, the implied subject could be the
> language interpreter; but it could just as easily be the CPU, or those
> friendly nanobots, or that guy moving the rocks in XKCD 505. But in
> the abstraction of the line of code, you don't care how CPython goes
> about loading globals, calling bound methods, and incrementing object
> reference counts - you just care that the stack is pushing this item
> onto itself.
Sure, that's all good, but, colloquially, I bet you've probably said
at one time in your life, "And, here, we are pushing the item on to
the stack." The subject is vague ("we"), but there is no assumption
of friendly nanobots (or vigorous hamsters, or CPUs, or any specific
mechanisms), just the idea that the stack is the object, not the
subject.
> Some method names are definitely written as though their primary
> argument is the object, not the subject. Either option works. Do you
> think about code as the subject+verb and a data structure as the
> object, or the object as the subject and the method as the verb?
> Fundamentally no difference.
At a certain fundamental level, sure, of course it's all just data
structure and code, so we shouldn't be quibbling about syntax or
grammar, and we certainly shouldn't be throwing around strained
analogies to natural languages.
But in this context, we are musing about grammar, so I would propose
this question:
What's more important, the object or the method?
IMHO the method is usually more interesting than the object itself.
Of course, the "stack" itself is important, but on any given line of
code, the action is more interesting, so I'd want to lead with "push"
or "pop."
Verb-first gets a bad rap, because people tend to associate verb-first
syntax with early, primitive imperative/functional languages that had
no OO syntax.
Assembly tends to be very imperative:
MOV AX, BX
So saying "push(stack, item)" or "push(item, stack)" seems very
unsophisticated, almost assembly-like in syntax, albeit at a higher
level conceptually than assembly.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.python
csiph-web