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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-19 23:16 -0600 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3608.1371706547.3114.python-list@python.org> |
| In reply to | #48615 |
On 06/18/2013 03:51 AM, Νίκος 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) ?
>
As Steve said Python provides all manner of data structures and the
means to create data structures. Any data structure (trees, lists, etc)
can all be made easily in Python using Python's basic data structures,
if the built-in data structures are not sufficient. It turns out that
lists, hashes (dicts), and classes can pretty much do anything with
having to much about with C-style pointers and such.
Do yourself a favor and forget about the low-level stuff in Python for
now. You'll be more frustrated if you don't.
The real power and expressivity of Python comes from embracing the
abstractions that Python provides to your advantage. There's a certain
elegance and beauty that comes from such things, which I believe really
comes from the elegance and beauty of LISP, some of which manages to
shine forth in Python, despite its deficiencies. When I first learned
Python, I was impressed that some of the elegance that I remember from
Scheme (how to use lists as a basic type for example) was there, but in
a form that appealed to me.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-20 05:48 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51c297a3$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48773 |
On Wed, 19 Jun 2013 23:16:51 -0600, Michael Torrie wrote: > The real power and expressivity of Python comes from embracing the > abstractions that Python provides to your advantage. There's a certain > elegance and beauty that comes from such things, which I believe really > comes from the elegance and beauty of LISP, some of which manages to > shine forth in Python, despite its deficiencies. When I first learned > Python, I was impressed that some of the elegance that I remember from > Scheme (how to use lists as a basic type for example) was there, but in > a form that appealed to me. Well said! -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-20 00:01 -0600 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3610.1371708078.3114.python-list@python.org> |
| In reply to | #48775 |
On 06/19/2013 11:48 PM, Steven D'Aprano wrote: > On Wed, 19 Jun 2013 23:16:51 -0600, Michael Torrie wrote: > >> The real power and expressivity of Python comes from embracing the >> abstractions that Python provides to your advantage. There's a certain >> elegance and beauty that comes from such things, which I believe really >> comes from the elegance and beauty of LISP, some of which manages to >> shine forth in Python, despite its deficiencies. When I first learned >> Python, I was impressed that some of the elegance that I remember from >> Scheme (how to use lists as a basic type for example) was there, but in >> a form that appealed to me. > > > Well said! Glad you made sense of it... the bit about LISP and Scheme came out a wee bit muddled. In fact thinking about it, perhaps LISPers would say about Python what a bible passage says about having the form of Godliness but denying the power thereof! For example, Python's lambda functions, and Python's functional programming capabilities in general. But since the LISP never really got a form beyond S-expressions, leaving us with lots of parenthesis everywhere, Python wins much as the Hitchhiker's Guide to the Galaxy wins.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@gmail.com> |
|---|---|
| Date | 2013-06-26 01:18 -0700 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <46a7a964-3bca-4805-9dd4-afe86d5c444c@googlegroups.com> |
| In reply to | #48776 |
Michael Torrie於 2013年6月20日星期四UTC+8下午2時01分11秒寫道：
>
> But since the LISP never really got a form beyond S-expressions,
>
> leaving us with lots of parenthesis everywhere, Python wins much as the
>
> Hitchhiker's Guide to the Galaxy wins.
Yep, a list is mutable even it's empty.
But constant integers, floats, strings, and None is immutable.
The variables in a function of python with default
parameters which could be mutable or immutable.
def fun1( x, alist=[]):
alist.append(x*x)
return alist ## valid
def fun2(x, alist=None):
if alist==None: alist=[]
alist.append(x*x)
return alist
# kind of boring to show the name binding mechanism of objects
# in Python in different usages
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-19 23:44 -0600 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3609.1371707070.3114.python-list@python.org> |
| In reply to | #48615 |
On 06/19/2013 11:16 PM, Michael Torrie wrote: > It turns out that lists, hashes (dicts), and classes can pretty much > do anything with having to much about with C-style pointers and > such. Oh wow. Parse error. should read, "pretty much do anything without having to muck about with C-style pointers and such."
[toc] | [prev] | [next] | [standalone]
| From | Roel Schroeven <roel@roelschroeven.net> |
|---|---|
| Date | 2013-06-20 19:19 +0200 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3634.1371748820.3114.python-list@python.org> |
| In reply to | #48615 |
Νίκος schreef:
> Στις 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) ?
You almost never need to do that in Python. But if you really want to,
out of curiosity, you can. For example, you could create a simple singly
linked list like this:
>>> class Node(object):
def __init__(self, value):
self.value = value
self.next = None
>>> first = Node(1)
>>> second = Node(2)
>>> first.next = second
You could iterate over it like this:
>>> def iterate_linked_list(node):
while node:
yield node.value
node = node.next
>>> for v in iterate_linked_list(first):
print v
--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise
roel@roelschroeven.net
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-06-17 10:22 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3481.1371478980.3114.python-list@python.org> |
| In reply to | #48514 |
On 6/17/2013 7:34 AM, Simpleton wrote: > 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 This is backwards. If the interpreter puts 5 in a *permanent* 'memory location' (which is not required by the language!), then it can associate 'a' with 5 by associating it with the memory location. CPython does this, but some other computer implementations do not. > 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? When you interpret Python code, do you put data in locations with integer addresses? -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Simpleton <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 18:55 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpnbhp$k63$2@news.ntua.gr> |
| In reply to | #48518 |
On 17/6/2013 5:22 μμ, Terry Reedy wrote: > On 6/17/2013 7:34 AM, Simpleton wrote: >> 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 > > This is backwards. If the interpreter puts 5 in a *permanent* 'memory > location' (which is not required by the language!), then it can > associate 'a' with 5 by associating it with the memory location. CPython > does this, but some other computer implementations do not. Please tell me how do i need to understand the sentence 'a' is being associated with number 5 in detail. Why don't we access the desired value we want to, by referencing to that value's memory location directly instead of using namespaces wich is an indirect call? i feel we have 3 things here a , memory address of a stored value, actual stored value >> So is it safe to say that in Python a == &a ? (& stands for memory >> address) >> >> is the above correct? > > When you interpret Python code, do you put data in locations with > integer addresses? I lost you here. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Joel Goldstick <joel.goldstick@gmail.com> |
|---|---|
| Date | 2013-06-17 12:26 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3487.1371486406.3114.python-list@python.org> |
| In reply to | #48528 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Jun 17, 2013 at 11:55 AM, Simpleton <support@superhost.gr> wrote: > On 17/6/2013 5:22 μμ, Terry Reedy wrote: > >> On 6/17/2013 7:34 AM, Simpleton wrote: >> >>> 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 >>> >> >> This is backwards. If the interpreter puts 5 in a *permanent* 'memory >> location' (which is not required by the language!), then it can >> associate 'a' with 5 by associating it with the memory location. CPython >> does this, but some other computer implementations do not. >> > > Please tell me how do i need to understand the sentence > 'a' is being associated with number 5 in detail. > > Why don't we access the desired value we want to, by referencing to that > value's memory location directly instead of using namespaces wich is an > indirect call? > > i feel we have 3 things here > > a , memory address of a stored value, actual stored value > > So is it safe to say that in Python a == &a ? (& stands for memory >>> address) >>> >>> is the above correct? >>> >> >> When you interpret Python code, do you put data in locations with >> integer addresses? >> > > I lost you here. > > > > -- > What is now proved was at first only imagined! > -- > http://mail.python.org/**mailman/listinfo/python-list<http://mail.python.org/mailman/listinfo/python-list> > Read and study this. Then come back and ask again. Don't think of physical representation of memory with actual binary addresses. Python is not assembler. Neither is it C (sometimes called high level assembler) http://docs.python.org/2/tutorial/classes.html#python-scopes-and-namespaces -- Joel Goldstick http://joelgoldstick.com
[toc] | [prev] | [next] | [standalone]
| From | Benjamin Kaplan <benjamin.kaplan@case.edu> |
|---|---|
| Date | 2013-06-17 09:23 -0700 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3488.1371486574.3114.python-list@python.org> |
| In reply to | #48528 |
On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <support@superhost.gr> wrote: > On 17/6/2013 5:22 μμ, Terry Reedy wrote: >> >> On 6/17/2013 7:34 AM, Simpleton wrote: >>> >>> 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 >> >> >> This is backwards. If the interpreter puts 5 in a *permanent* 'memory >> location' (which is not required by the language!), then it can >> associate 'a' with 5 by associating it with the memory location. CPython >> does this, but some other computer implementations do not. > > > Please tell me how do i need to understand the sentence > 'a' is being associated with number 5 in detail. > > Why don't we access the desired value we want to, by referencing to that > value's memory location directly instead of using namespaces wich is an > indirect call? > > i feel we have 3 things here > > a , memory address of a stored value, actual stored value > >>> So is it safe to say that in Python a == &a ? (& stands for memory >>> address) >>> >>> is the above correct? >> >> >> When you interpret Python code, do you put data in locations with >> integer addresses? > > > I lost you here. > You're confusing the way in which the CPython interpreter is written with the way the Python language is defined. Yes, the CPython interpreter puts 5 into a numbered memory location when creating the object. But the Nikos Python Interpreter (which is a completely valid, although quite buggy, Python interpreter that uses your head to interpret the code) should not be using numbered memory locations. Forget about memory locations. Memory locations don't exist. Let's use the pen-and-paper Python interpreter. On the left side of the paper, we'll write down the names. On the rest of the paper, we'll write down the objects. When I do "x =[]", I make a new list (which means I write down [] somewhere in the middle of the page), I create the name "x" (which means I write down an "x" on the left side of the page), and then I draw an arrow pointing from the x to the []. (sorry if my drawing doesn't line up in your email/news client- I'll try to make it line up correctly with a monospace font) -------------------------------------------- | x --------------> [] | | | | | -------------------------------------------- Now, When we do y = x, the right side of the equation is evaluated (which gives us the object currently bound to the name x) and it is then given the newly created name "y" -------------------------------------------- | x --------------> [] | | ^ | | y ----------------| | -------------------------------------------- When we do x.append(3), the object that x refers to is modified. This is seen by both x and y because they point to the same object. -------------------------------------------- | x --------------> [3] | | ^ | | y ----------------| | -------------------------------------------- When I do x = [], a new object is created somewhere else on the page, and the name x is made to point to the new object. This changes the arrow. The name "x" is not in any way tied to the location of the [3] on the page. This doesn't impact "y" which is still pointing at the same spot it was before -------------------------------------------- | x -------->[] [3] | | ^ | | y ----------------| | -------------------------------------------- That is how Python's object model works. In CPython, objects have specified memory locations but names do not. In IronPython and Jython, even that's not guaranteed- the garbage collector can move the objects around during their lifetime, so while you can trust that a name will always point to the correct object, you have no guarantee about where the object is located in the computer's memory.
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 20:17 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpngc1$av7$1@news.grnet.gr> |
| In reply to | #48533 |
On 17/6/2013 7:23 μμ, Benjamin Kaplan wrote: > On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <support@superhost.gr> wrote: >> On 17/6/2013 5:22 μμ, Terry Reedy wrote: >>> >>> On 6/17/2013 7:34 AM, Simpleton wrote: >>>> >>>> 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 >>> >>> >>> This is backwards. If the interpreter puts 5 in a *permanent* 'memory >>> location' (which is not required by the language!), then it can >>> associate 'a' with 5 by associating it with the memory location. CPython >>> does this, but some other computer implementations do not. >> >> >> Please tell me how do i need to understand the sentence >> 'a' is being associated with number 5 in detail. >> >> Why don't we access the desired value we want to, by referencing to that >> value's memory location directly instead of using namespaces wich is an >> indirect call? >> >> i feel we have 3 things here >> >> a , memory address of a stored value, actual stored value >> >>>> So is it safe to say that in Python a == &a ? (& stands for memory >>>> address) >>>> >>>> is the above correct? >>> >>> >>> When you interpret Python code, do you put data in locations with >>> integer addresses? >> >> >> I lost you here. >> > > You're confusing the way in which the CPython interpreter is written > with the way the Python language is defined. Yes, the CPython > interpreter puts 5 into a numbered memory location when creating the > object. But the Nikos Python Interpreter (which is a completely valid, > although quite buggy, Python interpreter that uses your head to > interpret the code) should not be using numbered memory locations. > > Forget about memory locations. Memory locations don't exist. Let's use > the pen-and-paper Python interpreter. On the left side of the paper, > we'll write down the names. On the rest of the paper, we'll write down > the objects. > > When I do "x =[]", I make a new list (which means I write down [] > somewhere in the middle of the page), I create the name "x" (which > means I write down an "x" on the left side of the page), and then I > draw an arrow pointing from the x to the []. > (sorry if my drawing doesn't line up in your email/news client- I'll > try to make it line up correctly with a monospace font) > -------------------------------------------- > | x --------------> [] | > | | > | | > -------------------------------------------- > > Now, When we do y = x, the right side of the equation is evaluated > (which gives us the object currently bound to the name x) and it is > then given the newly created name "y" > -------------------------------------------- > | x --------------> [] | > | ^ | > | y ----------------| | > -------------------------------------------- > > When we do x.append(3), the object that x refers to is modified. This > is seen by both x and y because they point to the same object. > > -------------------------------------------- > | x --------------> [3] | > | ^ | > | y ----------------| | > -------------------------------------------- > > When I do x = [], a new object is created somewhere else on the page, > and the name x is made to point to the new object. This changes the > arrow. The name "x" is not in any way tied to the location of the [3] > on the page. This doesn't impact "y" which is still pointing at the > same spot it was before > > -------------------------------------------- > | x -------->[] [3] | > | ^ | > | y ----------------| | > -------------------------------------------- > > That is how Python's object model works. In CPython, objects have > specified memory locations but names do not. In IronPython and Jython, > even that's not guaranteed- the garbage collector can move the objects > around during their lifetime, so while you can trust that a name will > always point to the correct object, you have no guarantee about where > the object is located in the computer's memory. > EXCELLENT EXPLANATION, THANK YOU VERY MUCH. I AM SAVING THIS TO A .TXT FOR FUTURE REFERENCE. THAT'S WHY I ASK YOU GUYS FOR HUMAN LIKE EXPLANATIONS. THIS CANNOT BE FIND WITH SUCH SIMPLE WAY OF PUTTING THIS IN TECH DOCS. Something else please: The way some info(i.e. a Unicode string) is saved into the hdd , is the same way its being saved into the memory too? Same way exactly? While you said to me to forget about memory locations, and that's indeed made things easy to follow i still keep wondering, how Python internally keeping tracks of 'x' and 'y' names as well as their referenced objects (i.e. number 6). After all the way i understand memory is as a series of bits like: 0100010100011110101000010101010010001001010010011100001101001010010 So from the above binary form: what is 'x', what is 'y', how's 'x' and 'y' differ from the actually memory locations that are bound too, and of course what is the actual value. Its 3 things for me to consider, even in Python id internal level detail. I want to understand this. names, memory addresses, memory address's actual values Thanks again Benjamin for making things clear. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2013-06-17 18:16 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3495.1371507400.3114.python-list@python.org> |
| In reply to | #48540 |
On 6/17/2013 1:17 PM, Νίκος wrote: >> On Mon, Jun 17, 2013 at 8:55 AM, Simpleton <support@superhost.gr> wrote: >>> On 17/6/2013 5:22 μμ, Terry Reedy wrote: >>>> When you interpret Python code, do you put data in locations with >>>> integer addresses? >>> I lost you here. Memory in biological brains is not a linear series of bits, or characters. How we do associate things is still mostly a puzzle. Read about holographic memory. > The way some info(i.e. a Unicode string) is saved into the hdd , is the > same way its being saved into the memory too? Same way exactly? No. A unicode string is a sequence of abstract characters or codepoints. They must be encoded somehow to map them to linear byte memory. There are still (too) many encodings in use. Most cannot encode *all* unicode characters. CPython is unusual in using one of three different encodings for internal unicode strings. > While you said to me to forget about memory locations, This is excellent advice. One of the *features* of Python is that one *can* forget about addresses. One of the *problems* of C is that many people *do* forget about memory locations, while virus writers study them carefully. -- Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-17 23:09 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bf9714$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48514 |
On Mon, 17 Jun 2013 14:34:57 +0300, Simpleton wrote:
> 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
No. a is associated to an object, the int 5, which may be free to move in
memory (PyPy does this), or may be at a fixed memory location (CPython
does this). But the association is with the object, not the memory
location.
The object is a data structure that contains a type (int), a value (5),
and various methods (e.g. bit_length, to_bytes).
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.
No. We're talking about what the Python interpreter does, not what you
do. Whether you are programming in C or Python, you still refer to
variables by name:
a = 5
but what goes on inside the interpreter or compiler is different.
> So is it safe to say that in Python a == &a ? (& stands for memory
> address)
Absolutely not.
> 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?
No. This has nothing to do with memory locations. Namespaces are dicts.
Write down a dict:
{"a": "Hello world"}
Do you see a memory location there? There is no memory location. There is
the name, "a", and the object it is associated with, "Hello world".
Either the dict, or the string, may move around memory if the underlying
memory manager allows it. Obviously any object in Python must be
*somewhere* in memory at any specific moment, but that is irrelevant to
understanding Python code. It is no more relevant than saying that a dict
{'a': 5} is just made up of bits.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-18 02:26 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpo5vf$sa6$2@news.grnet.gr> |
| In reply to | #48573 |
Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:
> {"a": "Hello world"}
>
> Do you see a memory location there? There is no memory location. There is
> the name, "a", and the object it is associated with, "Hello world".
> Either the dict, or the string, may move around memory if the underlying
> memory manager allows it. Obviously any object in Python must be
> *somewhere* in memory at any specific moment, but that is irrelevant to
> understanding Python code. It is no more relevant than saying that a dict
> {'a': 5} is just made up of bits.
Okey, the easy part was to understand how humans in high level need to
understand namespaces and assignment (which is not copying but instead
referencing another name to the same object).
But i would like to know, what happens internally within the python
compiler, because obviously memory is involved.
The way some info(i.e. a Unicode string) is saved into the hdd , is the
same way its being saved into the memory too? Same way exactly?
While you said to me to forget about memory locations, and that's indeed
made things easy to follow i still keep wondering, how Python internally
keeping tracks of 'x' and 'y' names as well as their referenced objects
(i.e. number 6).
After all the way i understand memory is as a series of bits like:
0100010100011110101000010101010010001001010010011100001101001010010
So from the above binary form:
what is 'x', what is 'y', how's 'x' and 'y' differ from the actually
memory locations that are bound too, and of course what is the actual value.
Its 3 things for me to consider, even in Python id internal level
detail. I want to understand this.
names, memory addresses, memory address's actual values
--
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 00:41 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfacd0$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48577 |
On Tue, 18 Jun 2013 02:26:39 +0300, Νίκος wrote:
> Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:
>> {"a": "Hello world"}
>>
>> Do you see a memory location there? There is no memory location. There
>> is the name, "a", and the object it is associated with, "Hello world".
>> Either the dict, or the string, may move around memory if the
>> underlying memory manager allows it. Obviously any object in Python
>> must be *somewhere* in memory at any specific moment, but that is
>> irrelevant to understanding Python code. It is no more relevant than
>> saying that a dict {'a': 5} is just made up of bits.
>
> Okey, the easy part was to understand how humans in high level need to
> understand namespaces and assignment (which is not copying but instead
> referencing another name to the same object).
>
> But i would like to know, what happens internally within the python
> compiler, because obviously memory is involved.
Depends which Python compiler.
CPython, IronPython, PyPy, Jython, Nuitka, Cython, ... ? They all operate
differently on the inside. Only the high-level Python code has to be the
same.
Jython works according to the JRE, the Java Runtime Environment. There is
masses of information about that on the Internet, google for it.
IronPython works according to the .Net runtime environment. Again, google
for it.
PyPy is a VERY complex but powerful JIT compiler. You can read about it
on the PyPy blog. Start here: http://morepypy.blogspot.com/
There's not a lot of documentation on how CPython works internally. You
have to read the C source code. You will need to understand about garbage
collectors, memory management, the difference between the stack and the
heap, etc. It's a big area to study. Don't expect anyone to spend the
days or weeks it will take to explain the whole thing.
> The way some info(i.e. a Unicode string) is saved into the hdd , is the
> same way its being saved into the memory too? Same way exactly?
No. Unicode strings can be stored on disk in any encoding you like.
Python stores string in memory as objects, which might look something
like this:
[Type=str, size=42, data=...]
only more complicated. And subject to change -- anything you learn that
holds for Python 3.3 might not apply for 3.2 or 3.4.
In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected
when the Python compiler itself is compiled. In Python 3.3, the data will
be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents
of the string.
> While you said to me to forget about memory locations, and that's indeed
> made things easy to follow i still keep wondering, how Python internally
> keeping tracks of 'x' and 'y' names as well as their referenced objects
> (i.e. number 6).
Good question, but I don't have a good answer. It has to do with the
Python's memory manager, and the garbage collector. I don't know how they
work.
> After all the way i understand memory is as a series of bits like:
>
> 0100010100011110101000010101010010001001010010011100001101001010010
>
> So from the above binary form:
>
> what is 'x', what is 'y', how's 'x' and 'y' differ from the actually
> memory locations that are bound too, and of course what is the actual
> value.
>
> Its 3 things for me to consider, even in Python id internal level
> detail. I want to understand this.
>
> names, memory addresses, memory address's actual values
Start here:
https://duckduckgo.com/html/?q=how%20computers%20work
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-17 21:06 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3500.1371517631.3114.python-list@python.org> |
| In reply to | #48581 |
On 06/17/2013 08:41 PM, Steven D'Aprano wrote: > > <SNIP> > > In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected > when the Python compiler itself is compiled. I think that was a typo. Do you perhaps UCS-2 or UCS-4 > In Python 3.3, the data will > be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents > of the string. > > -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 02:42 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfc931$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48583 |
On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote: > On 06/17/2013 08:41 PM, Steven D'Aprano wrote: >> >> <SNIP> >> >> In Python 3.2 and older, the data will be either UTF-4 or UTF-8, >> selected when the Python compiler itself is compiled. > > I think that was a typo. Do you perhaps UCS-2 or UCS-4 Yes, that would be better. UCS-2 is identical to UTF-16, except it doesn't support non-BMP characters and therefore doesn't have surrogate pairs. UCS-4 is functionally equivalent to UTF-16, as far as I can tell. (I'm not really sure what the difference is.) -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-18 00:12 -0400 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3506.1371528775.3114.python-list@python.org> |
| In reply to | #48590 |
On 06/17/2013 10:42 PM, Steven D'Aprano wrote: > On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote: > >> On 06/17/2013 08:41 PM, Steven D'Aprano wrote: >>> >>> <SNIP> >>> >>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8, >>> selected when the Python compiler itself is compiled. >> >> I think that was a typo. Do you perhaps UCS-2 or UCS-4 > > Yes, that would be better. > > UCS-2 is identical to UTF-16, except it doesn't support non-BMP > characters and therefore doesn't have surrogate pairs. > > UCS-4 is functionally equivalent to UTF-16, Perhaps you mean UTF-32 ? as far as I can tell. (I'm > not really sure what the difference is.) > Now you've got me curious, by bringing up surrogate pairs. Do you know whether a narrow build (say 3.2) really works as UTF16, so when you encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode character into a single UTF-8 sequence (prob. 4 bytes long) ? -- DaveA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 06:04 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bff874$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48593 |
On Tue, 18 Jun 2013 00:12:34 -0400, Dave Angel wrote:
> On 06/17/2013 10:42 PM, Steven D'Aprano wrote:
>> On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote:
>>
>>> On 06/17/2013 08:41 PM, Steven D'Aprano wrote:
>>>>
>>>> <SNIP>
>>>>
>>>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
>>>> selected when the Python compiler itself is compiled.
>>>
>>> I think that was a typo. Do you perhaps UCS-2 or UCS-4
>>
>> Yes, that would be better.
>>
>> UCS-2 is identical to UTF-16, except it doesn't support non-BMP
>> characters and therefore doesn't have surrogate pairs.
>>
>> UCS-4 is functionally equivalent to UTF-16,
>
> Perhaps you mean UTF-32 ?
Yes, sorry for the repeated confusion.
>> as far as I can tell. (I'm
>> not really sure what the difference is.)
>>
>>
> Now you've got me curious, by bringing up surrogate pairs. Do you know
> whether a narrow build (say 3.2) really works as UTF16, so when you
> encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode
> character into a single UTF-8 sequence (prob. 4 bytes long) ?
In a Python narrow build, the internal storage of strings is equivalent
to UTF-16: all characters in the Basic Multilingual Plane require two
bytes:
py> sys.maxunicode
65535
py> sys.getsizeof('π') - sys.getsizeof('')
2
Outside of the BMP, characters are treated as a pair of surrogates:
py> c = chr(0x10F000) # one character...
py> len(c) # ...stored as a pair of surrogates
2
Encoding and decoding works fine:
py> c.encode('utf-8').decode('utf-8') == c
True
py> c.encode('utf-8')
b'\xf4\x8f\x80\x80'
The problem with surrogates is that it is possible to accidentally
separate the pair, which leads to broken, invalid text:
py> c[0].encode('utf-8')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udbfc' in
position 0: surrogates not allowed
(The error message is a little misleading; surrogates are allowed, but
only if they make up a valid pair.)
Python's handling of UTF-16 is, as far as I know, correct. What isn't
correct is that the high-level Python string methods assume that two
bytes == one character, which can lead to surrogates being separated,
which gives you junk text. Wide builds don't have this problem, because
every character == four bytes, and neither does Python 3.
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-18 02:38 +0000 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bfc81c$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48581 |
On Tue, 18 Jun 2013 00:41:53 +0000, Steven D'Aprano wrote: > In Python 3.2 and older, the data will be either UTF-4 or UTF-8, > selected when the Python compiler itself is compiled. In Python 3.3, the > data will be stored in either Latin-1, UTF-4, or UTF-8, depending on the > contents of the string. UTF-4? UTF-8? Whatever crack I was smoking, it obviously was *bad* crack. That should be UTF-8 or UTF-16. -- Steven
[toc] | [prev] | [next] | [standalone]
Page 7 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