Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #4380 > unrolled thread
| Started by | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| First post | 2011-05-01 08:45 +0000 |
| Last post | 2011-05-04 07:28 -0700 |
| Articles | 20 on this page of 176 — 34 participants |
Back to article view | Back to comp.lang.python
What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-01 08:45 +0000
Re: What other languages use the same data model as Python? Alec Taylor <alec.taylor6@gmail.com> - 2011-05-01 19:00 +1000
Re: What other languages use the same data model as Python? Chris Rebert <clp2@rebertia.com> - 2011-05-01 02:04 -0700
Re: What other languages use the same data model as Python? Terry Reedy <tjreedy@udel.edu> - 2011-05-01 15:10 -0400
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-02 10:37 +1200
Re: What other languages use the same data model as Python? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-02 07:45 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-02 13:12 +0000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-02 10:33 +1200
Re: What other languages use the same data model as Python? Terry Reedy <tjreedy@udel.edu> - 2011-05-01 21:42 -0400
Re: What other languages use the same data model as Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-02 00:28 -0700
Re: What other languages use the same data model as Python? Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-02 08:43 +0000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-03 13:39 +0100
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-03 14:49 +0000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-03 15:20 +0000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-03 22:10 +0100
Re: What other languages use the same data model as Python? Mel <mwilson@the-wire.com> - 2011-05-03 12:33 -0400
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-03 16:52 +0000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-03 21:47 +0100
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-04 08:00 +1000
Re: What other languages use the same data model as Python? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-05-04 02:56 -0700
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-04 10:51 +0000
Re: What other languages use the same data model as Python? Paul Rubin <no.email@nospam.invalid> - 2011-05-04 03:58 -0700
Re: What other languages use the same data model as Python? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-05-04 06:12 -0700
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 14:44 +0100
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-05 00:20 +1000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 18:09 +0100
Re: What other languages use the same data model as Python? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-05-04 09:18 -0700
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 18:03 +0100
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 20:55 +1200
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-05 11:31 +0100
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-07 21:21 +1200
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-07 19:28 +1000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-08 10:39 +1200
Re: What other languages use the same data model as Python? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-05-20 20:56 +0000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-08 02:17 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-07 23:10 -0500
Re: What other languages use the same data model as Python? rusi <rustompmody@gmail.com> - 2011-05-07 22:48 -0700
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-09 12:52 +1200
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-09 11:38 +0100
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-09 21:18 +1000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-09 21:53 +0100
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-09 14:29 +0000
Re: What other languages use the same data model as Python? Tim Golden <mail@timgolden.me.uk> - 2011-05-09 15:41 +0100
Re: What other languages use the same data model as Python? Ethan Furman <ethan@stoneleaf.us> - 2011-05-09 10:15 -0700
Re: What other languages use the same data model as Python? Mel <mwilson@the-wire.com> - 2011-05-09 13:38 -0400
Re: What other languages use the same data model as Python? Terry Reedy <tjreedy@udel.edu> - 2011-05-09 16:23 -0400
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-10 19:41 +1200
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-10 19:35 +1000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-11 10:47 +1200
Re: What other languages use the same data model as Python? Terry Reedy <tjreedy@udel.edu> - 2011-05-10 15:18 -0400
Re: What other languages use the same data model as Python? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-05-20 21:17 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-09 16:28 -0500
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-09 07:23 +0100
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 15:14 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 14:22 -0500
Re: What other languages use the same data model as Python? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2011-05-04 15:46 -0400
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 14:58 -0500
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 21:40 +0100
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 21:31 +1200
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 14:50 +0000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 12:14 +0000
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-05 22:37 +1000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 20:58 +0100
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 16:49 -0500
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-05 07:12 +0100
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 21:08 +1200
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-05 19:12 +1000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:30 +0000
Re: What other languages use the same data model as Python? TheSaint <nobody@nowhere.net.no> - 2011-05-07 20:18 +0800
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 12:49 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:31 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 09:40 -0500
Re: What other languages use the same data model as Python? Roy Smith <roy@panix.com> - 2011-05-05 10:49 -0400
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 14:47 -0500
Re: What other languages use the same data model as Python? Ben Finney <ben+python@benfinney.id.au> - 2011-05-05 07:43 +1000
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-05 12:43 +1000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 15:42 +0000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-07 22:04 +1200
Re: What other languages use the same data model as Python? Ben Finney <ben+python@benfinney.id.au> - 2011-05-08 06:09 +1000
Re: What other languages use the same data model as Python? Roy Smith <roy@panix.com> - 2011-05-07 16:24 -0400
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-08 10:54 +1200
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-08 09:43 +1000
Re: What other languages use the same data model as Python? Ben Finney <ben+python@benfinney.id.au> - 2011-05-08 11:16 +1000
Re: What other languages use the same data model as Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-07 23:16 -0700
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-08 16:32 +1000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-10 13:49 +1200
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-10 03:13 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-10 14:05 +0000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-10 16:09 +0100
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-10 15:16 +0000
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-11 01:27 +1000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-10 16:40 +0100
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-11 01:44 +1000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-10 13:51 +1200
Re: What other languages use the same data model as Python? MRAB <python@mrabarnett.plus.com> - 2011-05-10 03:47 +0100
Re: What other languages use the same data model as Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-09 23:15 -0700
Re: What other languages use the same data model as Python? John Nagle <nagle@animats.com> - 2011-05-04 14:52 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 19:46 -0500
Re: What other languages use the same data model as Python? John Nagle <nagle@animats.com> - 2011-05-04 21:32 -0700
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 22:06 +1200
Re: What other languages use the same data model as Python? John Nagle <nagle@animats.com> - 2011-05-05 08:41 -0700
Re: What other languages use the same data model as Python? Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-05 10:44 -0600
Re: What other languages use the same data model as Python? Chris Torek <nospam@torek.net> - 2011-05-06 17:57 +0000
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-07 21:39 +1200
Re: What other languages use the same data model as Python? Mel <mwilson@the-wire.com> - 2011-05-05 07:44 -0400
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-05 21:48 +1000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 13:59 +0000
Re: What other languages use the same data model as Python? John Nagle <nagle@animats.com> - 2011-05-05 08:58 -0700
Re: What other languages use the same data model as Python? Neil Cerutti <neilc@norwich.edu> - 2011-05-05 13:19 +0000
Re: What other languages use the same data model as Python? Terry Reedy <tjreedy@udel.edu> - 2011-05-05 14:39 -0400
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 11:56 +0100
Re: What other languages use the same data model as Python? Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-05-04 06:13 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 14:33 -0500
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-04 20:19 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 16:35 -0500
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-04 21:57 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 20:11 -0500
Re: What other languages use the same data model as Python? Mark Hammond <mhammond@skippinet.com.au> - 2011-05-05 12:09 +1000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 23:01 -0500
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 22:19 +1200
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:17 +0000
Re: What other languages use the same data model as Python? Roy Smith <roy@panix.com> - 2011-05-05 10:31 -0400
Re: What other languages use the same data model as Python? Neil Cerutti <neilc@norwich.edu> - 2011-05-05 15:10 +0000
Re: What other languages use the same data model as Python? Roy Smith <roy@panix.com> - 2011-05-05 11:29 -0400
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-06 08:01 +1000
Re: What other languages use the same data model as Python? Neil Cerutti <neilc@norwich.edu> - 2011-05-06 13:10 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 16:57 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 16:56 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 11:58 -0500
Re: What other languages use the same data model as Python? Neil Cerutti <neilc@norwich.edu> - 2011-05-05 17:39 +0000
Re: What other languages use the same data model as Python? Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-05 13:13 -0600
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 15:12 -0500
Re: What other languages use the same data model as Python? Tim Roberts <timr@probo.com> - 2011-05-04 20:23 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 23:55 -0500
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:21 +0000
Re: What other languages use the same data model as Python? Mel <mwilson@the-wire.com> - 2011-05-05 08:09 -0400
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-05 07:34 +0100
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 14:10 +0000
Re: What other languages use the same data model as Python? Mel <mwilson@the-wire.com> - 2011-05-05 11:30 -0400
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 10:56 -0500
RE: What other languages use the same data model as Python? Andreas Tawn <andreas.tawn@ubisoft.com> - 2011-05-05 18:27 +0200
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-07 22:09 +1200
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-06 07:56 +1000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:14 +0000
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 15:11 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 11:00 -0500
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 16:52 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 12:03 -0500
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-07 22:12 +1200
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-07 12:03 +0000
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 16:48 +0000
Re: What other languages use the same data model as Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-05 22:24 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 11:18 -0500
Re: What other languages use the same data model as Python? Ethan Furman <ethan@stoneleaf.us> - 2011-05-05 10:28 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 12:19 -0500
Re: What other languages use the same data model as Python? Chris Torek <nospam@torek.net> - 2011-05-06 18:17 +0000
Re: What other languages use the same data model as Python? Chris Torek <nospam@torek.net> - 2011-05-06 19:06 +0000
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-06 14:25 -0500
Re: What other languages use the same data model as Python? Chris Angelico <rosuav@gmail.com> - 2011-05-07 09:43 +1000
Re: What other languages use the same data model as Python? Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-04 16:22 -0600
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-04 19:51 -0500
Re: What other languages use the same data model as Python? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-05 14:51 +0000
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-04 21:20 +0100
Re: What other languages use the same data model as Python? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-04 22:10 -0700
Re: What other languages use the same data model as Python? harrismh777 <harrismh777@charter.net> - 2011-05-05 00:19 -0500
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:25 +0000
Re: What other languages use the same data model as Python? sturlamolden <sturla@molden.no> - 2011-05-04 07:44 -0700
Re: What other languages use the same data model as Python? Michael Torrie <torriem@gmail.com> - 2011-05-04 09:40 -0600
Re: What other languages use the same data model as Python? sturlamolden <sturla@molden.no> - 2011-05-04 09:40 -0700
Re: What other languages use the same data model as Python? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2011-05-04 13:15 -0400
Re: What other languages use the same data model as Python? sturlamolden <sturla@molden.no> - 2011-05-04 10:19 -0700
Re: What other languages use the same data model as Python? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-05 15:48 +1200
Re: What other languages use the same data model as Python? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-05 05:58 +0100
Re: What other languages use the same data model as Python? Grant Edwards <invalid@invalid.invalid> - 2011-05-05 14:24 +0000
Re: What other languages use the same data model as Python? Hrvoje Niksic <hniksic@xemacs.org> - 2011-05-03 15:50 +0200
Re: What other languages use the same data model as Python? sturlamolden <sturla@molden.no> - 2011-05-04 07:28 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Hans Georg Schaathun <hg@schaathun.net> |
|---|---|
| Date | 2011-05-09 21:53 +0100 |
| Message-ID | <dr0m98-8g2.ln1@svn.schaathun.net> |
| In reply to | #4989 |
On Mon, 9 May 2011 21:18:29 +1000, Chris Angelico <rosuav@gmail.com> wrote: : Analogies are like diagrams. Not all of them are perfect or useful. : : The boxes are different sizes. If you really want them to look : different, do one as squares and one as circles, but don't try that in : plain text. Analogies, even imperfect ones, are good when we are clear about the fact that they are analogies. Using C pointers to illustrate how to use bound names in python may be useful, but only if we are clear about the fact that it is an analogy and do not pretend that it explains it in full. -- :-- Hans Georg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-05-09 14:29 +0000 |
| Message-ID | <4dc7fa2f$0$29991$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #4967 |
On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>
>> Since you haven't explained what you think is happening, I can only
>> guess.
>
> Let me save you from guessing. I'm thinking of a piece of paper with a
> little box on it and the name 'a' written beside it. There is an arrow
> from that box to a bigger box.
>
> +-------------+
> +---+ | |
> a | --+---------------->| |
> +---+ | |
> +-------------+
>
> There is another little box labelled 'b'. After executing 'a = b', both
> little boxes have arrows pointing to the same big box.
[...]
> In this model, a "reference" is an arrow. Manipulating references
> consists of rubbing out the arrows and redrawing them differently.
All very good, but that's not what takes place at the level of Python
code. It's all implementation. I think Hans Georg Schaathun made a good
objection to the idea that "Python has references":
In Pascal a pointer is a distinct data type, and you can
have variables of a given type or of type pointer to that
given type. That makes the pointer a concrete concept
defined by the language.
The same can't be said of "references" in Python. It's not part of Python
the language, although it might be part of Python's implementation.
> Also
> in this model, a "variable" is a little box. It's *not* the same thing
> as a name; a name is a label for a variable, not the variable itself.
That's essentially the same model used when dealing with pointers. I've
used it myself, programming in Pascal. The "little box" named a or b is
the pointer variable, and the "big box" is the data that the pointer
points to.
It's not an awful model for Python: a name binding a = obj is equivalent
to sticking a reference (a pointer?) in box a that points to obj.
Certainly there are advantages to it.
But one problem is, the model is ambiguous with b = a. You've drawn
little boxes a and b both pointing to the big box (which I deleted for
brevity). But surely, if a = 1234 creates a reference from a to the big
box 1234, then b = a should create a reference from b to the box a?
+-------------+
+---+ | |
a | --+---------------->| |
+---+ | |
^ +-------------+
|
+-|-+
b | | |
+---+
which is the reference (pointer) model as most people would recognise it.
That's how it works in C and Pascal (well, at least with the appropriate
type declarations). To get b pointing to the big box, you would need an
explicit dereference: "b = whatever a points to" rather than "b = a".
Of course, both of these concepts are models, which is another word for
"lies" *wink*. Your model is closer to what the CPython implementation
actually does, using actual C pointers, except of course you do need to
dereference the pointers appropriately. One of my objections to it is not
that it is wrong (all models are wrong) but that it will mislead some
people to reason incorrectly about Python's behaviour, e.g. that b now
points to the little box a, and therefore if you change what a points to,
b will follow along. The whole "call by reference" thing. I suppose you
might argue that you're not responsible for the misunderstandings of
blinkered C coders *wink*, and there's something to that.
But there's another objection... take, say, the line of Python code:
n = len('hello world')
I can identify the little box "n", which ends up pointing to the big box
holding int 11; another little box "len", which points to a big box
holding a function; and a third big box holding the string 'hello world'.
But where is its little box?
If len were written in pure Python, then *inside* len's namespace there
would be a local little box for the argument. I expect that there is an
analogous local little box for built-in functions too. But I don't care
what happens inside len. What about outside len? Where's the little box
pointing to 'hello world'?
So it seems your model fails to deal with sufficiently anonymous objects.
I say "sufficiently", because of course your model deals fine with
objects without names inside, say, lists: the little box there is the
list slot rather than a named entry in a namespace.
It's not just literals that your model fails to deal with, it's any
expression that isn't bound to a little box:
n = len('hello world') + func(y)
func(y) produces a new object, a big box. Where is the little box
pointing to it?
If we drop down an abstraction layer, we can see where objects live:
>>> code = compile("n = len('hello world') + func(y)", '', 'single')
>>> import dis
>>> dis.dis(code)
1 0 LOAD_NAME 0 (len)
3 LOAD_CONST 0 ('hello world')
6 CALL_FUNCTION 1
9 LOAD_NAME 1 (func)
12 LOAD_NAME 2 (y)
15 CALL_FUNCTION 1
18 BINARY_ADD
19 STORE_NAME 3 (n)
22 LOAD_CONST 1 (None)
25 RETURN_VALUE
Both the call to len and the call to func push their results onto the
stack. There's no little box pointing to the result. There's no little
box pointing to len, or y, or any of the others: there are just names and
abstract operations LOAD_NAME and friends.
Again, this is just an abstraction layer. Python objects can be huge,
potentially hundreds of megabytes or gigabytes. No way are they being
pushed and popped onto a stack, even if the virtual machine gives the
illusion that they are. For practical reasons, there must be some sort of
indirection. But that's implementation and not the VM's model.
> It seems that you would prefer to eliminate the little boxes and arrows
> and write the names directly beside the objects:
>
> +-------------+
> a | |
> | |
> b | |
> +-------------+
>
> +-------------+
> c | |
> | |
> | |
> +-------------+
That's not a bad model. But again, it's incomplete, because it would
suggest that the big box should be able to read its own name tags, which
of course is impossible in Python. But I suppose one might say, if the
tag is on the outside of the object, the object can't use introspection
to see it, can it?
But note that this is really your model in disguise: if you imagine the
name tags are stuck on with a little piece of blutack, and you carefully
pull on the name and stretch it away, you get a name sitting over here
with a tiny thread of blutack attaching it to the big box over there,
just like in your model.
I actually prefer to keep the nature of the mapping between name and
object abstract: names map to objects. Objects float around in space,
wherever the interpreter happens to put them, and you can optionally give
them names. Objects are dumb and don't know their own name, but the
Python interpreter knows the names. Names are not the only way to ask the
interpreter for an object: e.g. you can put them in a list, and ask for
them by position.
If people then ask, how does the interpreter know the names?, I can add
more detail: names are actually strings in a namespace, which is usually
nothing more than a dict. Oh, and inside functions, it's a bit more
complicated still. And so on.
There is a problem with my model of free-floating objects in space: it
relies on objects being able to be in two places at once, even *inside*
themselves (you can append a list to itself). If you hate that concept,
you'll hate my model. But if you're a science fiction fan from way back,
then you won't have any problem with the idea that objects can be inside
themselves:
http://www.youtube.com/watch?v=51JtuEa_OPc
Remember: it's just a model, and all models are lies. Abstractions all
leak. You can only chose where and how badly they break down.
Now, that's a good challenge for your model. Little boxes only point to
big boxes. So how do you model cycles, including lists that contain
themselves?
> But what would you do about lists? With little boxes and arrows, you can
> draw a diagram like this:
>
> +---+ +---+
> a | --+----->| | +-------------+
> +---+ +---+ | |
> | --+----->| |
> +---+ | |
> | | +-------------+
> +---+
>
> (Here, the list is represented as a collection of variables. That's why
> variables and names are not the same thing -- the elements of the list
> don't have textual names.)
But that's wrong! Names (little boxes) can't point to *slots in a list*,
any more than they can point to other names! This doesn't work:
>>> L = [None, 42, None]
>>> a = L[0]
>>> L[0] = 23
>>> print(a) # This doesn't work!
23
It's a pity that Python doesn't actually have references. Imagine how
much time we'd save: all the unproductive time we spend arguing about
whether Python has references, we could be fixing bugs caused by the use
of references instead...
> But without any little boxes or arrows, you can't represent the list
> itself as a coherent object. You would have to go around and label
> various objects with 'a[0]', 'a[1]', etc.
>
> +-------------+
> a[0] | |
> | |
> | |
> +-------------+
>
> +-------------+
> a[1] | |
> | |
> | |
> +-------------+
>
> This is not very satisfactory. If the binding of 'a' changes, you have
> to hunt for all your a[i] labels, rub them out and rewrite them next to
> different objects. It's hardly conducive to imparting a clear
> understanding of what is going on, whereas the boxes-and-arrows model
> makes it instantly obvious.
But I wouldn't do it like that. I'd do it like this:
0 1 2 3 4
+--------+--------+--------+--------+--------+
a | | | | | |
| | | | | |
| | | | | |
+--------+--------+--------+--------+--------+
which conveniently happens to be the way Python lists actually are set
up. More or less.
[...]
> Finally, there's another benefit of considering a reference to be a
> distinct entity in the data model. If you think of the little boxes as
> being of a fixed size, just big enough to hold a reference, then it's
> obvious that you can only bind it to *one* object at a time. Otherwise
> it might appear that you could draw more than one arrow coming out of a
> name, or write the same name next to more than one object.
But that's pretty much an arbitrary restriction. Why are the boxes so
small? Just because. Why can't you carefully tease the thread of blutack
apart, into a bifurcated Y shaped thread? Just because.
If objects can be in two places at once, why can't names? Just because.
(Actually, because Guido decrees it so. Also because it would be kinda
crazy to do otherwise. I can't think of any language that has a many:many
mapping between names and values.)
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Tim Golden <mail@timgolden.me.uk> |
|---|---|
| Date | 2011-05-09 15:41 +0100 |
| Message-ID | <mailman.1334.1304952080.9059.python-list@python.org> |
| In reply to | #4991 |
On 09/05/2011 15:29, Steven D'Aprano wrote: [... snippage galore ...] Slightly abstract comment: while I don't usually get much enjoyment out of the regular "Python is call-by-value; no it isn't; yes it is" debates, I always enjoy reading Steven D'Aprano's responses. Thanks, Mr D'A. :) TJG
[toc] | [prev] | [next] | [standalone]
| From | Ethan Furman <ethan@stoneleaf.us> |
|---|---|
| Date | 2011-05-09 10:15 -0700 |
| Message-ID | <mailman.1336.1304961326.9059.python-list@python.org> |
| In reply to | #4991 |
Steven D'Aprano wrote: > But that's wrong! Names (little boxes) can't point to *slots in a list*, > any more than they can point to other names! This doesn't work: > > > --> L = [None, 42, None] > --> a = L[0] > --> L[0] = 23 > --> print(a) # This doesn't work! > 23 Minor nitpick -- having a comment saying "this doesn't work" then having output showing that it does is confusing. I had to load up the interpretor to make sure I was confused! ;) ~Ethan~
[toc] | [prev] | [next] | [standalone]
| From | Mel <mwilson@the-wire.com> |
|---|---|
| Date | 2011-05-09 13:38 -0400 |
| Message-ID | <iq98r2$sv3$1@speranza.aioe.org> |
| In reply to | #4991 |
Steven D'Aprano wrote: > It's not an awful model for Python: a name binding a = obj is equivalent > to sticking a reference (a pointer?) in box a that points to obj. > Certainly there are advantages to it. > > But one problem is, the model is ambiguous with b = a. You've drawn > little boxes a and b both pointing to the big box (which I deleted for > brevity). But surely, if a = 1234 creates a reference from a to the big > box 1234, then b = a should create a reference from b to the box a? :) There's a way around that too. Describe literals as "magic names" or "Platonic names" that are bound to objects in ideal space. I actually considered that for a while as a way of explaining to newbs why the characters in a string literal could be different from the characters in the string value. This would probably have troubles of its own; I never took it through the knock-down drag-out disarticulation that would show what the problems were. Mel.
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2011-05-09 16:23 -0400 |
| Message-ID | <mailman.1354.1304972612.9059.python-list@python.org> |
| In reply to | #4991 |
On 5/9/2011 10:29 AM, Steven D'Aprano wrote: > > If people then ask, how does the interpreter know the names?, I can add > more detail: names are actually strings in a namespace, which is usually > nothing more than a dict. Oh, and inside functions, it's a bit more > complicated still. And so on. Which is why I think it best to stick with 'A namespace is a many-to-one mapping (in other words, a function) of names to objects'. Any programmer should understand the abstractions 'mapping' and 'function'. Asking how the interpreter finds the object associated with a name amounts to asking how to do tabular lookup. Well, we basically know, though the details depends on the implementation of the table (mapping). An interpreter can *implement* namespaces various ways. One is to objectify names and namespaces as strings and dicts. If the set of names in a namespace is fixed, another way is to objectify names and namespaces as ints and arrays. Python prohibits 'from x import *' within functions precisely to keep the set of local namespace names fixed. Therefore, CPython can and does always use C ints and array for function local namespaces. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2011-05-10 19:41 +1200 |
| Message-ID | <92s8hlFqn5U1@mid.individual.net> |
| In reply to | #4991 |
Steven D'Aprano wrote:
> All very good, but that's not what takes place at the level of Python
> code. It's all implementation.
Actually, you're right. What I've presented is a paper-and-pencil
implementation of the Python data model. Together with a set of
rules for manipulating the diagram under the direction of Python
code, you have a complete implementation of Python that you can
execute in your head.
And you NEED such an implementation in order to reason correctly
about Python programs under all circumstances.
I find it very difficult to imagine *any* implementation of
Python, computer-based or otherwise, that doesn't have something
equivalent to references. Whether you call them that, or pointers,
or arrows, or object bindings, or something else, the concept
needs to be there in some form.
> But surely, if a = 1234 creates a reference from a to the big
> box 1234, then b = a should create a reference from b to the box a?
>
> +-------------+
> +---+ | |
> a | --+---------------->| |
> +---+ | |
> ^ +-------------+
> |
> +-|-+
> b | | |
> +---+
You can't expect anyone to draw correct conclusions from the
diagram alone; you also need to explain the rules for manipulating
the diagram under control of Python code.
Here, the explanation goes something like this:
1. The right hand side of an assignment denotes a big box. The
literal 1234 in a program denotes a big box containing the integer
value 1234.
2. The left hand side of an assignment denotes a little box. The
effect of an assignment is to make the arrow from the left hand
side's little box point to the big box denoted by the right hand
side.
So the assignment a = 1234 results in
+-------------+
+---+ | |
a | --+---------------->| 1234 |
+---+ | |
+-------------+
3. When a name is used on the right hand side, it denotes whichever
big box is pointed to by the arrow from its little box. So given
the above diagram, the assignment b = a results in
+-------------+
+---+ | |
a | --+---------------->| 1234 |
+---+ | |
+-------------+
^
+---+ |
b | --+---------------------
+---+
Furthermore, from rule 2 alone it's evident that no assignment
can ever make an arrow lead from one little box to another
little box. Arrows can only lead from a little box to a big
box.
> That's how it works in C and Pascal (well, at least with the appropriate
> type declarations).
Um, no, it doesn't, really. There's no way 'b = a' can give
you that in C; you would have to write 'b = &a'. And you
couldn't do it at all in standard Pascal, because there is
no equivalent to the & operator there.
> Your model is closer to what the CPython implementation
> actually does,
I think it's close -- actually, I would say isomorphic --
to what *any conceivable* Python implementation would do in
some form.
> n = len('hello world')
>
> What about outside len? Where's the little box
> pointing to 'hello world'?
> So it seems your model fails to deal with sufficiently anonymous objects.
Anonymous objects are fine. You just draw a little box and
don't write any label beside it. Or you don't bother drawing
a little box at all and just draw a big box until such time
as some little box that you care about needs to point to it.
If that's a problem, then you have the same problem talking
about names bound to objects. An anonymous object obviously
doesn't have any name bound to it. So you have to admit that
objects can exist, at least temporarily, without being bound
to anything, or bound to some anonymous thing.
> Both the call to len and the call to func push their results onto the
> stack. There's no little box pointing to the result.
If you want to model things at that level of detail, then the
stack itself is an array of little boxes inside a frame object.
And the frame object is pointed to by a little box in its
calling frame object, etc. until you get to some global little
box, that doesn't have a name in Python, but exists somewhere
and keeps the chain of active stack frames alive.
But you don't have to draw any of that if you don't want to.
> For practical reasons, there must be some sort of
> indirection. But that's implementation and not the VM's model.
No, it's not just implementation. Indirection is needed for
*correct semantics*, not just practicality.
> There is a problem with my model of free-floating objects in space: it
> relies on objects being able to be in two places at once,
Yes, that's the point I'm trying to make. While it might be
possible to make such a model work, it would require bizarre
contortions that actually obscure what is going on instead
of clarifying it. Trying to teach someone about Python using
a model like that would be actively harmful, and probably
vilolate several human rights conventions.
> But if you're a science fiction fan from way back,
> then you won't have any problem with the idea that objects can be inside
> themselves:
>
> http://www.youtube.com/watch?v=51JtuEa_OPc
Yeah, it's fun to play around with ideas like that precisely
because they twist our brains into knots. But it's not a
good way to explain Python semantics clearly!
> Now, that's a good challenge for your model. Little boxes only point to
> big boxes. So how do you model cycles, including lists that contain
> themselves?
I'll answer your next question first, and come back to that.
>> +---+ +---+
>> a | --+----->| | +-------------+
>> +---+ +---+ | |
>> | --+----->| |
>> +---+ | |
>> | | +-------------+
>> +---+
>
> But that's wrong! Names (little boxes) can't point to *slots in a list*,
The arrow from a is to be understood as pointing to the whole
list, not any particular little box within the list. If you want
to clarify that, you can embellish the big boxes with some kind
of header area and point to that instead.
+---+
a | --+----->/---\
+---+ +---+
| |
+---+
| --+----->/-------------\
+---+ +-------------+
| | | |
+---+ | |
| |
+-------------+
Now, a list that "contains" itself:
--------
| |
+---+ V |
a | --+----->/---\ |
+---+ +---+ |
| | |
+---+ |
| --+-----
+---+
| |
+---+
> But I wouldn't do it like that. I'd do it like this:
>
> 0 1 2 3 4
> +--------+--------+--------+--------+--------+
> a | | | | | |
> | | | | | |
> | | | | | |
> +--------+--------+--------+--------+--------+
But then you can't model two list items bound to the same object,
unless you invoke the two-places-at-once idea. Even then, you would
have trouble unambiguously indicating that boxes draw in two places
are mean to actually represent the *same* object as against two
different objects with equal values.
> Why are the boxes so
> small? Just because. Why can't you carefully tease the thread of blutack
> apart, into a bifurcated Y shaped thread? Just because.
Yes, it's probably just as good to leave it as an arbitrary rule
that a little box can only point to one big box at a time.
--
Greg
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2011-05-10 19:35 +1000 |
| Message-ID | <mailman.1377.1305020125.9059.python-list@python.org> |
| In reply to | #5059 |
On Tue, May 10, 2011 at 12:29 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > If objects can be in two places at once, why can't names? Just because. Because then you'd need some way to identify which object you wanted to refer to - something like name[0] and name[1]. A tuple is one effective way to do this (sort of - actually, the name points at the tuple and the tuple points at each of the objects). On Tue, May 10, 2011 at 12:47 PM, MRAB <python@mrabarnett.plus.com> wrote: > I had heard something about the meaning of the word "gift", so I > checked in Google Translate. For Swedish "gift" it says: > > noun > 1. POISON > 2. VENOM > 3. TOXIN > 4. VIRUS Beware of Swedes bearing gifts! On Tue, May 10, 2011 at 5:41 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Anonymous objects are fine. You just draw a little box and > don't write any label beside it. Or you don't bother drawing > a little box at all and just draw a big box until such time > as some little box that you care about needs to point to it. > > If that's a problem, then you have the same problem talking > about names bound to objects. An anonymous object obviously > doesn't have any name bound to it. So you have to admit that > objects can exist, at least temporarily, without being bound > to anything, or bound to some anonymous thing. There has to be a way to get from some mythical "home" location (which we know in Python as locals()+globals()+current expression - the "current namespace") to your object. That might involve several names, or none at all, but if there's no such path, the object is unreferenced and must be disposed of. IIRC that's not just an implementation detail (the garbage collector), but a language guarantee (that the __del__ method will be called). Names are immaterial to that. Chris Angelico
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2011-05-11 10:47 +1200 |
| Message-ID | <92ttklFqs3U1@mid.individual.net> |
| In reply to | #5062 |
Chris Angelico wrote: > There has to be a way to get from some mythical "home" location (which > we know in Python as locals()+globals()+current expression - the > "current namespace") to your object. That might involve several names, > or none at all, but if there's no such path, the object is > unreferenced and must be disposed of. Yes, that's what I mean by "bound to some anonymous thing". Somewhere in the implementation there must be one or more "root" references, but they don't necessarily have any names that you can refer to from Python. When I say "not bound to any name", I just mean that it's okay to leave some bindings out of your diagram if they're not pertinent to what you're trying to illustrate. For example, you can draw a box representing a string object and trust that something will keep it alive long enough for you to draw an arrow to it from the name you're assigning it to. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2011-05-10 15:18 -0400 |
| Message-ID | <mailman.1386.1305055147.9059.python-list@python.org> |
| In reply to | #5059 |
On 5/10/2011 3:41 AM, Gregory Ewing wrote: > Actually, you're right. What I've presented is a paper-and-pencil > implementation of the Python data model. Together with a set of > rules for manipulating the diagram under the direction of Python > code, you have a complete implementation of Python that you can > execute in your head. I think that it would be both fun and useful to have an animated graphical tutorial that used and box and arrow model. Names should be in ovals (instead of the little boxes used here due to text limitations) to differentiate them from objects. Immutable objects could have solid boundaries and mutables a broken line boundary. Collection objects would have dotted lines to separate slots. Ovals could also use different lines for builtins, globals, and locals. > And you NEED such an implementation in order to reason correctly > about Python programs under all circumstances. > > I find it very difficult to imagine *any* implementation of > Python, computer-based or otherwise, that doesn't have something > equivalent to references. Whether you call them that, or pointers, > or arrows, or object bindings, or something else, the concept > needs to be there in some form. Since namespaces link names in a namespace with objects not in the namespace, any practical implementation needs a third entity to link or associated each name with an object. This is pretty much needed to explain multiple links without objects being in multiple locations. It is also needed to explain how an object can link to itself. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2011-05-20 21:17 +0000 |
| Message-ID | <llij5q.4cb@spenarnc.xs4all.nl> |
| In reply to | #4991 |
In article <4dc7fa2f$0$29991$c3e8da3$5496439d@news.astraweb.com>, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote: > >> Steven D'Aprano wrote: >> >>> Since you haven't explained what you think is happening, I can only >>> guess. >> >> Let me save you from guessing. I'm thinking of a piece of paper with a >> little box on it and the name 'a' written beside it. There is an arrow >> from that box to a bigger box. >> >> +-------------+ >> +---+ | | >> a | --+---------------->| | >> +---+ | | >> +-------------+ >> >> There is another little box labelled 'b'. After executing 'a = b', both >> little boxes have arrows pointing to the same big box. >[...] >> In this model, a "reference" is an arrow. Manipulating references >> consists of rubbing out the arrows and redrawing them differently. > >All very good, but that's not what takes place at the level of Python >code. It's all implementation. I think Hans Georg Schaathun made a good >objection to the idea that "Python has references": > > In Pascal a pointer is a distinct data type, and you can > have variables of a given type or of type pointer to that > given type. That makes the pointer a concrete concept > defined by the language. > >The same can't be said of "references" in Python. It's not part of Python >the language, although it might be part of Python's implementation. > > > >> Also >> in this model, a "variable" is a little box. It's *not* the same thing >> as a name; a name is a label for a variable, not the variable itself. > >That's essentially the same model used when dealing with pointers. I've >used it myself, programming in Pascal. The "little box" named a or b is >the pointer variable, and the "big box" is the data that the pointer >points to. > >It's not an awful model for Python: a name binding a = obj is equivalent >to sticking a reference (a pointer?) in box a that points to obj. >Certainly there are advantages to it. > >But one problem is, the model is ambiguous with b = a. You've drawn >little boxes a and b both pointing to the big box (which I deleted for >brevity). But surely, if a = 1234 creates a reference from a to the big >box 1234, then b = a should create a reference from b to the box a? There are cleaner languages. Algol 68 , Forth. This is Forth. VARIABLE A VARIABLE B 1234 ( anonymous "object" created by the language ) A ! A @ B ! ( Copy the content, equivalent of B=A). Algol 68 B:=A compiler : THINK ! THINK ! A is a "ref int" so it can't be stored into b which is a "ref int" which is the name of a place where an int can be stored (not where a ref int could be stored.) Solution: Algol dereferences A into an int, by getting its content. But it is a rule, very explicitly explained in the language definition. (If you are that clean you can handle "ref ref int q" where q is the name of a place where a "ref int" can be stored.) "real a" is in fact an abbreviation of "ref real a=loc real" meaning "a" is a reference to a local real, that is anonymous. The = means that the connection between a and that real is an identity, i.e. the connection can't be broken. (Forget about C++, "casting away const", yuck! ) In Forth and in Algol 68 storing a constant into a variable is very different from copying the content of a variable to some other variable. <SNIP> > >-- >Steven 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 | harrismh777 <harrismh777@charter.net> |
|---|---|
| Date | 2011-05-09 16:28 -0500 |
| Message-ID | <g0Zxp.23191$Vp.11316@newsfe14.iad> |
| In reply to | #4967 |
Gregory Ewing wrote:
>
> +-------------+
> +---+ | |
> a | --+---------------->| |
> +---+ | |
> +-------------+
> ^
> +---+ |
> b | --+-----------------------|
> +---+
>
> In this model, a "reference" is an arrow. Manipulating references
> consists of rubbing out the arrows and redrawing them differently.
Greg, this is an excellent model, thank you for taking the time to
put it together for the list... very helpful.
Both Summerfield and Lutz use the same model (and almost the
identical graphic symbolism) to explain dynamic typing in Python.
Summerfield's Programming in Python 3 2nd ed. has a good explanation
similar, see pages 17 and 32 (there are others). Lutz has an entire
chapter devoted to the topic in Learning Python 4th ed., see chapter
six. He calls it the Dynamic Typing Interlude.
The model is in-the-field and very workable; and yet, it does have
limitations, as most models do. For visual thinkers this model probably
comes closest to being most helpful, esp in the beginning.
kind regards,
m harris
[toc] | [prev] | [next] | [standalone]
| From | Hans Georg Schaathun <hg@schaathun.net> |
|---|---|
| Date | 2011-05-09 07:23 +0100 |
| Message-ID | <csdk98-591.ln1@svn.schaathun.net> |
| In reply to | #4894 |
On Sat, 07 May 2011 21:21:45 +1200, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: : You can manipulate them just fine by moving them : from one place to another: : : a = b : : You can use them to get at stuff they refer to: : : a = b.c : a[:] = b[:] Surely you can refer to the objects, but you cannot refer to the reference. : You can compare them: : : if a is b: : ... This could be implemented as pointer comparison, but it is not defined as such and there is no requirement that it be. : That's about all you can do with pointers in Pascal, : and I've never heard anyone argue that Pascal pointers : are any more or less abstract than any other piece of : data in that language. In Pascal a pointer is a distinct data type, and you can have variables of a given type or of type pointer to that given type. That makes the pointer a concrete concept defined by the languagedefined by the language. -- :-- Hans Georg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-05-05 15:14 +0000 |
| Message-ID | <4dc2becc$0$29991$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #4623 |
On Wed, 04 May 2011 09:18:56 -0700, Devin Jeanpierre wrote: > On May 4, 9:44 am, Hans Georg Schaathun <h...@schaathun.net> wrote: >> : The only twist is that you never get to dereference : >> pointers in Python, but you can in C. Not much of a twist if you ask : >> me, but then again, I've been thinking in thismodelfor years. Maybe : >> I'm brainwashed. :) >> >> You are. You explain Python in terms of C. That's useful when you >> talk to other speakers of C. >> >> If you want to explain the language to a broader audience, you should >> use terminology from the language's own level of abstraction. > > No, I explained Python in terms of pointers/reference. Python has no pointers or references unless you simulate them yourself using other data types. They exist as implementation details of the Python virtual machine, which is at least two levels below that of Python code. The first is the byte code which runs in the virtual machine; the second is the code in the VM. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | harrismh777 <harrismh777@charter.net> |
|---|---|
| Date | 2011-05-04 14:22 -0500 |
| Message-ID | <3Ihwp.18043$Ot6.11759@newsfe15.iad> |
| In reply to | #4613 |
Hans Georg Schaathun wrote:
> It only works by assuming
> knowledge of C, which is language which has proved unsuitable for
> complex and abstract data modelling.
That statement is untrue; evidenced by the very fact the CPython's
complex and abstract data modeling has been very suitably handled by C.
You cannot possibly mean what you have asserted... I realize there
must be a contextual problem. I have been handling complex data
abstractions with C for more than 20 years... its quite well suited to
the task... although, I am able to do my research today faster and with
less lines of code in CPython. That does not in any way impugn C..;.
quite the contrary, given enough time, C is better suited for modeling
on a von Neumann processor, period.
Here is the thing that everyone forgets... all we have to work with
is a von Neumann processor. (same as EDVAC, ENIAC, the VIC20, etc).
Assembler is still the best language on that processor. 'C' is still
the best high-level language on that processor. CPython is implemented
in C for a reason: gcc and the von Neumann processor make it a no-brainer.
Its silly to claim that one high-level language or another is better
suited to complex data abstraction... don't go there.
> Digging down into C should be unnecessary to explain Python.
huh? You have to be kidding. Why do you suppose we want it to be
open-sourced? Use the force Luke, read the source. If you really
want to know how Python is working you *must* dig down into the C code
which implements it. The folks who document Python should be able to
tell us enough to know how to use the language, but to really 'know' you
need the implementation source.
kind regards,
m harris
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Kaplan <benjamin.kaplan@case.edu> |
|---|---|
| Date | 2011-05-04 15:46 -0400 |
| Message-ID | <mailman.1169.1304538384.9059.python-list@python.org> |
| In reply to | #4649 |
On Wed, May 4, 2011 at 3:22 PM, harrismh777 <harrismh777@charter.net> wrote: > Hans Georg Schaathun wrote: >> >> It only works by assuming >> knowledge of C, which is language which has proved unsuitable for >> complex and abstract data modelling. > > That statement is untrue; evidenced by the very fact the CPython's complex > and abstract data modeling has been very suitably handled by C. > You cannot possibly mean what you have asserted... I realize there must be > a contextual problem. I have been handling complex data abstractions with C > for more than 20 years... its quite well suited to the task... although, I > am able to do my research today faster and with less lines of code in > CPython. That does not in any way impugn C..;. quite the contrary, given > enough time, C is better suited for modeling on a von Neumann processor, > period. > > Here is the thing that everyone forgets... all we have to work with is a > von Neumann processor. (same as EDVAC, ENIAC, the VIC20, etc). Assembler is > still the best language on that processor. 'C' is still the best > high-level language on that processor. CPython is implemented in C for a > reason: gcc and the von Neumann processor make it a no-brainer. > CPython is implemented in C because that's the language chosen. Python is also implemented in Java, C#, Python, and several other languages. And it's not tied to the von Neumann architecture either. Only the current implementations of it are. > Its silly to claim that one high-level language or another is better > suited to complex data abstraction... don't go there. > > >> Digging down into C should be unnecessary to explain Python. > > > huh? You have to be kidding. Why do you suppose we want it to be > open-sourced? Use the force Luke, read the source. If you really want to > know how Python is working you *must* dig down into the C code which > implements it. The folks who document Python should be able to tell us > enough to know how to use the language, but to really 'know' you need the > implementation source. > Reading the CPython sources will show you how CPython works under the hood, but it has nothing to do with how Python works. There are lots of things that CPython does that "Python" does not. For instance, the GIL is not a part of Python. Reference counting is not a part of Python. Caching small integers and strings is not a part of Python. Why not read the Jython sources instead of the CPython? It's the same language, after all.
[toc] | [prev] | [next] | [standalone]
| From | harrismh777 <harrismh777@charter.net> |
|---|---|
| Date | 2011-05-04 14:58 -0500 |
| Message-ID | <Odiwp.31506$8U5.30629@newsfe20.iad> |
| In reply to | #4654 |
Benjamin Kaplan wrote:
> CPython is implemented in C because that's the language chosen. Python
> is also implemented in Java, C#, Python, and several other languages.
True enough. If I used Jython, I would want to take a look at those
sources... as well as the Java sources... which were wrtten in, um, C.
> And it's not tied to the von Neumann architecture either. Only the
> current implementations of it are.
Oh, yes they are. That is the $10,000,000 dollar problem... how to
extricate ourselves from the von Neumann processor. *Everthing* comes
down to that... its hilarious to hear folks talk about lambda the
ultimate (especially those guys on Lambda the Ultimate) when there is no
such thing until such time as we have lambda the hardware architecture.
As long as we are all constrained to funnel data through the von
Neumann ALU, that really is *all* that matters. Another way of saying
this is that no matter how sophisticated our high level coding gets, it
all has to be translated somehow one way or another into von Neumann
codes toggling 1's and 0's on and off in the registers of the von
Neumann ALU.
> Reading the CPython sources will show you how CPython works under the
> hood, but it has nothing to do with how Python works.
Not conceptually, but practically. For instance, for a C programmer
to see that Python's object references are C void pointers, tells the
newbie Python ( C programmer ) much about how Python considers
variables... as references... to objects.
> There are lots
> of things that CPython does that "Python" does not. For instance, the
> GIL is not a part of Python. Reference counting is not a part of
> Python. Caching small integers and strings is not a part of Python.
This is not something I was aware of... caching of small ints is
unique to CPython implementation only ?? I guess I'll have to go read
the "sources" of the other implementations to check that out... ;-)
> Why not read the Jython sources instead of the CPython? It's the same
> language, after all.
Yep. Agreed. .... on both counts.
[toc] | [prev] | [next] | [standalone]
| From | Hans Georg Schaathun <hg@schaathun.net> |
|---|---|
| Date | 2011-05-04 21:40 +0100 |
| Message-ID | <b7q898-pql.ln1@svn.schaathun.net> |
| In reply to | #4656 |
On Wed, 04 May 2011 14:58:38 -0500, harrismh777 <harrismh777@charter.net> wrote: : True enough. If I used Jython, I would want to take a look at those : sources... as well as the Java sources... which were wrtten in, um, C. And then, suddenly, you'll be developing code which fails on CPython instead of code which fails on Jython. Except that it will still fail on Jython too, unless you happen to have the right jvm. Marvelous. : Oh, yes they are. That is the $10,000,000 dollar problem... how to : extricate ourselves from the von Neumann processor. *Everthing* comes : down to that... its hilarious to hear folks talk about lambda the : ultimate (especially those guys on Lambda the Ultimate) when there is no : such thing until such time as we have lambda the hardware architecture. The problem with your approach is that software development does not scale. Assembly worked very well with a few 100 lines of codes half a century ago. C and friends were a great step forward and reduced the complexity to allow another magnitude of lines of codes. Then came further languages further removed from von Neumann, but close enough to human cognition to handle yet a magnitude or too. Of course you can still gain useful understanding by studying assembly or von Neumann, or the instruction set of the CPU you use. And in some projects it may be an optimal strategy. However, there are many skills necessary to make an efficient system and in many projects assembly and hardware skills are far down the list. Virtualisation is there to the cut costs of rethinking solutions for multiple architectures. If you need to understand the implementation to do your programming, you are in fact disregarding one of the most significant achievements deployed in computing the last two decades. : Not conceptually, but practically. For instance, for a C programmer : to see that Python's object references are C void pointers, tells the : newbie Python ( C programmer ) much about how Python considers : variables... as references... to objects. And of course, this is useful as /one/ way to consider python variables. As long as one is aware that this is just an example, one approach out of many, then it enhances understanding. If one blindly extrapolates from one implementation, it enhances misunderstanding. -- :-- Hans Georg
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2011-05-05 21:31 +1200 |
| Message-ID | <92f94aFploU1@mid.individual.net> |
| In reply to | #4656 |
harrismh777 wrote: > That is the $10,000,000 dollar problem... how to > extricate ourselves from the von Neumann processor. *Everthing* comes > down to that... its hilarious to hear folks talk about lambda the > ultimate (especially those guys on Lambda the Ultimate) when there is no > such thing until such time as we have lambda the hardware architecture. I think there are fundamental problems that go beyond the issue of hardware design. It's easy to reason about a program that does things one step at a time, much harder when lots of things are happening at once. Whether you express the program using lambda calculus or a Turing machine doesn't change that fact. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2011-05-05 14:50 +0000 |
| Message-ID | <4dc2b93c$0$29991$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #4656 |
On Wed, 04 May 2011 14:58:38 -0500, harrismh777 wrote: > Benjamin Kaplan wrote: >> CPython is implemented in C because that's the language chosen. Python >> is also implemented in Java, C#, Python, and several other languages. > > True enough. If I used Jython, I would want to take a look at those > sources... as well as the Java sources... which were wrtten in, um, C. No, Java sources are written in Java. That's why they're *Java* sources. Perhaps you mean that the Java compiler is written in C? Highly unlikely: Java compilers have been self-hosting for many years now. http://en.wikipedia.org/wiki/Self-hosting -- Steven
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.python
csiph-web