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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2013-06-14 21:17 +0300 |
| Message-ID | <qotobb8pnfa.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #48182 |
Nick the Gr33k writes:
> >>> (a or b or c)
> 'abcd'
>
> This for me, should evaluate to True but instead it has been
> evaluated to the first variable's value, which is a truthy value of
> course since its not an empty string, but shouldn't it return True
> instead?
In your own programs, write bool(a or b or c) instead. And instead of
writing (k in (a or b or c)), write ((k in a) or (k in b) or (k in c))
-- you can use fewer parentheses if you like, but only if you are
comfortable with it. (Here, I use the outer parentheses to separate
Python from English. I might not use them in code.)
Usually such expressions occur as conditions in conditional statements
or conditional expressions. There, the bool() makes no observable
difference.
> Returning True is the same thing as returning a variable's truthy
> value?
I think that's a good approximation. Strictly speaking, True is a
particular value in Python, but I think that at the moment you need to
understand that what is important is how the value is interpreted as a
condition in a conditional statement (if condition:, elif: condition),
a conditional expression (x if condition else y), a while loop (while
condition:).
>>> while "ijkl": print("it doesn't matter")
[toc] | [prev] | [next] | [standalone]
| From | Larry Hudson <orgnut@yahoo.com> |
|---|---|
| Date | 2013-06-14 22:27 -0700 |
| Message-ID | <bfudnQuhb7jHZibMnZ2dnUVZ_t-dnZ2d@giganews.com> |
| In reply to | #48182 |
On 06/14/2013 09:56 AM, Nick the Gr33k wrote: > On 14/6/2013 7:31 μμ, Steven D'Aprano wrote: >> On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote: >> > > Returning True is the same thing as returning a variable's truthy value? > NO! 'True' and 'False' are the two values of the boolean type. The 'and' and 'or' logical operators do NOT return a boolean type of True or False. (Although, the 'not' DOES return a boolean.) Also they do NOT return "a variable's truthy value", they return the variable itself. Now, that returned variable can then be interpreted as a boolean value for other operations in the same way that (virtually) all data types can be interpreted as a boolean. Let me emphasize... they are INTERPRETED as having a boolean VALUE, but they are NOT a boolean TYPE. > > >>> (a and b and c) > 'ijkl' > > This in my head should have been evaluated to True also since all 3 strings hold truthy values > You need to get it into your thick head that you are mistaken, like everyone is trying to tell you. What YOU think about it is WRONG! Throw that thinking away and start LISTENING to what you are being told are the facts. > Why on earth this boolean expression evaluates to the value of the last variable? This is what > can't at all seem to follow. > BECAUSE THAT IS THE WAY PYTHON IS DEFINED, whether or not you agree with it. You are WRONG! It is time for you to accept the fact that you are mistaken and start trying to learn how Python IS defined -- NOT how YOU think it should be defined. > > What i'm trying to say that both these exprs are Boolean Expressions therefore should return > Boolean values not variable's values, even if they are truthy. > I repeat: what YOU think Python should do is completely irrelevant. If you keep insisting on trying to use Python they way you THINK it should work instead of the way it is DEFINED to work, you'll lose that argument every time. The whys of how Python works is, frankly, not important -- interesting and useful perhaps, but essentially irrelevant. Just keep writing Python in the way it is defined, and learning the whys will come along.
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-15 11:39 +0300 |
| Message-ID | <kph978$29li$6@news.ntua.gr> |
| In reply to | #48249 |
On 15/6/2013 8:27 πμ, Larry Hudson wrote:
> On 06/14/2013 09:56 AM, Nick the Gr33k wrote:
>> On 14/6/2013 7:31 μμ, Steven D'Aprano wrote:
>>> On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:
>>>
>
>>
>> Returning True is the same thing as returning a variable's truthy value?
>>
> NO! 'True' and 'False' are the two values of the boolean type. The
> 'and' and 'or' logical operators do NOT return a boolean type of True or
> False.
Indeed.
>>> print( name and month and year )
hijk
>>> print( bool( name and month and year ) )
True
>>> print( name or month or year )
abcd
print( bool( name or month or year ) )
True
> Also they do NOT return "a variable's truthy value", they return the
> variable itself.
No, as seen from my above examples, what is returned after the expr eval
are the actual variables' values, which in turn are truthy, *not* the
variable itself.
> Now, that returned variable can then be interpreted as
> a boolean value for other operations in the same way that (virtually)
> all data types can be interpreted as a boolean. Let me emphasize...
> they are INTERPRETED as having a boolean VALUE, but they are NOT a
> boolean TYPE.
Yes the returned value of 'hijk' is being interpreted as bool('hijk'),
which boils down as truthy.
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Lele Gaifax <lele@metapensiero.it> |
|---|---|
| Date | 2013-06-15 11:54 +0200 |
| Message-ID | <mailman.3368.1371290048.3114.python-list@python.org> |
| In reply to | #48269 |
Nick the Gr33k <support@superhost.gr> writes:
> On 15/6/2013 8:27 πμ, Larry Hudson wrote:
>> Also they do NOT return "a variable's truthy value", they return the
>> variable itself.
>
> No, as seen from my above examples, what is returned after the expr
> eval are the actual variables' values, which in turn are truthy, *not*
> the variable itself.
In the context we are talking about, "the variable itself" has the very
same meaning as "the actual variable value":
>>> mylist = ['foo']
>>> emptylist = []
>>> result = emptylist or mylist
>>> result.append('bar')
>>> result is mylist
True
>>> print(mylist)
['foo', 'bar']
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it | -- Fortunato Depero, 1929.
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-15 16:07 +0300 |
| Message-ID | <kphou8$slt$1@news.ntua.gr> |
| In reply to | #48277 |
On 15/6/2013 12:54 μμ, Lele Gaifax wrote:
> Nick the Gr33k <support@superhost.gr> writes:
>
>> On 15/6/2013 8:27 πμ, Larry Hudson wrote:
>>> Also they do NOT return "a variable's truthy value", they return the
>>> variable itself.
>>
>> No, as seen from my above examples, what is returned after the expr
>> eval are the actual variables' values, which in turn are truthy, *not*
>> the variable itself.
>
> In the context we are talking about, "the variable itself" has the very
> same meaning as "the actual variable value":
Are there cases that a variable and the variable's value cosidered to be
2 different things?
>>>> mylist = ['foo']
>>>> emptylist = []
>>>> result = emptylist or mylist
result = mylist (since its a no-emoty list)
>>>> result.append('bar')
>>>> result is mylist
> True
Never seen the last statement before. What does that mean?
result is mylist ????
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-15 09:53 -0600 |
| Message-ID | <mailman.3382.1371311603.3114.python-list@python.org> |
| In reply to | #48292 |
On 06/15/2013 07:07 AM, Nick the Gr33k wrote:
> result = mylist (since its a no-emoty list)
>
>>>>> result.append('bar')
>>>>> result is mylist
>> True
>
> Never seen the last statement before. What does that mean?
> result is mylist ????
Yes. Surprisingling good question.
http://docs.python.org/3.3/reference/expressions.html#is
http://docs.python.org/3/reference/datamodel.html
One thing that you may find interesting is that what we often call
variables in Python, and which from your code's point of view look and
act like variables are in fact names. Whereas in C, assignment can be
thought of as copy (a = b in C means that b's value is copied to a), in
Python assignment is associating a name with an object. Thus a = b in
Python means that now the names a and b both are bound (reference to)
the same object. That's why the "is" operator is there, to help one
know if two names point to the same object.
I bring this up on the list from time to time because I find it really
interesting and intellectually appealing the way Python works. Hearkens
back to my class at uni on programming language theory.
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-15 19:18 +0300 |
| Message-ID | <kpi45d$n5$3@news.ntua.gr> |
| In reply to | #48313 |
On 15/6/2013 6:53 μμ, Michael Torrie wrote:
> On 06/15/2013 07:07 AM, Nick the Gr33k wrote:
>> result = mylist (since its a no-emoty list)
>>
>>>>>> result.append('bar')
>>>>>> result is mylist
>>> True
>>
>> Never seen the last statement before. What does that mean?
>> result is mylist ????
>
> Yes. Surprisingling good question.
>
> http://docs.python.org/3.3/reference/expressions.html#is
> http://docs.python.org/3/reference/datamodel.html
>
> One thing that you may find interesting is that what we often call
> variables in Python, and which from your code's point of view look and
> act like variables are in fact names. Whereas in C, assignment can be
> thought of as copy (a = b in C means that b's value is copied to a), in
> Python assignment is associating a name with an object. Thus a = b in
> Python means that now the names a and b both are bound (reference to)
> the same object. That's why the "is" operator is there, to help one
> know if two names point to the same object.
>
> I bring this up on the list from time to time because I find it really
> interesting and intellectually appealing the way Python works. Hearkens
> back to my class at uni on programming language theory.
>
>
(a = b in C means that b's value is copied to a)
in C:
a = memory chunk able to hold some specific type's value
b = memory chunk able to hold some specific type's value
a = b means
So we have 2 memory units hod, the same value.
in Python:
a and b you say are names, which still are memory chunks
In both situations we still have 2 memory units holding values, so hows
that different?
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-15 11:45 -0600 |
| Message-ID | <mailman.3394.1371318322.3114.python-list@python.org> |
| In reply to | #48315 |
On 06/15/2013 10:18 AM, Nick the Gr33k wrote: > a and b you say are names, which still are memory chunks Yes no matter how you look at it, a dictionary of names and objects is memory and "variables" in that sense. But at a higher level, we can consider the differences with how a language like C defines variables. > In both situations we still have 2 memory units holding values, so hows > that different? Perhaps one could think of python names as more like pointers or references in C. But python references are counted and garbage-collected (more like a C++ reference-counting pointer type). For example, a = 4 makes the name "a" be a reference to the object int(4), which will never ever change in its lifetime (indeed it wouldn't make sense for the integer 4 to change otherwise it wouldn't be a 4). Thus a = a + 1 creates a new object that represents the integer value of 4 + 1, and throws the old object away. >>> a = 5 >>> id(a) 2857664 >>> a = a + 1 >>> id (a) 2857680 >>> Note that the identity (object) of a has changed. If a were a variable in the same sense as C, the identity of a would not change. A mutable object like a list acts more like a variable in some ways: >>> b = [] >>> id(b) 3076765292 >>> b.append(3) >>> id(b) 3076765292 In many cases the distinction is little more than intellectual for all intents and purposes, though it some cases the idea is very powerful. But there a couple of cases where the difference between a variable and a name referencing an object does bite people in Python: http://effbot.org/zone/default-values.htm http://stackoverflow.com/questions/986006/python-how-do-i-pass-a-variable-by-reference
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-06-16 06:32 +0000 |
| Message-ID | <kpjm6h$4rb$1@dont-email.me> |
| In reply to | #48315 |
On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote: > In both situations we still have 2 memory units holding values, so hows > that different? Consider that each named variable is a pointer to a memory location that holds a value. This is one of the ways in that a typed compiled language and an untyped scripted language may differ in their treatment of data items (or variables). Consider the following C and Python code: C: int a, b; b = 6; a = b; In C, this places the numeric value 6 into the memory location identified by the variable "b", then copies the value from the location pointed to by "b" into the location pointed to by "a". b is a pointer to a memory location containing the value 6 a is a pointer to another memory location also containing the value 6 Python: b = 6 a = b In Python, this first puts the value 6 in in a memory location and points "b" at that memory location, then makes "a" point to the same memory location as "b" points to. b is a pointer to a memory location containing the value 6 a is a pointer to the same memory location Do you understand the difference? -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 11:07 +0300 |
| Message-ID | <kpjrng$hmp$1@news.ntua.gr> |
| In reply to | #48416 |
On 16/6/2013 9:32 πμ, Denis McMahon wrote: > On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote: > >> In both situations we still have 2 memory units holding values, so hows >> that different? > > Consider that each named variable is a pointer to a memory location that > holds a value. This is one of the ways in that a typed compiled language > and an untyped scripted language may differ in their treatment of data > items (or variables). > > Consider the following C and Python code: > > C: > > int a, b; > b = 6; > a = b; > > In C, this places the numeric value 6 into the memory location identified > by the variable "b", then copies the value from the location pointed to > by "b" into the location pointed to by "a". > > b is a pointer to a memory location containing the value 6 > a is a pointer to another memory location also containing the value 6 > > Python: > > b = 6 > a = b > > In Python, this first puts the value 6 in in a memory location and points > "b" at that memory location, then makes "a" point to the same memory > location as "b" points to. > > b is a pointer to a memory location containing the value 6 > a is a pointer to the same memory location > > Do you understand the difference? > Yes and thank you for explaining in detail to me. So Python economies(saves) system's memory. Good job Python! There is no point having 2 variables point to 2 different memory locations as C does since both of those memory locations are supposed to contain the same value! One thing that i want you guys to confirm to me: a and b in both of the languages mentioned are pointers to memory locations which hold a value. A pointer = a variable that has as a value a memory address a variable = a memory address that has as a value the actual value we want to store. But since pointer itself is a memory location that holds as a value the address of another memory location(by definition) that in it's own turn holds the actual value we want stored? So the scheme would look like this in Python: memory address = number 6 memory address = memory address value that stores number 6 (pointer a) memory address = memory address value that stores number 6 (pointer b) So having in mind the above. The memory address that actually stores number 6 have no name at all and the only way to access it's value is by printing the variables a or b? Doesn't that memory address have a name itself? if someone wants the memory address of the pointer's a or b, how can he access it? in C it was somethign like &a and &b And in Python internally shall i imagine two tables that has associations of: variable's_name <-> memory_address <-> actual value And ALL 3 of them are actually bits(1s and 0s) Is this how the thing works? -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-06-16 09:22 +0000 |
| Message-ID | <kpk04c$4rb$6@dont-email.me> |
| In reply to | #48418 |
On Sun, 16 Jun 2013 11:07:12 +0300, Nick the Gr33k wrote: > On 16/6/2013 9:32 πμ, Denis McMahon wrote: >> On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote: >> >>> In both situations we still have 2 memory units holding values, so >>> hows that different? >> >> Consider that each named variable is a pointer to a memory location >> that holds a value. This is one of the ways in that a typed compiled >> language and an untyped scripted language may differ in their treatment >> of data items (or variables). >> >> Consider the following C and Python code: >> >> C: >> >> int a, b; >> b = 6; >> a = b; >> >> In C, this places the numeric value 6 into the memory location >> identified by the variable "b", then copies the value from the location >> pointed to by "b" into the location pointed to by "a". >> >> b is a pointer to a memory location containing the value 6 a is a >> pointer to another memory location also containing the value 6 >> >> Python: >> >> b = 6 >> a = b >> >> In Python, this first puts the value 6 in in a memory location and >> points "b" at that memory location, then makes "a" point to the same >> memory location as "b" points to. >> >> b is a pointer to a memory location containing the value 6 a is a >> pointer to the same memory location >> >> Do you understand the difference? >> > Yes and thank you for explaining in detail to me. > So Python economies(saves) system's memory. Good job Python! No. Don't read that into it. 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 Python doesn't point all the variables that have the same value at the same location. > A pointer = a variable that has as a value a memory address a variable = > a memory address that has as a value the actual value we want to store. These are really C terms, not Python terms. Stop thinking that C is behaving like Python. > Is this how the thing works? No. Python is an interpreted language. C is a compiled language. They present very different feature sets to the user. You need to understand this, and at the moment you're not doing so. -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 12:59 +0300 |
| Message-ID | <kpk295$hmp$5@news.ntua.gr> |
| In reply to | #48424 |
On 16/6/2013 12:22 μμ, Denis McMahon wrote: > On Sun, 16 Jun 2013 11:07:12 +0300, Nick the Gr33k wrote: > >> On 16/6/2013 9:32 πμ, Denis McMahon wrote: >>> On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote: >>> >>>> In both situations we still have 2 memory units holding values, so >>>> hows that different? >>> >>> Consider that each named variable is a pointer to a memory location >>> that holds a value. This is one of the ways in that a typed compiled >>> language and an untyped scripted language may differ in their treatment >>> of data items (or variables). >>> >>> Consider the following C and Python code: >>> >>> C: >>> >>> int a, b; >>> b = 6; >>> a = b; >>> >>> In C, this places the numeric value 6 into the memory location >>> identified by the variable "b", then copies the value from the location >>> pointed to by "b" into the location pointed to by "a". >>> >>> b is a pointer to a memory location containing the value 6 a is a >>> pointer to another memory location also containing the value 6 >>> >>> Python: >>> >>> b = 6 >>> a = b >>> >>> In Python, this first puts the value 6 in in a memory location and >>> points "b" at that memory location, then makes "a" point to the same >>> memory location as "b" points to. >>> >>> b is a pointer to a memory location containing the value 6 a is a >>> pointer to the same memory location >>> >>> Do you understand the difference? >>> >> Yes and thank you for explaining in detail to me. >> So Python economies(saves) system's memory. Good job Python! > > No. Don't read that into it. > > 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. >> A pointer = a variable that has as a value a memory address a variable = >> a memory address that has as a value the actual value we want to store. > > These are really C terms, not Python terms. Stop thinking that C is > behaving like Python. I think it behaves the same way, but lets here from someone else too. >> Is this how the thing works? > > No. > > Python is an interpreted language. C is a compiled language. They present > very different feature sets to the user. You need to understand this, and > at the moment you're not doing so. Whats the difference of "interpreting " to "compiling" ? I have also asked other things too which you didn't quote, please do. -- 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 11:42 +0100 |
| Message-ID | <mailman.3433.1371379385.3114.python-list@python.org> |
| In reply to | #48427 |
On Sun, Jun 16, 2013 at 10:59 AM, Nick the Gr33k <support@superhost.gr> wrote: > 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. Actually, y'all both might be. This is a bit CPython specific and not mandated by the language specification. To Nikos: please don't extrapolate from the examples below. They are a CPython (the most common implementation of the Python language) specific detail. ## CODE SNIPPET## a = 6; b = a; c = 6 id(a) id(b) id(c) ## END CODE## These are all the same, indicating that they all point to the "same 6" in memory. That's a CPython specific optimization (caching small integers) which is not guaranteed by the language and changes between pythons and between compiles. For example, ## CODE SNIPPET## a = 552315251254 b = a c = 552315251254 a is b # True _on my machine_ a is c # False _on my machine_ id(a) id(b) id(c) ## END CODE## Note that to compare if two names point to the same "object, you can use the "is" operator. a is b c is a etc. > >>> A pointer = a variable that has as a value a memory address a variable = >>> a memory address that has as a value the actual value we want to store. >> >> >> These are really C terms, not Python terms. Stop thinking that C is >> behaving like Python. > > > > I think it behaves the same way, but lets here from someone else too. I understand the Greeks invented democracy and all that, but facts aren't subject to it. > > Whats the difference of "interpreting " to "compiling" ? If only it could be googled.... Alas, no one has ever written anything about technology on the internet. Ironic that... Michael
[toc] | [prev] | [next] | [standalone]
| From | Ferrous Cranus <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 14:06 +0300 |
| Message-ID | <kpk67v$10mb$1@news.ntua.gr> |
| In reply to | #48429 |
On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote: >> >> 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. > Actually, y'all both might be. This is a bit CPython specific and not > mandated by the language specification. > > To Nikos: please don't extrapolate from the examples below. They are a > CPython (the most common implementation of the Python language) > specific detail. > > ## CODE SNIPPET## > a = 6; b = a; c = 6 > > id(a) > id(b) > id(c) > ## END CODE## > > These are all the same, indicating that they all point to the "same 6" > in memory. That's a CPython specific optimization (caching small > integers) which is not guaranteed by the language and changes between > pythons and between compiles. > > For example, > > ## CODE SNIPPET## > a = 552315251254 > b = a > c = 552315251254 > > a is b # True _on my machine_ I accept this if in the premise that, b boils down to actually point to a's value, but it has to go through a first to find it, not directly. > a is c # False _on my machine_ Why false? These are 2 different memory locations storing the same number. This should have been True. Looks very weird. a = memory location storing a value b = memory location storing a's memory location c = memory location storing a value, the same value as a > id(a) > id(b) > id(c) > ## END CODE## > > Note that to compare if two names point to the same "object, you can > use the "is" operator. > > a is b > c is a > > etc. what id() does, never heard of that function before. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-06-16 12:26 +0100 |
| Message-ID | <mailman.3439.1371381967.3114.python-list@python.org> |
| In reply to | #48435 |
On 16/06/2013 12:06, Ferrous Cranus wrote: > > what id() does, never heard of that function before. > what google does, never heard of that function before. -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
| From | YBM <ybmess@nooos.fr.invalid> |
|---|---|
| Date | 2013-06-16 14:00 +0200 |
| Message-ID | <51bda8da$0$2272$426a34cc@news.free.fr> |
| In reply to | #48435 |
Le 16.06.2013 13:06, Ferrous Cranus a écrit : > what id() does, never heard of that function before. just type help(id) at Python prompt and stop flooding the group with superfluous demands.
[toc] | [prev] | [next] | [standalone]
| From | "R. Michael Weylandt" <michael.weylandt@gmail.com> |
|---|---|
| Date | 2013-06-16 13:04 +0100 |
| Message-ID | <mailman.3440.1371384296.3114.python-list@python.org> |
| In reply to | #48435 |
On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus <support@superhost.gr> wrote:
I appreciate you've returned to your Ferrous Cranus persona for this
interchange. It reminds me not to get hung up on concerns of
futility...
> On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote:
>>>
>>
>> ## CODE SNIPPET##
>> a = 552315251254
>> b = a
>> c = 552315251254
>>
>> a is b # True _on my machine_
>
>
> I accept this if in the premise that, b boils down to actually point to a's
> value, but it has to go through a first to find it, not directly.
You don't get to "accept it on a premise" or not. It's simply a matter of fact.
In fact, b does not go "through" a. The memory address referenced
exists even if the "a" binding is removed using "del a" or some other
mechanism. Imagine this scenario:
[a]
\
6
/
[b]
Using the name "a" or "b" simply tells Python where to look for a
value, but the value itself is not associated with "a" or "b" and will
only be removed if both a and b are del'd.
If we remove "a" while keeping "b" alive, we still have a means of
getting to "6" so Python's GC / RefCounter won't remove it. This
implies that the memory can't be solely "owned" by "a".
[a] # Binding gone now or perhaps referring to something else
6
/
[b]
And this pattern continues for any sort of Python object.
>
>> a is c # False _on my machine_
>
>
> Why false? These are 2 different memory locations storing the same number.
> This should have been True.
Again, you have the idea that you can use words like "should" here. It
either is or isn't. There's simply no normative claim involved.
>
> what id() does, never heard of that function before.
>
It seems you've also never heard of Python's "help" function?
Try
help(id)
at your interactive prompt and see what happens.
>
> --
> What is now proved was at first only imagined!
Depth of stubbornness?
[toc] | [prev] | [next] | [standalone]
| From | Ferrous Cranus <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 16:38 +0300 |
| Message-ID | <kpkf4t$f6p$1@news.ntua.gr> |
| In reply to | #48443 |
On 16/6/2013 3:04 μμ, R. Michael Weylandt wrote: > On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus <support@superhost.gr> wrote: > > I appreciate you've returned to your Ferrous Cranus persona for this > interchange. It reminds me not to get hung up on concerns of > futility... > >> On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote: >>>> >>> >>> ## CODE SNIPPET## >>> a = 552315251254 >>> b = a >>> c = 552315251254 >>> >>> a is b # True _on my machine_ > > And this pattern continues for any sort of Python object. >>> a is c # False _on my machine_ And in mine is also True. >>> id(a) 140160465571760 >>> id(b) 140160465571760 >>> id(c) 140160465571696 Since all object result to point to actual number 6 why don't all of them (a,b,c) bound to the same memory address. a and b seem both objects of the same identity, which means they are both bound to the same memory address(140160465571760) how come c's memory address is different than a's and b's ? After all, this is the 3rd object pointing to number 6. And why not d and e and f and g are all objects of the same memory address? > In fact, b does not go "through" a. The memory address referenced > exists even if the "a" binding is removed using "del a" or some other > mechanism. Imagine this scenario: > > [a] > \ > 6 > / > [b] > > Using the name "a" or "b" simply tells Python where to look for a > value, but the value itself is not associated with "a" or "b". If i understood you correctly, you say: unbounded memory address = value of 6 a = pointer to memory address that holds 6 b = pointer to memory address that holds 6 So, a and b, are two objects(two variable names if you want) that are bounded to the same memory address. And their value is the address of unbounded memory address. Correct? >> what id() does, never heard of that function before. >> > > It seems you've also never heard of Python's "help" function? > > Try > > help(id) > > at your interactive prompt and see what happens. No i had no idea thagt was a bult-in help() function. So id() is actually the memory address of an object which uniquely identifies it. -- 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:50 +0100 |
| Message-ID | <mailman.3450.1371408666.3114.python-list@python.org> |
| In reply to | #48450 |
On Sun, Jun 16, 2013 at 2:38 PM, Ferrous Cranus <support@superhost.gr> wrote:
> On 16/6/2013 3:04 μμ, R. Michael Weylandt wrote:
>>>> ## CODE SNIPPET##
>>>> a = 552315251254
>>>> b = a
>>>> c = 552315251254
>>>>
>>>> a is b # True _on my machine_
>
>>
>> And this pattern continues for any sort of Python object.
>>>> a is c # False _on my machine_
>
> And in mine is also True.
>
What do you mean "also true" here? You can't be "also true" in the
presence of a false. This makes little sense to me...
>
>>>> id(a)
> 140160465571760
>>>> id(b)
> 140160465571760
>>>> id(c)
> 140160465571696
>
> Since all object result to point to actual number 6 why don't all of them
> (a,b,c) bound to the same memory address.
Look at the code they follow. (At least in this email) -- none of them
point to an object with value 6. They all point to a much larger
value.
>
> a and b seem both objects of the same identity, which means they are both
> bound to the same memory address(140160465571760)
Yes
>
> how come c's memory address is different than a's and b's ?
> After all, this is the 3rd object pointing to number 6.
Again, no it's not.
>
> And why not d and e and f and g are all objects of the same memory address?
What are these variables? They are referenced nowhere in any mail
between you and me.
>
>
a and b are the same object, with two different names. (No "if I want"
about it -- the distinction is important)
No idea what you mean by "unbounded memory address" here. (Yes I'm
aware I deleted a fairly meaningless line about it from the context)
>
> No i had no idea thagt was a bult-in help() function.
> So id() is actually the memory address of an object which uniquely
> identifies it.
Yes.
I think part of your confusion is coming from the dual interpretation
of the "=" operator in an expression like:
LHS = RHS
If RHS is some sort of literal, a conforming Python behaves as if
(modulo optimizations described below) a new object is created
according to that literal, put in memory and the name LHS is used to
point to it.
If RHS is a name (as in code such as "a = b"), the Python will find
the object to which "b" refers and add a new reference ("a") to it.
Some information on the CPython specific implementation details:
As part of the startup process, CPython creates some number of small
integers and adds them to the object cache.
Why? Because creating an object (even as simple as an int) is
relatively expensive and small integers are ubiquitous in programming.
This sacrifices some memory for a good deal of speed. But the payoff
becomes less as you go higher: almost all programs will use a 0 or a
2, fewer will use 247. At some point, the pre-creation stops. I
believe this is a compile time option.
Now, to make effective use of this caching, CPython will use a few
tricks to try to identify when one of the small ints appears in the
code. If it can identify it, I will replace the object creation with a
reference to the in-cache object. The exact times when this can happen
are not -- to my knowledge -- documented anywhere.
Now you might ask why Python doesn't realize that, in code like my
code snippet above, it could simply reuse the same int object for a,
b, and c. Conceivably it could, but it would require enormous energies
to check all currently existing objects for one that happens to be
equal to what you need (and is not mutable if that's relevant) and
it's simply faster to create the new int.
Michael
[toc] | [prev] | [next] | [standalone]
| From | Mark Lawrence <breamoreboy@yahoo.co.uk> |
|---|---|
| Date | 2013-06-16 11:52 +0100 |
| Message-ID | <mailman.3434.1371379943.3114.python-list@python.org> |
| In reply to | #48427 |
On 16/06/2013 11:42, R. Michael Weylandt wrote: > >> >> Whats the difference of "interpreting " to "compiling" ? > > If only it could be googled.... Alas, no one has ever written anything > about technology on the internet. Ironic that... > > Michael > I'm very sorry but I don't understand the words "googled" and "internet". Could you please explain them? -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence
[toc] | [prev] | [next] | [standalone]
Page 5 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