Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #47701 > unrolled thread
| Started by | Νικόλαος Κούρας <nikos.gr33k@gmail.com> |
|---|---|
| First post | 2013-06-11 13:20 -0700 |
| Last post | 2013-06-14 15:31 +0300 |
| Articles | 20 on this page of 171 — 44 participants |
Back to article view | Back to comp.lang.python
A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <nikos.gr33k@gmail.com> - 2013-06-11 13:20 -0700
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-11 23:14 +0100
Re: A certainl part of an if() structure never gets executed. MRAB <python@mrabarnett.plus.com> - 2013-06-11 23:43 +0100
Re: A certainl part of an if() structure never gets executed. nagia.retsina@gmail.com - 2013-06-11 18:25 -0700
Re: A certainl part of an if() structure never gets executed. Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 18:46 -0700
Re: A certainl part of an if() structure never gets executed. alex23 <wuwei23@gmail.com> - 2013-06-11 18:57 -0700
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-12 12:05 +1000
Re: A certainl part of an if() structure never gets executed. alex23 <wuwei23@gmail.com> - 2013-06-11 19:14 -0700
Re: A certainl part of an if() structure never gets executed. Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 20:37 -0700
Re: A certainl part of an if() structure never gets executed. Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 20:50 -0700
Re: A certainl part of an if() structure never gets executed. Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2013-06-26 11:07 +0200
Re: A certainl part of an if() structure never gets executed. MRAB <python@mrabarnett.plus.com> - 2013-06-12 02:50 +0100
Re: A certainl part of an if() structure never gets executed. Cameron Simpson <cs@zip.com.au> - 2013-06-12 12:00 +1000
Re: A certainl part of an if() structure never gets executed. Rick Johnson <rantingrickjohnson@gmail.com> - 2013-06-11 15:48 -0700
Re: A certainl part of an if() structure never gets executed. alex23 <wuwei23@gmail.com> - 2013-06-11 16:45 -0700
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-11 22:49 -0600
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 07:45 +0000
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-12 17:55 +1000
Re: A certainl part of an if() structure never gets executed. Neil Cerutti <neilc@norwich.edu> - 2013-06-12 13:05 +0000
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-12 15:37 +0100
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-11 23:05 -0600
Re: A certainl part of an if() structure never gets executed. Tim Roberts <timr@probo.com> - 2013-06-11 22:44 -0700
Re: A certainl part of an if() structure never gets executed. alex23 <wuwei23@gmail.com> - 2013-06-11 23:16 -0700
Re: A certainl part of an if() structure never gets executed. Grant Edwards <invalid@invalid.invalid> - 2013-06-12 14:38 +0000
Re: A certainl part of an if() structure never gets executed. Neil Cerutti <neilc@norwich.edu> - 2013-06-12 14:55 +0000
Re: A certainl part of an if() structure never gets executed. Zero Piraeus <schesis@gmail.com> - 2013-06-12 11:20 -0400
Re: A certainl part of an if() structure never gets executed. rusi <rustompmody@gmail.com> - 2013-06-13 05:30 -0700
Re: A certainl part of an if() structure never gets executed. Roy Smith <roy@panix.com> - 2013-06-13 09:01 -0400
Re: A certainl part of an if() structure never gets executed. Neil Cerutti <neilc@norwich.edu> - 2013-06-13 12:34 +0000
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 20:00 +0300
Re: A certainl part of an if() structure never gets executed. Jan Riechers <janpeterr@freenet.de> - 2013-06-19 01:05 +0300
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-12 08:27 +0000
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 11:54 +0300
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-12 10:07 +0100
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 12:19 +0300
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-12 10:57 +0100
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 13:45 +0300
Re: A certainl part of an if() structure never gets executed. Andreas Perstinger <andipersti@gmail.com> - 2013-06-12 12:07 +0200
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 13:59 +0300
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 14:03 +0300
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-12 12:49 +0100
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 15:39 +0300
Re: A certainl part of an if() structure never gets executed. feedthetroll@gmx.de - 2013-06-12 04:07 -0700
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 06:15 +1000
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 14:17 +0300
Re: A certainl part of an if() structure never gets executed. MRAB <python@mrabarnett.plus.com> - 2013-06-12 17:40 +0100
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 20:13 +0300
Re: A certainl part of an if() structure never gets executed. MRAB <python@mrabarnett.plus.com> - 2013-06-12 18:53 +0100
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 21:06 +0300
Re: A certainl part of an if() structure never gets executed. Sibylle Koczian <nulla.epistola@web.de> - 2013-06-12 21:48 +0200
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-12 23:00 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 06:16 +1000
Re: A certainl part of an if() structure never gets executed. Sibylle Koczian <nulla.epistola@web.de> - 2013-06-12 23:16 +0200
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 17:47 +0300
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-13 01:55 +0000
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 12:03 +1000
Re: A certainl part of an if() structure never gets executed. Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2013-06-13 10:05 +0530
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-13 14:39 +1000
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 08:36 +0300
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 10:11 +0300
Re: A certainl part of an if() structure never gets executed. Sibylle Koczian <nulla.epistola@web.de> - 2013-06-13 14:22 +0200
Re: A certainl part of an if() structure never gets executed. Νικόλαος Κούρας <support@superhost.gr> - 2013-06-13 17:26 +0300
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 01:14 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:03 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:23 +1000
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-14 09:24 +0100
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 11:28 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:41 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:50 +1000
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 10:03 +0100
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 12:21 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:44 +0300
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 15:40 +0300
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 16:07 +0300
Re: A certainl part of an if() structure never gets executed. Zero Piraeus <schesis@gmail.com> - 2013-06-14 09:48 -0400
Re: A certainl part of an if() structure never gets executed. rusi <rustompmody@gmail.com> - 2013-06-14 07:05 -0700
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 17:08 +0300
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 16:31 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 19:56 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:18 +1000
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 21:17 +0300
Re: A certainl part of an if() structure never gets executed. Larry Hudson <orgnut@yahoo.com> - 2013-06-14 22:27 -0700
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 11:39 +0300
Re: A certainl part of an if() structure never gets executed. Lele Gaifax <lele@metapensiero.it> - 2013-06-15 11:54 +0200
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 16:07 +0300
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-15 09:53 -0600
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-15 19:18 +0300
Re: A certainl part of an if() structure never gets executed. Michael Torrie <torriem@gmail.com> - 2013-06-15 11:45 -0600
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 06:32 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 11:07 +0300
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 09:22 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 12:59 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 11:42 +0100
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 14:06 +0300
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-16 12:26 +0100
Re: A certainl part of an if() structure never gets executed. YBM <ybmess@nooos.fr.invalid> - 2013-06-16 14:00 +0200
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 13:04 +0100
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 16:38 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 19:50 +0100
Re: A certainl part of an if() structure never gets executed. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-06-16 11:52 +0100
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-16 10:51 +0000
Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 12:07 +0000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Mark Janssen <dreamingforward@gmail.com> - 2013-06-16 12:31 -0700
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 20:02 +0000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Chris Angelico <rosuav@gmail.com> - 2013-06-17 08:26 +1000
Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-16 23:13 -0400
Re: A certainl part of an if() structure never gets executed. Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-16 14:13 +0300
Re: A certainl part of an if() structure never gets executed. Ferrous Cranus <support@superhost.gr> - 2013-06-16 16:47 +0300
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-16 19:53 +0100
Re: A certainl part of an if() structure never gets executed. Νίκος <support@superhost.gr> - 2013-06-17 08:17 +0300
Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-17 06:51 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 14:34 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-17 05:58 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 18:50 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Larry Hudson <orgnut@yahoo.com> - 2013-06-17 23:39 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 07:24 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 11:49 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 09:05 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 12:51 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Chris Angelico <rosuav@gmail.com> - 2013-06-18 20:22 +1000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-19 23:16 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-20 05:48 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-20 00:01 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] 88888 Dihedral <dihedral88888@gmail.com> - 2013-06-26 01:18 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Michael Torrie <torriem@gmail.com> - 2013-06-19 23:44 -0600
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Roel Schroeven <roel@roelschroeven.net> - 2013-06-20 19:19 +0200
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Terry Reedy <tjreedy@udel.edu> - 2013-06-17 10:22 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Simpleton <support@superhost.gr> - 2013-06-17 18:55 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Joel Goldstick <joel.goldstick@gmail.com> - 2013-06-17 12:26 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-06-17 09:23 -0700
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-17 20:17 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Terry Reedy <tjreedy@udel.edu> - 2013-06-17 18:16 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-17 23:09 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Νίκος <support@superhost.gr> - 2013-06-18 02:26 +0300
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 00:41 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dave Angel <davea@davea.name> - 2013-06-17 21:06 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:42 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dave Angel <davea@davea.name> - 2013-06-18 00:12 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 06:04 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:38 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-18 02:46 +0000
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-17 21:34 -0400
Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] Marcin Szamotulski <mszamot@gmail.com> - 2013-06-18 04:22 +0100
Re: A certainl part of an if() structure never gets executed. Michael Weylandt <michael.weylandt@gmail.com> - 2013-06-17 07:56 +0100
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 12:50 +0000
OT: C vs Python terminology (was: A certainl part of an if() structure never gets executed) Andreas Perstinger <andipersti@gmail.com> - 2013-06-16 13:22 +0200
Re: OT: C vs Python terminology Dave Angel <davea@davea.name> - 2013-06-16 08:55 -0400
Re: OT: C vs Python terminology Andreas Perstinger <andipersti@gmail.com> - 2013-06-16 17:02 +0200
Re: OT: C vs Python terminology Dave Angel <davea@davea.name> - 2013-06-16 21:58 -0400
Re: A certainl part of an if() structure never gets executed. "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-06-14 09:28 +0100
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 09:35 +0100
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 11:44 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 18:57 +1000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:00 +0300
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-14 19:12 +1000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:47 +0300
Re: A certainl part of an if() structure never gets executed. Tim Roberts <timr@probo.com> - 2013-06-15 18:55 -0700
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 05:09 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-16 11:20 +0300
Re: A certainl part of an if() structure never gets executed. Tim Roberts <timr@probo.com> - 2013-06-18 22:08 -0700
Re: A certainl part of an if() structure never gets executed. Dave Angel <davea@davea.name> - 2013-06-19 01:42 -0400
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 17:14 +1000
Re: A certainl part of an if() structure never gets executed. Νίκος <support@superhost.gr> - 2013-06-19 10:49 +0300
Re: A certainl part of an if() structure never gets executed. Dave Angel <davea@davea.name> - 2013-06-19 04:06 -0400
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 18:21 +1000
Re: A certainl part of an if() structure never gets executed. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-19 08:55 +0000
Re: A certainl part of an if() structure never gets executed. Chris Angelico <rosuav@gmail.com> - 2013-06-19 19:14 +1000
Re: A certainl part of an if() structure never gets executed. Grant Edwards <invalid@invalid.invalid> - 2013-06-14 14:38 +0000
Re: A certainl part of an if() structure never gets executed. Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 10:05 +0100
Re: A certainl part of an if() structure never gets executed. Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-14 12:03 +0000
Re: A certainl part of an if() structure never gets executed. Nick the Gr33k <support@superhost.gr> - 2013-06-14 15:31 +0300
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-06-16 10:51 +0000 |
| Message-ID | <kpk5bj$ifk$1@dont-email.me> |
| In reply to | #48427 |
On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote: > Whats the difference of "interpreting " to "compiling" ? OK, I give up! -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 12:07 +0000 |
| Subject | Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bdaa78$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48432 |
On Sun, 16 Jun 2013 10:51:31 +0000, Denis McMahon wrote: > On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote: > >> Whats the difference of "interpreting " to "compiling" ? > > OK, I give up! Actually, that's a more subtle question than most people think. Python, for example, is a compiled language. (What did you think the "c" in ".pyc" files stood for? and the compile() function>?) It is compiled to byte-code, which runs on a virtual machine, rather than machine-code, which runs on a physical machine. Except PyPy, which *is* compiled to machine-code. Except that it doesn't do so at compile time, but on the fly at run-time. And these days, for many types of hardware, even machine-code is often interpreted by a virtual machine on a chip. And even languages which compile to machine-code often use an intermediate platform-independent form rather than targeting pure machine-code. The line between compilers and interpreters is quite fuzzy. Probably the best definition I've seen for the difference between a modern compiler and interpreter is this one: "...the distinguishing feature of interpreted languages is not that they are not compiled, but that the compiler is part of the language runtime and that, therefore, it is possible (and easy) to execute code generated on the fly." -- Roberto Ierusalimschy, "Programming In Lua", 2nd Edition, p. 63 -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-06-16 12:31 -0700 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3453.1371411127.3114.python-list@python.org> |
| In reply to | #48444 |
>>> Whats the difference of "interpreting " to "compiling" ? >> >> OK, I give up! > > Actually, that's a more subtle question than most people think. Python, > for example, is a compiled language. (What did you think the "c" in > ".pyc" files stood for? and the compile() function>?) Careful there. This terminology is not agreed upon universally (that is, within the realm of academia where the notion of mastery exists), and unless you are citing an actual reference or publishing one yourself, then you may be adding more confusion than illumination. For example, I would say that it is an *interpreted language* that gets compiled at run-time. Some (*valid*) definitions of "compiler" mean a strict mapping from the language syntax and lexical definition to a sequence of bytes that can be fed to a (hardware not virtual) machine architecture to do perform what is requested. The face that an extension ends in the letter "c" is not sufficient evidence, since file extensions have no strict standard. > And these days, for many types of hardware, even machine-code is often > interpreted by a virtual machine on a chip. And even languages which > compile to machine-code often use an intermediate platform-independent > form rather than targeting pure machine-code. Do you have a reference for this? What language? > The line between compilers > and interpreters is quite fuzzy. It shouldn't be. What is fuzzy is the definition of "interpreter", however. The definition of compiler has only become fuzzy with the advent of the personal computer. > Probably the best definition I've seen for the difference between a > modern compiler and interpreter is this one: > > "...the distinguishing feature of interpreted languages is not that they > are not compiled, but that the compiler is part of the language runtime > and that, therefore, it is possible (and easy) to execute code generated > on the fly." That's reasonable. -- MarkJ Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 20:02 +0000 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51be19f1$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48471 |
On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote: >>>> Whats the difference of "interpreting " to "compiling" ? >>> >>> OK, I give up! >> >> Actually, that's a more subtle question than most people think. Python, >> for example, is a compiled language. (What did you think the "c" in >> ".pyc" files stood for? and the compile() function>?) > > Careful there. This terminology is not agreed upon universally Which is why I said it was a more subtle question than most people think. Most people think that there is One True Definition of compiling/ interpreting, usually based on an over-simplified model of program execution that was obsolete in the 1970s. > (that > is, within the realm of academia where the notion of mastery exists), The notion of mastery exists in many places, not just academia. > and unless you are citing an actual reference or publishing one > yourself, then you may be adding more confusion than illumination. For > example, I would say that it is an *interpreted language* that gets > compiled at run-time. Apart from the contradiction there -- if it is compiled, why do you insist on calling it interpreted? -- you would be wrong. Languages are neither interpreted nor compiled. Languages are abstract entities that describe what syntax is permitted, and what functionality is provided. It is only concrete implementations which are interpreted or compiled. In the case of Python, we have: CPython: compiled to byte-code for it's own virtual machine; Jython: compiled to byte-code for the JRE; IronPython: compiled to byte-code for the .Net runtime; PyPy: JIT compiler that generates machine code; Nuitka: static compiler that generates machine code; etc. So, the answer to the question "Is Python compiled or interpreted?" is, "Yes." [...] >> And these days, for many types of hardware, even machine-code is often >> interpreted by a virtual machine on a chip. And even languages which >> compile to machine-code often use an intermediate platform-independent >> form rather than targeting pure machine-code. > > Do you have a reference for this? What language? https://en.wikipedia.org/wiki/Microcode >> The line between compilers >> and interpreters is quite fuzzy. > > It shouldn't be. Of course it should be, because that reflects reality. > What is fuzzy is the definition of "interpreter", > however. The definition of compiler has only become fuzzy with the > advent of the personal computer. Incorrect. Lisp predates the PC, and it is a good example of a language with implementations which combine features of compile-to-machine-code and execute-high-level-code-at-run-time (i.e. both "compiler" and "interpreter" behaviour, at the same time). Lisp is nearly as old as Fortran. Forth is another such language. It's not quite so old as Lisp, but it is especially interesting because Forth includes commands to switch from "compile mode" to "interpret mode" on the fly. So is it a compiler or an interpreter? Yes. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-17 08:26 +1000 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3463.1371421585.3114.python-list@python.org> |
| In reply to | #48476 |
On Mon, Jun 17, 2013 at 6:02 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote: >>> The line between compilers >>> and interpreters is quite fuzzy. >> >> It shouldn't be. > > Of course it should be, because that reflects reality. It's fuzzy AND it seldom even matters. Compare these three text strings: """'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'"""" """'a'*64""" """\37\213\b\b*8\276Q\0\3test\0KL\244\f\0\0Ue\264\211@\0\0\0""" """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" Which of these is an interpreted program? I would say: All of them. And they all produce the same output, a series of 64 copies of the letter a. The third one is interpreted by gzip(1) and will create a file called 'test', the fourth is a raw gzip/zlib stream and so is interpreted by (eg) the Python zlib.decompress() function. They're all languages, of a sort. Are they interpreted/compiled versions of that message? Kinda. If you prepend a sfx header to them, do they become compiled and not interpreted? Doubtful. I don't think you could say that this ceases to be interpreted: import zlib print(zlib.decompress( """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" )) Even if you manually imported the code for zlib.decompress, in a way that makes it impossible for your cut-down program to actually compress data (which then breaks the principle quoted from "Programming in Lua"), it's still fairly clearly being interpreted/parsed the exact same way. So it really doesn't matter (so it really doesn't matter (so it really doesn't matter)). [1] ChrisA [1] http://math.boisestate.edu/gas/ruddigore/web_opera/rudd24.html
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-06-16 23:13 -0400 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3467.1371438818.3114.python-list@python.org> |
| In reply to | #48444 |
On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen
<dreamingforward@gmail.com> declaimed the following:
>Careful there. This terminology is not agreed upon universally (that
>is, within the realm of academia where the notion of mastery exists),
>and unless you are citing an actual reference or publishing one
>yourself, then you may be adding more confusion than illumination.
>For example, I would say that it is an *interpreted language* that
>gets compiled at run-time. Some (*valid*) definitions of "compiler"
>mean a strict mapping from the language syntax and lexical definition
>to a sequence of bytes that can be fed to a (hardware not virtual)
>machine architecture to do perform what is requested. The face that
>an extension ends in the letter "c" is not sufficient evidence, since
>file extensions have no strict standard.
>
And I'd tend to consider it a Byte-Code Interpreted language (a la UCSD
P-code Pascal). I also consider standard Java to be such.
In contrast, I consider "compiled" to mean the end result of the
compilation step is native instruction set for the processor. And true
"interpreted" is more like classic BASIC (which /tokenized/ the program but
the tokens mapped 1:1 with the source keywords. Tokenization saved a few
bytes as "while" and "for" condensed to single bytes -- but then needed
long subroutines at run time to actually process them.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2013-06-16 14:13 +0300 |
| Message-ID | <qot8v2al34n.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #48427 |
Nick the Gr33k writes: > On 16/6/2013 12:22 μμ, Denis McMahon wrote: > > For example, in Python > > > > a = 6 > > b = a > > c = 6 > > > > a and b point to one memory location that contains the value 6 > > c points to a different memory location that contains the value 6 > > I believe you are mistaken. > > a here is not a pointer but variable, > which is a memory location that stores value 6. > > b here is a pointer. It's value is the memory location of variable a > which stores value 6. > > c here is just te same as a , a variable. b is also just like a. All the talk about pointers and memory locations is intended to explain how things do or do not change. (Or, sometimes, how the behaviour is implemented.) If, instead of the above, you have a = 6 b = a b = 5 you will find that b == 5 and a == 6. So b is not the same as a. Else one would have changed when the other changed. I would say that a and b are different variables. They had the same value, briefly. What does same mean? Think of mutable objects. A dictionary, for example: a = dict(x = 3) b = a b.update(x = 31) You will find that the value of a changed when the value of b changed. It's the same value. Values do not get copied in Python when you pass them around. This is implemented with pointers and memory locations, but in Python these implementation details are normally hidden behind the scenes. Python is far from unique in this regard.
[toc] | [prev] | [next] | [standalone]
| From | Ferrous Cranus <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 16:47 +0300 |
| Message-ID | <kpkfm2$f6p$2@news.ntua.gr> |
| In reply to | #48438 |
On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: > If, instead of the above, you have > > a = 6 > b = a > b = 5 > > you will find that b == 5 and a == 6. So b is not the same as a. Else > one would have changed when the other changed. I would say that a and > b are different variables. They had the same value, briefly. If they were different variables then they would have different memory addresses and they would act like two different objects. But... both a and b are for a fact mappings for the same memory address as seen form the following command. >>> id(a) == id(b) True They are like the same object with 2 different names. Like i'am a human being and me Greek friends call me "Νίκος" while you guys call me "Nick". That the way i understand it so far. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | "R. Michael Weylandt" <michael.weylandt@gmail.com> |
|---|---|
| Date | 2013-06-16 19:53 +0100 |
| Message-ID | <mailman.3451.1371408858.3114.python-list@python.org> |
| In reply to | #48452 |
On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <support@superhost.gr> wrote: > On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: >> >> If, instead of the above, you have >> >> a = 6 >> b = a >> b = 5 >> >> you will find that b == 5 and a == 6. So b is not the same as a. Else >> one would have changed when the other changed. I would say that a and >> b are different variables. They had the same value, briefly. > > > If they were different variables then they would have different memory > addresses and they would act like two different objects. > > But... both a and b are for a fact mappings for the same memory address as > seen form the following command. > >>>> id(a) == id(b) > True > > They are like the same object with 2 different names. This will depend on when the test is run: a = 6 b = a a is b # True b = 5 a is b # False The latter is false because the binding of "b" to the int 6 was broken in order to bind b to the int 5. I might also suggest you restrain from trying to correct respondents on these matters until you yourself understand them. It's only polite. Michael
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 08:17 +0300 |
| Message-ID | <kpm65s$250s$2@news.ntua.gr> |
| In reply to | #48467 |
On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote: > On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <support@superhost.gr> wrote: >> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: >>> >>> If, instead of the above, you have >>> >>> a = 6 >>> b = a >>> b = 5 >>> >>> you will find that b == 5 and a == 6. So b is not the same as a. Else >>> one would have changed when the other changed. I would say that a and >>> b are different variables. They had the same value, briefly. >> >> >> If they were different variables then they would have different memory >> addresses and they would act like two different objects. >> >> But... both a and b are for a fact mappings for the same memory address as >> seen form the following command. >> >>>>> id(a) == id(b) >> True >> >> They are like the same object with 2 different names. > > This will depend on when the test is run: > > a = 6 > b = a > a is b # True > > b = 5 > a is b # False > > The latter is false because the binding of "b" to the int 6 was broken > in order to bind b to the int 5. Very surprising. a and b was *references* to the same memory address, it was like a memory address having 2 names to be addresses as. b = a name we use to address some memory location, do we agree on that? So, b = 6, must have changed the stored value of its mapped memory location, but given you example it seems its changing the mapping of b to some other memory address. I don't follow its act of course. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-17 06:51 +0000 |
| Subject | Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51beb20c$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48493 |
On Mon, 17 Jun 2013 08:17:48 +0300, Νίκος wrote:
[...]
>> The latter is false because the binding of "b" to the int 6 was broken
>> in order to bind b to the int 5.
>
> Very surprising.
> a and b was *references* to the same memory address, it was like a
> memory address having 2 names to be addresses as.
>
> b = a name we use to address some memory location, do we agree on that?
>
> So, b = 6, must have changed the stored value of its mapped memory
> location, but given you example it seems its changing the mapping of b
> to some other memory address.
>
> I don't follow its act of course.
Let me explain how variables work in some other languages, and how they
work in Python. (And Ruby, and Java, and many others.)
In a language like Pascal, or C, the compiler keeps a table mapping
variable names to fixed memory addresses, like this:
Variable Address
======== =======
x 10234
y 10238
z 10242
Code like:
x := 42;
y := x + 1;
will get compiled into something that looks like this:
# Pseudo-code
STORE 42 AT ADDRESS 10234;
READ ADDRESS 10234;
STORE (LAST RESULT + 1) AT ADDRESS 10238;
The important thing is that memory addresses are known at compile time,
and at least in general, variables cannot move around in memory. Another
important thing is that assignment is copying:
x := y;
becomes:
READ ADDRESS 10234;
STORE (LAST RESULT) AT ADDRESS 10238;
which is equivalent to:
COPY ADDRESS 10234 TO ADDRESS 10238;
If, instead of an integer, x was an array of 1000 integers, all 1000
integers would need to be copied.
Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:
global namespace:
x --> 23
y --> "hello world"
In Python, namespaces are *dicts*, just like those you create with {}.
Code like:
x = 42
y = x + 1
is treated as:
# Pseudocode
create the object 42
bind it to the name 'x'
look up the name 'x'
add 1 to it
bind it to the name 'y'
where "bind" means to change the association in the namespace:
global namespace:
x --> 42
y --> 43
One important thing is that binding does *not* make a copy of the object.
Assignment is equally fast whether you have one int or a list or a
million ints. So code like this:
x = y
results in both names 'x' and 'y' being associated to the same object.
With ints, that's pretty boring, but for mutable objects like lists, it
means that you get two names for the same list:
py> x = []
py> y = x
py> y.append("Surprise!")
py> x
['Surprise!']
This sort of behaviour is trivial in languages with name-binding
semantics, like Python, but quite tricky in languages like Pascal. You
have to explicitly work with pointers or other indirect memory access,
leading to extra effort and the possibility of serious bugs.
Note also that because you aren't dealing with fixed memory addresses,
objects are free to be moved in memory for better memory usage and less
fragmentation. CPython doesn't do this, but PyPy does, and I expect that
both Jython and IronPython probably do too. So long as the runtime
environment can (somehow) track when objects are moved, it all works out
fine.
Another difference is that in C-like languages, variables always have a
value, even if it's not a useful value. As soon as the compiler decides
that variable 'z' will be at address 10242, then 'z' has an implied value
made up of whatever junk happens to be at that address. Some compilers
will warn you if you try to use a variable without assigning to it first,
since using junk you happen to find lying around in memory is usually a
bad thing, but not all compilers.
In contrast, Python doesn't have this issue. If you haven't assigned to
'z', then there is no such thing as 'z' in your namespace, and trying to
use it will automatically give you an error:
py> x = z - 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'z' is not defined
There are other differences in regards to passing arguments to functions.
I've written about that before:
http://mail.python.org/pipermail/tutor/2010-December/080505.html
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Simpleton <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 14:34 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpms91$20d$2@news.ntua.gr> |
| In reply to | #48500 |
On 17/6/2013 9:51 πμ, Steven D'Aprano wrote: > Now, in languages like Python, Ruby, Java, and many others, there is no > table of memory addresses. Instead, there is a namespace, which is an > association between some name and some value: > > global namespace: > x --> 23 > y --> "hello world" First of all thanks for the excellent and detailed explanation Steven. As for namespace: a = 5 1. a is associated to some memory location 2. the latter holds value 5 So 'a', is a reference to that memory location, so its more like a name to that memory location, yes? Instead of accessing a memory address with a use of an integer like "14858485995" we use 'a' instead. So is it safe to say that in Python a == &a ? (& stands for memory address) is the above correct? I say this because here you said that: Instead, there is a namespace, which is anassociation between some name and some value: When you say that you mean that a is associated to some value as in memory location or to that memory location's address? -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-17 05:58 -0600 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3479.1371470335.3114.python-list@python.org> |
| In reply to | #48514 |
On 06/17/2013 05:34 AM, Simpleton wrote: > So is it safe to say that in Python a == &a ? (& stands for memory address) > > is the above correct? It might be partially equivalent inside the interpreter, but it's not something you should concern yourself with. And in general, no it's not safe to say, since Python is a reference-counted, garbage-collected object system and pointers in C certainly are not. > I say this because here you said that: Instead, there is a namespace, > which is anassociation between some name and some value: > > When you say that you mean that a is associated to some value as in > memory location or to that memory location's address? In python just think of assignment as making a name *be* an object. And if you assign one name to another name, that makes both names be the same object. When names are unbound (either they go out of scope or you manually unbind them), the objects they are bound to are garbage collected. Forget about the details of how the interpreter might doing at a low level.
[toc] | [prev] | [next] | [standalone]
| From | Simpleton <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 18:50 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpnb7t$k63$1@news.ntua.gr> |
| In reply to | #48516 |
On 17/6/2013 2:58 μμ, Michael Torrie wrote: > In python just think of assignment as making a name *be* an object. And > if you assign one name to another name, that makes both names be the > same object. When names are unbound (either they go out of scope or you > manually unbind them), the objects they are bound to are garbage collected. "Object" here being the memory location, right? When we say a = 5 a = an easy way for calling that "fixed memory location" that holds our value, instead of calling it in binary format or in hex format. This is the direct object a is pointing too. Correct? 5 = *this* is the indirect object that a outputs when we print a. Are the above statements correct Michael? a = 5 b = a a <---> memory address b <---> memory address I like to think a and b as references to the same memory address -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Larry Hudson <orgnut@yahoo.com> |
|---|---|
| Date | 2013-06-17 23:39 -0700 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <HdmdncUNJIsSnV3MnZ2dnUVZ_oGdnZ2d@giganews.com> |
| In reply to | #48526 |
On 06/17/2013 08:50 AM, Simpleton wrote: > On 17/6/2013 2:58 μμ, Michael Torrie wrote: > > a = 5 > b = a > > a <---> memory address > b <---> memory address > > I like to think a and b as references to the same memory address > Not quite: a and b _are_ memory addresses, At the same time, a and b are references to the data (the objects) stored in those memory locations. The distinction is probably more important in languages like C/C++, where the _language_ gives you direct access to, and can manipulate, these memory addresses (through pointers). Python handles it differently and does not give you this sort of ability, it all occurs "under the hood". Yes, the id() function will tell you the addresses, but you can't do anything with them other than perhaps compare them. It's really pretty much useless information.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 07:24 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51c00b28$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48600 |
On Mon, 17 Jun 2013 23:39:10 -0700, Larry Hudson wrote:
> On 06/17/2013 08:50 AM, Simpleton wrote:
>> On 17/6/2013 2:58 μμ, Michael Torrie wrote:
>>
>> a = 5
>> b = a
>>
>> a <---> memory address
>> b <---> memory address
>>
>> I like to think a and b as references to the same memory address
>>
> Not quite: a and b _are_ memory addresses,
Not in Python they aren't. a and b are names in a namespace.
> At the same time, a and b
> are references to the data (the objects) stored in those memory
> locations.
Not in Python they aren't. In Python, objects are free to move around
memory. Not all implementations take advantage of this freedom, but some
like Jython, IronPython and PyPy do.
> The distinction is probably more important in languages like C/C++,
> where the _language_ gives you direct access to, and can manipulate,
> these memory addresses (through pointers). Python handles it
> differently and does not give you this sort of ability, it all occurs
> "under the hood". Yes, the id() function will tell you the addresses,
> but you can't do anything with them other than perhaps compare them.
> It's really pretty much useless information.
The id() function does not tell you the address of the object, except by
accident. The id() function gives you an arbitrary ID number for the
object:
steve@runes:~$ ipy
IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> id([])
43
>>> id('*')
44
steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> id([])
1
>>> id('*')
2
That some implementations happen to use a fixed memory address as the ID
number is, well, a mere accident of implementation. That's not what id()
*is*, any more than "id() returns the next value in an integer sequence
starting from 43" just because that's what IronPython happens to do.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-18 11:49 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpp6v1$le7$1@news.grnet.gr> |
| In reply to | #48600 |
Στις 18/6/2013 9:39 πμ, ο/η Larry Hudson έγραψε: > Not quite: a and b _are_ memory addresses, At the same time, a and b > are references to the data (the objects) stored in those memory locations. > > The distinction is probably more important in languages like C/C++, > where the _language_ gives you direct access to, and can manipulate, > these memory addresses (through pointers). Python handles it > differently and does not give you this sort of ability, it all occurs > "under the hood". Yes, the id() function will tell you the addresses, > but you can't do anything with them other than perhaps compare them. > It's really pretty much useless information. So, a and b are actual memory addresses. Does the term of a pointer exist in Python? I mean if print(a) or print(b) outputs the object that a and b are linked to, then how do we access a's and b's memory locations themselves t create links among variables, one pointing to the other and so on? Can a variable point to another variable or variables never point to other variables but instead are *only* linked to the objects of those var's instead? -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 09:05 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51c022d5$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48609 |
On Tue, 18 Jun 2013 11:49:36 +0300, Νίκος wrote:
> Στις 18/6/2013 9:39 πμ, ο/η Larry Hudson έγραψε:
>> Not quite: a and b _are_ memory addresses, At the same time, a and b
>> are references to the data (the objects) stored in those memory
>> locations.
>>
>> The distinction is probably more important in languages like C/C++,
>> where the _language_ gives you direct access to, and can manipulate,
>> these memory addresses (through pointers). Python handles it
>> differently and does not give you this sort of ability, it all occurs
>> "under the hood". Yes, the id() function will tell you the addresses,
>> but you can't do anything with them other than perhaps compare them.
>> It's really pretty much useless information.
>
> So, a and b are actual memory addresses.
No, no, no, a thousand times no.
> Does the term of a pointer exist in Python?
No.
> I mean if print(a) or
> print(b) outputs the object that a and b are linked to, then how do we
> access a's and b's memory locations themselves t create links among
> variables, one pointing to the other and so on?
You cannot. You can only have links between OBJECTS, not between
VARIABLES. There is no way to have a name "a" set to point to another
name "b". All you can do is have a name "a" set to refer to the same
object as "b" has *right now*. If "b" changes to another object, "a" will
not follow.
> Can a variable point to another variable or variables never point to
> other variables but instead are *only* linked to the objects of those
> var's instead?
Names are *always* linked to objects, not to other names.
a = []
b = a # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-18 12:51 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kppaih$jso$1@news.grnet.gr> |
| In reply to | #48612 |
Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:
> Names are *always* linked to objects, not to other names.
>
> a = []
> b = a # Now a and b refer to the same list
> a = {} # Now a refers to a dict, and b refers to the same list as before
I see, thank you Steven.
But since this is a fact how do you create complicated data structures
that rely on various variables pointing one to another liek we did in
C++(cannot recall their names) ?
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-18 20:22 +1000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3523.1371550941.3114.python-list@python.org> |
| In reply to | #48615 |
On Tue, Jun 18, 2013 at 7:51 PM, Νίκος <support@superhost.gr> wrote:
> Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:
>
>> Names are *always* linked to objects, not to other names.
>>
>> a = []
>> b = a # Now a and b refer to the same list
>> a = {} # Now a refers to a dict, and b refers to the same list as before
>
>
> I see, thank you Steven.
>
> But since this is a fact how do you create complicated data structures that
> rely on various variables pointing one to another liek we did in C++(cannot
> recall their names) ?
Why do you need to? Linked lists, trees, and so on are just tools.
They're usually used to implement data structures like mappings,
growable arrays, lists that can have elements inserted into them, etc,
etc. Python does these sorts of things in better ways. You should not
need to worry about memory locations, pointers, etc. Now, if you want
to have one object reference another, that can be done in plenty of
ways. Check the Python tutorial.
ChrisA
[toc] | [prev] | [next] | [standalone]
Page 6 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