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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Zero Piraeus <schesis@gmail.com> |
|---|---|
| Date | 2013-06-14 09:48 -0400 |
| Message-ID | <mailman.3307.1371217712.3114.python-list@python.org> |
| In reply to | #48143 |
:
On 14 June 2013 09:07, Nick the Gr33k <support@superhost.gr> wrote:
>
> Thanks for explaining this but i cannot follow its logic at all.
> My mind is stuck trying to interpret it as an English sentence:
>
> if ('Parker' and 'May' and '2001')
>
> if ('Parker' or 'May' or '2001')
>
> i just don't get it and i feel silly about it.
You've been advised many times to experiment in the Python
interpreter. I may be mistaken, but I don't recall seeing any evidence
at all that you've ever done so.
Try the following in a Python interpreter:
>>> "vic" and "bob"
>>> "bob" and "vic"
>>> "vic" or "bob"
>>> "bob" or "vic"
>>> "vic" and ""
>>> "" and "bob"
>>> "bob" or ""
>>> "" or "vic"
Carefully study the results you get. This is simple, basic stuff;
don't come back here asking for explanations of it. If you get stuck,
*carefully* read this article:
http://en.wikipedia.org/wiki/Short-circuit_evaluation
Repeat the steps above until you do understand. If all else fails,
google "short circuit logic" or "short circuit evaluation python" or
similar search terms, until you find a resource which you do follow.
-[]z.
[toc] | [prev] | [next] | [standalone]
| From | rusi <rustompmody@gmail.com> |
|---|---|
| Date | 2013-06-14 07:05 -0700 |
| Message-ID | <b5761aac-71fc-496d-bf88-42e77956e6e7@rh15g2000pbb.googlegroups.com> |
| In reply to | #48146 |
On Jun 14, 6:48 pm, Zero Piraeus <sche...@gmail.com> wrote:
> :
>
> On 14 June 2013 09:07, Nick the Gr33k <supp...@superhost.gr> wrote:
>
>
>
> > Thanks for explaining this but i cannot follow its logic at all.
> > My mind is stuck trying to interpret it as an English sentence:
>
> > if ('Parker' and 'May' and '2001')
>
> > if ('Parker' or 'May' or '2001')
>
> > i just don't get it and i feel silly about it.
>
> You've been advised many times to experiment in the Python
> interpreter. I may be mistaken, but I don't recall seeing any evidence
> at all that you've ever done so.
>
> Try the following in a Python interpreter:
>
> >>> "vic" and "bob"
> >>> "bob" and "vic"
> >>> "vic" or "bob"
> >>> "bob" or "vic"
> >>> "vic" and ""
> >>> "" and "bob"
> >>> "bob" or ""
> >>> "" or "vic"
>
> Carefully study the results you get. This is simple, basic stuff;
> don't come back here asking for explanations of it. If you get stuck,
> *carefully* read this article:
>
> http://en.wikipedia.org/wiki/Short-circuit_evaluation
>
> Repeat the steps above until you do understand. If all else fails,
> google "short circuit logic" or "short circuit evaluation python" or
> similar search terms, until you find a resource which you do follow.
>
> -[]z.
You get my prize 'Zero' for best answer!
[You've also given me a nice example for my next python class -- I
usually spend time showing how to play in the interpreter. And the
examples I usually give are numeric/string/list based. Short-circuit
evaluation is good to show. So thanks]
Incidentally, you have also proved right Nicolas' claim that this is
helpful to all :-) All that is needed is that other charitable-to-
Nick souls on this list should exercise some restraint and provide the
answers that they *know* he *needs* rather than what he *claims* to
*want*.
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-14 17:08 +0300 |
| Message-ID | <kpf84l$spl$17@news.ntua.gr> |
| In reply to | #48146 |
On 14/6/2013 4:48 μμ, Zero Piraeus wrote:
> :
>
> On 14 June 2013 09:07, Nick the Gr33k <support@superhost.gr> wrote:
>>
>> Thanks for explaining this but i cannot follow its logic at all.
>> My mind is stuck trying to interpret it as an English sentence:
>>
>> if ('Parker' and 'May' and '2001')
>>
>> if ('Parker' or 'May' or '2001')
>>
>> i just don't get it and i feel silly about it.
>
> You've been advised many times to experiment in the Python
> interpreter. I may be mistaken, but I don't recall seeing any evidence
> at all that you've ever done so.
>
> Try the following in a Python interpreter:
>
>>>> "vic" and "bob"
>>>> "bob" and "vic"
>>>> "vic" or "bob"
>>>> "bob" or "vic"
>>>> "vic" and ""
>>>> "" and "bob"
>>>> "bob" or ""
>>>> "" or "vic"
>
> Carefully study the results you get. This is simple, basic stuff;
> don't come back here asking for explanations of it. If you get stuck,
> *carefully* read this article:
>
> http://en.wikipedia.org/wiki/Short-circuit_evaluation
>
> Repeat the steps above until you do understand. If all else fails,
> google "short circuit logic" or "short circuit evaluation python" or
> similar search terms, until you find a resource which you do follow.
>
> -[]z.
>
(a or b or c)
is like saying True or True or True.
the first of these 3 variables that hasn;t as value an emptry string,
which means they contain a truthy value, that variable's value will be
returned
For 'and' operator, i do not understand it at all.
--
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-14 16:31 +0000 |
| Message-ID | <51bb454c$0$29997$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48143 |
On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:
> Thanks for explaining this but i cannot follow its logic at all. My mind
> is stuck trying to interpret it as an English sentence:
>
> if ('Parker' and 'May' and '2001')
>
> if ('Parker' or 'May' or '2001')
>
> i just don't get it and i feel silly about it.
Python is not English. You just have to accept that, no matter how much
you wish it worked like English, it does not.
Think of it like this:
"If today is Tuesday AND I finish work early, then I can go to the
movies."
Unless *both* conditions are true, I cannot go to the movies.
"If today is Tuesday AND I finish work early AND I have more than $16
spare cash to pay for a ticket, then I can go to the movies."
All three conditions must be true, or I cannot go to the movies.
If today is Monday, I don't need to check whether I finish work early, or
whether I have spare cash. It is enough to know that today is not
Tuesday, so I'm not going to the movies.
Python works the same way:
today_is_tuesday = True
finish_work_early = True
spare_cash = 11
if today_is_tuesday and finish_work_early and spare_cash > 16:
print("Going to the movies")
else:
print("No movies today.")
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-14 19:56 +0300 |
| Message-ID | <kpfhv1$4rq$2@news.ntua.gr> |
| In reply to | #48177 |
On 14/6/2013 7:31 μμ, Steven D'Aprano wrote:
> On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:
>
>> Thanks for explaining this but i cannot follow its logic at all. My mind
>> is stuck trying to interpret it as an English sentence:
>>
>> if ('Parker' and 'May' and '2001')
>>
>> if ('Parker' or 'May' or '2001')
>>
>> i just don't get it and i feel silly about it.
>
> Python is not English. You just have to accept that, no matter how much
> you wish it worked like English, it does not.
>
> Think of it like this:
>
> "If today is Tuesday AND I finish work early, then I can go to the
> movies."
>
> Unless *both* conditions are true, I cannot go to the movies.
>
>
> "If today is Tuesday AND I finish work early AND I have more than $16
> spare cash to pay for a ticket, then I can go to the movies."
>
> All three conditions must be true, or I cannot go to the movies.
>
>
> If today is Monday, I don't need to check whether I finish work early, or
> whether I have spare cash. It is enough to know that today is not
> Tuesday, so I'm not going to the movies.
>
>
> Python works the same way:
>
> today_is_tuesday = True
> finish_work_early = True
> spare_cash = 11
>
>
> if today_is_tuesday and finish_work_early and spare_cash > 16:
> print("Going to the movies")
> else:
> print("No movies today.")
>
It will print the latter since the overall boolean evaluation of the
expression is False since (spare_cash > 16) = False
That's understandable and works just like an English sentence, but in
this example it was easy since you assigned the vars values to be either
True or False.
This is my difficulty.
a = 'abcd'
b = 'efgh'
c = 'ijkl'
>>> (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?
Returning True is the same thing as returning a variable's truthy value?
>>> (a and b and c)
'ijkl'
This in my head should have been evaluated to True also since all 3
strings hold truthy values
Why on earth this boolean expression evaluates to the value of the last
variable? This is what can't at all seem to follow.
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.
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-15 03:18 +1000 |
| Message-ID | <mailman.3324.1371230285.3114.python-list@python.org> |
| In reply to | #48182 |
On Sat, Jun 15, 2013 at 2:56 AM, Nick the Gr33k <support@superhost.gr> wrote: > 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. Okay, now we get to the nub of the matter. In some languages, what you say is the case. In C, for instance, 3 || 4 == 1 (C doesn't have dedicated True and False types, it uses 1 and 0). But there are very few situations where you actually need it to specifically be the boolean values, and plenty where you can make use of this additional feature. If you want to demand a bool from Python, there is a way to do this. Experiment with bool() in the interactive interpreter. ChrisA
[toc] | [prev] | [next] | [standalone]
| 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]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.python
csiph-web