Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #47884 > unrolled thread
| Started by | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| First post | 2013-06-13 01:55 +0000 |
| Last post | 2013-06-14 10:05 +0100 |
| Articles | 20 on this page of 115 — 33 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| 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]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2013-06-16 10:51 +0000 |
| Message-ID | <kpk5bj$ifk$1@dont-email.me> |
| In reply to | #48427 |
On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote: > Whats the difference of "interpreting " to "compiling" ? OK, I give up! -- Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 12:07 +0000 |
| Subject | Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51bdaa78$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48432 |
On Sun, 16 Jun 2013 10:51:31 +0000, Denis McMahon wrote: > On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote: > >> Whats the difference of "interpreting " to "compiling" ? > > OK, I give up! Actually, that's a more subtle question than most people think. Python, for example, is a compiled language. (What did you think the "c" in ".pyc" files stood for? and the compile() function>?) It is compiled to byte-code, which runs on a virtual machine, rather than machine-code, which runs on a physical machine. Except PyPy, which *is* compiled to machine-code. Except that it doesn't do so at compile time, but on the fly at run-time. And these days, for many types of hardware, even machine-code is often interpreted by a virtual machine on a chip. And even languages which compile to machine-code often use an intermediate platform-independent form rather than targeting pure machine-code. The line between compilers and interpreters is quite fuzzy. Probably the best definition I've seen for the difference between a modern compiler and interpreter is this one: "...the distinguishing feature of interpreted languages is not that they are not compiled, but that the compiler is part of the language runtime and that, therefore, it is possible (and easy) to execute code generated on the fly." -- Roberto Ierusalimschy, "Programming In Lua", 2nd Edition, p. 63 -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Mark Janssen <dreamingforward@gmail.com> |
|---|---|
| Date | 2013-06-16 12:31 -0700 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3453.1371411127.3114.python-list@python.org> |
| In reply to | #48444 |
>>> Whats the difference of "interpreting " to "compiling" ? >> >> OK, I give up! > > Actually, that's a more subtle question than most people think. Python, > for example, is a compiled language. (What did you think the "c" in > ".pyc" files stood for? and the compile() function>?) Careful there. This terminology is not agreed upon universally (that is, within the realm of academia where the notion of mastery exists), and unless you are citing an actual reference or publishing one yourself, then you may be adding more confusion than illumination. For example, I would say that it is an *interpreted language* that gets compiled at run-time. Some (*valid*) definitions of "compiler" mean a strict mapping from the language syntax and lexical definition to a sequence of bytes that can be fed to a (hardware not virtual) machine architecture to do perform what is requested. The face that an extension ends in the letter "c" is not sufficient evidence, since file extensions have no strict standard. > And these days, for many types of hardware, even machine-code is often > interpreted by a virtual machine on a chip. And even languages which > compile to machine-code often use an intermediate platform-independent > form rather than targeting pure machine-code. Do you have a reference for this? What language? > The line between compilers > and interpreters is quite fuzzy. It shouldn't be. What is fuzzy is the definition of "interpreter", however. The definition of compiler has only become fuzzy with the advent of the personal computer. > Probably the best definition I've seen for the difference between a > modern compiler and interpreter is this one: > > "...the distinguishing feature of interpreted languages is not that they > are not compiled, but that the compiler is part of the language runtime > and that, therefore, it is possible (and easy) to execute code generated > on the fly." That's reasonable. -- MarkJ Tacoma, Washington
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 20:02 +0000 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51be19f1$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48471 |
On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote: >>>> Whats the difference of "interpreting " to "compiling" ? >>> >>> OK, I give up! >> >> Actually, that's a more subtle question than most people think. Python, >> for example, is a compiled language. (What did you think the "c" in >> ".pyc" files stood for? and the compile() function>?) > > Careful there. This terminology is not agreed upon universally Which is why I said it was a more subtle question than most people think. Most people think that there is One True Definition of compiling/ interpreting, usually based on an over-simplified model of program execution that was obsolete in the 1970s. > (that > is, within the realm of academia where the notion of mastery exists), The notion of mastery exists in many places, not just academia. > and unless you are citing an actual reference or publishing one > yourself, then you may be adding more confusion than illumination. For > example, I would say that it is an *interpreted language* that gets > compiled at run-time. Apart from the contradiction there -- if it is compiled, why do you insist on calling it interpreted? -- you would be wrong. Languages are neither interpreted nor compiled. Languages are abstract entities that describe what syntax is permitted, and what functionality is provided. It is only concrete implementations which are interpreted or compiled. In the case of Python, we have: CPython: compiled to byte-code for it's own virtual machine; Jython: compiled to byte-code for the JRE; IronPython: compiled to byte-code for the .Net runtime; PyPy: JIT compiler that generates machine code; Nuitka: static compiler that generates machine code; etc. So, the answer to the question "Is Python compiled or interpreted?" is, "Yes." [...] >> And these days, for many types of hardware, even machine-code is often >> interpreted by a virtual machine on a chip. And even languages which >> compile to machine-code often use an intermediate platform-independent >> form rather than targeting pure machine-code. > > Do you have a reference for this? What language? https://en.wikipedia.org/wiki/Microcode >> The line between compilers >> and interpreters is quite fuzzy. > > It shouldn't be. Of course it should be, because that reflects reality. > What is fuzzy is the definition of "interpreter", > however. The definition of compiler has only become fuzzy with the > advent of the personal computer. Incorrect. Lisp predates the PC, and it is a good example of a language with implementations which combine features of compile-to-machine-code and execute-high-level-code-at-run-time (i.e. both "compiler" and "interpreter" behaviour, at the same time). Lisp is nearly as old as Fortran. Forth is another such language. It's not quite so old as Lisp, but it is especially interesting because Forth includes commands to switch from "compile mode" to "interpret mode" on the fly. So is it a compiler or an interpreter? Yes. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-17 08:26 +1000 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3463.1371421585.3114.python-list@python.org> |
| In reply to | #48476 |
On Mon, Jun 17, 2013 at 6:02 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote: >>> The line between compilers >>> and interpreters is quite fuzzy. >> >> It shouldn't be. > > Of course it should be, because that reflects reality. It's fuzzy AND it seldom even matters. Compare these three text strings: """'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'"""" """'a'*64""" """\37\213\b\b*8\276Q\0\3test\0KL\244\f\0\0Ue\264\211@\0\0\0""" """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" Which of these is an interpreted program? I would say: All of them. And they all produce the same output, a series of 64 copies of the letter a. The third one is interpreted by gzip(1) and will create a file called 'test', the fourth is a raw gzip/zlib stream and so is interpreted by (eg) the Python zlib.decompress() function. They're all languages, of a sort. Are they interpreted/compiled versions of that message? Kinda. If you prepend a sfx header to them, do they become compiled and not interpreted? Doubtful. I don't think you could say that this ceases to be interpreted: import zlib print(zlib.decompress( """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" )) Even if you manually imported the code for zlib.decompress, in a way that makes it impossible for your cut-down program to actually compress data (which then breaks the principle quoted from "Programming in Lua"), it's still fairly clearly being interpreted/parsed the exact same way. So it really doesn't matter (so it really doesn't matter (so it really doesn't matter)). [1] ChrisA [1] http://math.boisestate.edu/gas/ruddigore/web_opera/rudd24.html
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-06-16 23:13 -0400 |
| Subject | Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3467.1371438818.3114.python-list@python.org> |
| In reply to | #48444 |
On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen
<dreamingforward@gmail.com> declaimed the following:
>Careful there. This terminology is not agreed upon universally (that
>is, within the realm of academia where the notion of mastery exists),
>and unless you are citing an actual reference or publishing one
>yourself, then you may be adding more confusion than illumination.
>For example, I would say that it is an *interpreted language* that
>gets compiled at run-time. Some (*valid*) definitions of "compiler"
>mean a strict mapping from the language syntax and lexical definition
>to a sequence of bytes that can be fed to a (hardware not virtual)
>machine architecture to do perform what is requested. The face that
>an extension ends in the letter "c" is not sufficient evidence, since
>file extensions have no strict standard.
>
And I'd tend to consider it a Byte-Code Interpreted language (a la UCSD
P-code Pascal). I also consider standard Java to be such.
In contrast, I consider "compiled" to mean the end result of the
compilation step is native instruction set for the processor. And true
"interpreted" is more like classic BASIC (which /tokenized/ the program but
the tokens mapped 1:1 with the source keywords. Tokenization saved a few
bytes as "while" and "for" condensed to single bytes -- but then needed
long subroutines at run time to actually process them.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Jussi Piitulainen <jpiitula@ling.helsinki.fi> |
|---|---|
| Date | 2013-06-16 14:13 +0300 |
| Message-ID | <qot8v2al34n.fsf@ruuvi.it.helsinki.fi> |
| In reply to | #48427 |
Nick the Gr33k writes: > On 16/6/2013 12:22 μμ, Denis McMahon wrote: > > For example, in Python > > > > a = 6 > > b = a > > c = 6 > > > > a and b point to one memory location that contains the value 6 > > c points to a different memory location that contains the value 6 > > I believe you are mistaken. > > a here is not a pointer but variable, > which is a memory location that stores value 6. > > b here is a pointer. It's value is the memory location of variable a > which stores value 6. > > c here is just te same as a , a variable. b is also just like a. All the talk about pointers and memory locations is intended to explain how things do or do not change. (Or, sometimes, how the behaviour is implemented.) If, instead of the above, you have a = 6 b = a b = 5 you will find that b == 5 and a == 6. So b is not the same as a. Else one would have changed when the other changed. I would say that a and b are different variables. They had the same value, briefly. What does same mean? Think of mutable objects. A dictionary, for example: a = dict(x = 3) b = a b.update(x = 31) You will find that the value of a changed when the value of b changed. It's the same value. Values do not get copied in Python when you pass them around. This is implemented with pointers and memory locations, but in Python these implementation details are normally hidden behind the scenes. Python is far from unique in this regard.
[toc] | [prev] | [next] | [standalone]
| From | Ferrous Cranus <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 16:47 +0300 |
| Message-ID | <kpkfm2$f6p$2@news.ntua.gr> |
| In reply to | #48438 |
On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: > If, instead of the above, you have > > a = 6 > b = a > b = 5 > > you will find that b == 5 and a == 6. So b is not the same as a. Else > one would have changed when the other changed. I would say that a and > b are different variables. They had the same value, briefly. If they were different variables then they would have different memory addresses and they would act like two different objects. But... both a and b are for a fact mappings for the same memory address as seen form the following command. >>> id(a) == id(b) True They are like the same object with 2 different names. Like i'am a human being and me Greek friends call me "Νίκος" while you guys call me "Nick". That the way i understand it so far. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | "R. Michael Weylandt" <michael.weylandt@gmail.com> |
|---|---|
| Date | 2013-06-16 19:53 +0100 |
| Message-ID | <mailman.3451.1371408858.3114.python-list@python.org> |
| In reply to | #48452 |
On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <support@superhost.gr> wrote: > On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: >> >> If, instead of the above, you have >> >> a = 6 >> b = a >> b = 5 >> >> you will find that b == 5 and a == 6. So b is not the same as a. Else >> one would have changed when the other changed. I would say that a and >> b are different variables. They had the same value, briefly. > > > If they were different variables then they would have different memory > addresses and they would act like two different objects. > > But... both a and b are for a fact mappings for the same memory address as > seen form the following command. > >>>> id(a) == id(b) > True > > They are like the same object with 2 different names. This will depend on when the test is run: a = 6 b = a a is b # True b = 5 a is b # False The latter is false because the binding of "b" to the int 6 was broken in order to bind b to the int 5. I might also suggest you restrain from trying to correct respondents on these matters until you yourself understand them. It's only polite. Michael
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 08:17 +0300 |
| Message-ID | <kpm65s$250s$2@news.ntua.gr> |
| In reply to | #48467 |
On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote: > On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus <support@superhost.gr> wrote: >> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote: >>> >>> If, instead of the above, you have >>> >>> a = 6 >>> b = a >>> b = 5 >>> >>> you will find that b == 5 and a == 6. So b is not the same as a. Else >>> one would have changed when the other changed. I would say that a and >>> b are different variables. They had the same value, briefly. >> >> >> If they were different variables then they would have different memory >> addresses and they would act like two different objects. >> >> But... both a and b are for a fact mappings for the same memory address as >> seen form the following command. >> >>>>> id(a) == id(b) >> True >> >> They are like the same object with 2 different names. > > This will depend on when the test is run: > > a = 6 > b = a > a is b # True > > b = 5 > a is b # False > > The latter is false because the binding of "b" to the int 6 was broken > in order to bind b to the int 5. Very surprising. a and b was *references* to the same memory address, it was like a memory address having 2 names to be addresses as. b = a name we use to address some memory location, do we agree on that? So, b = 6, must have changed the stored value of its mapped memory location, but given you example it seems its changing the mapping of b to some other memory address. I don't follow its act of course. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-17 06:51 +0000 |
| Subject | Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <51beb20c$0$29872$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48493 |
On Mon, 17 Jun 2013 08:17:48 +0300, Νίκος wrote:
[...]
>> The latter is false because the binding of "b" to the int 6 was broken
>> in order to bind b to the int 5.
>
> Very surprising.
> a and b was *references* to the same memory address, it was like a
> memory address having 2 names to be addresses as.
>
> b = a name we use to address some memory location, do we agree on that?
>
> So, b = 6, must have changed the stored value of its mapped memory
> location, but given you example it seems its changing the mapping of b
> to some other memory address.
>
> I don't follow its act of course.
Let me explain how variables work in some other languages, and how they
work in Python. (And Ruby, and Java, and many others.)
In a language like Pascal, or C, the compiler keeps a table mapping
variable names to fixed memory addresses, like this:
Variable Address
======== =======
x 10234
y 10238
z 10242
Code like:
x := 42;
y := x + 1;
will get compiled into something that looks like this:
# Pseudo-code
STORE 42 AT ADDRESS 10234;
READ ADDRESS 10234;
STORE (LAST RESULT + 1) AT ADDRESS 10238;
The important thing is that memory addresses are known at compile time,
and at least in general, variables cannot move around in memory. Another
important thing is that assignment is copying:
x := y;
becomes:
READ ADDRESS 10234;
STORE (LAST RESULT) AT ADDRESS 10238;
which is equivalent to:
COPY ADDRESS 10234 TO ADDRESS 10238;
If, instead of an integer, x was an array of 1000 integers, all 1000
integers would need to be copied.
Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:
global namespace:
x --> 23
y --> "hello world"
In Python, namespaces are *dicts*, just like those you create with {}.
Code like:
x = 42
y = x + 1
is treated as:
# Pseudocode
create the object 42
bind it to the name 'x'
look up the name 'x'
add 1 to it
bind it to the name 'y'
where "bind" means to change the association in the namespace:
global namespace:
x --> 42
y --> 43
One important thing is that binding does *not* make a copy of the object.
Assignment is equally fast whether you have one int or a list or a
million ints. So code like this:
x = y
results in both names 'x' and 'y' being associated to the same object.
With ints, that's pretty boring, but for mutable objects like lists, it
means that you get two names for the same list:
py> x = []
py> y = x
py> y.append("Surprise!")
py> x
['Surprise!']
This sort of behaviour is trivial in languages with name-binding
semantics, like Python, but quite tricky in languages like Pascal. You
have to explicitly work with pointers or other indirect memory access,
leading to extra effort and the possibility of serious bugs.
Note also that because you aren't dealing with fixed memory addresses,
objects are free to be moved in memory for better memory usage and less
fragmentation. CPython doesn't do this, but PyPy does, and I expect that
both Jython and IronPython probably do too. So long as the runtime
environment can (somehow) track when objects are moved, it all works out
fine.
Another difference is that in C-like languages, variables always have a
value, even if it's not a useful value. As soon as the compiler decides
that variable 'z' will be at address 10242, then 'z' has an implied value
made up of whatever junk happens to be at that address. Some compilers
will warn you if you try to use a variable without assigning to it first,
since using junk you happen to find lying around in memory is usually a
bad thing, but not all compilers.
In contrast, Python doesn't have this issue. If you haven't assigned to
'z', then there is no such thing as 'z' in your namespace, and trying to
use it will automatically give you an error:
py> x = z - 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'z' is not defined
There are other differences in regards to passing arguments to functions.
I've written about that before:
http://mail.python.org/pipermail/tutor/2010-December/080505.html
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Simpleton <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 14:34 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpms91$20d$2@news.ntua.gr> |
| In reply to | #48500 |
On 17/6/2013 9:51 πμ, Steven D'Aprano wrote: > Now, in languages like Python, Ruby, Java, and many others, there is no > table of memory addresses. Instead, there is a namespace, which is an > association between some name and some value: > > global namespace: > x --> 23 > y --> "hello world" First of all thanks for the excellent and detailed explanation Steven. As for namespace: a = 5 1. a is associated to some memory location 2. the latter holds value 5 So 'a', is a reference to that memory location, so its more like a name to that memory location, yes? Instead of accessing a memory address with a use of an integer like "14858485995" we use 'a' instead. So is it safe to say that in Python a == &a ? (& stands for memory address) is the above correct? I say this because here you said that: Instead, there is a namespace, which is anassociation between some name and some value: When you say that you mean that a is associated to some value as in memory location or to that memory location's address? -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-06-17 05:58 -0600 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <mailman.3479.1371470335.3114.python-list@python.org> |
| In reply to | #48514 |
On 06/17/2013 05:34 AM, Simpleton wrote: > So is it safe to say that in Python a == &a ? (& stands for memory address) > > is the above correct? It might be partially equivalent inside the interpreter, but it's not something you should concern yourself with. And in general, no it's not safe to say, since Python is a reference-counted, garbage-collected object system and pointers in C certainly are not. > I say this because here you said that: Instead, there is a namespace, > which is anassociation between some name and some value: > > When you say that you mean that a is associated to some value as in > memory location or to that memory location's address? In python just think of assignment as making a name *be* an object. And if you assign one name to another name, that makes both names be the same object. When names are unbound (either they go out of scope or you manually unbind them), the objects they are bound to are garbage collected. Forget about the details of how the interpreter might doing at a low level.
[toc] | [prev] | [next] | [standalone]
| From | Simpleton <support@superhost.gr> |
|---|---|
| Date | 2013-06-17 18:50 +0300 |
| Subject | Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.] |
| Message-ID | <kpnb7t$k63$1@news.ntua.gr> |
| In reply to | #48516 |
On 17/6/2013 2:58 μμ, Michael Torrie wrote: > In python just think of assignment as making a name *be* an object. And > if you assign one name to another name, that makes both names be the > same object. When names are unbound (either they go out of scope or you > manually unbind them), the objects they are bound to are garbage collected. "Object" here being the memory location, right? When we say a = 5 a = an easy way for calling that "fixed memory location" that holds our value, instead of calling it in binary format or in hex format. This is the direct object a is pointing too. Correct? 5 = *this* is the indirect object that a outputs when we print a. Are the above statements correct Michael? a = 5 b = a a <---> memory address b <---> memory address I like to think a and b as references to the same memory address -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web