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 | 15 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-14 19:12 +1000 |
| Message-ID | <mailman.3277.1371201144.3114.python-list@python.org> |
| In reply to | #48094 |
On Fri, Jun 14, 2013 at 7:00 PM, Nick the Gr33k <support@superhost.gr> wrote: > but i really wont to understand how 'or' and 'and' works inside an > expression. please answer my previous post if you know. *eyeroll* You have all the information. Go play with it in the interactive interpreter until you understand. Seriously. That interpreter wants to be your friend, just extend a hand and say "Hi"! Become familiar with Python that way. Don't expect everything to be answered on-list. ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-14 12:47 +0300 |
| Message-ID | <kpeorl$spl$7@news.ntua.gr> |
| In reply to | #48098 |
On 14/6/2013 12:12 μμ, Chris Angelico wrote: > On Fri, Jun 14, 2013 at 7:00 PM, Nick the Gr33k <support@superhost.gr> wrote: >> but i really wont to understand how 'or' and 'and' works inside an >> expression. please answer my previous post if you know. > > *eyeroll* > > You have all the information. Go play with it in the interactive > interpreter until you understand. Seriously. That interpreter wants to > be your friend, just extend a hand and say "Hi"! Become familiar with > Python that way. Don't expect everything to be answered on-list. > > ChrisA > but i'm doing this all day long i just dont comprehend why it works this way. it doesn't make any sense to me. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Tim Roberts <timr@probo.com> |
|---|---|
| Date | 2013-06-15 18:55 -0700 |
| Message-ID | <ro5qr89r11ebtqif6hr9egkkr1s4ecogef@4ax.com> |
| In reply to | #48105 |
Nick the Gr33k <support@superhost.gr> wrote:
>
>but i'm doing this all day long i just dont comprehend why it works this
>way.
>it doesn't make any sense to me.
It's just a rule you'll have to learn. The "and" and "or" operators in
Python simply do not return a boolean value. The expression "a or b" is
evaluated as:
if a is true then return a otherwise return b
It's true that in many languages, "or" returns a Boolean value, so the
result is:
if a is true then return True otherwise return bool(b)
Because Python lets you use arbitrary values in a Boolean context, the net
result is exactly the same. However, the Python is a lot more flexible,
because it lets you simulate the C ternary ?: operator.
Similarly, "a and b" is evaluated as:
if a is false then return a otherwise return b
In a long series separated by "or", the expression is true as soon as one
of the subexpressions is true. So, as a short-circuit, Python simply
returns the first one that has a "true" value. So, for example, these all
return 'abcd':
'abcd' or 'defg' or 'hjkl' ==> 'abcd'
0 or 'abcd' or 'defg' or 'hjkl' ==> 'abcd'
0 or None or 'abcd' or 'defg' or 'hjkl' ==> 'abcd'
Similarly, "and" returns the first "false" value, or if they're all true,
the last value. Why? Because it can't know whether the whole expression
is true unless it looks at every value. So:
0 and 1 and 'what' ==> 0
1 and 0 and 'what' ==> 0
1 and None and 0 ==> None
1 and 1 and 'what' ==> 'what'
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-16 05:09 +0000 |
| Message-ID | <51bd48a0$0$29966$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48399 |
On Sat, 15 Jun 2013 18:55:05 -0700, Tim Roberts wrote: > Nick the Gr33k <support@superhost.gr> wrote: >> >>but i'm doing this all day long i just dont comprehend why it works this >>way. it doesn't make any sense to me. > > It's just a rule you'll have to learn. The "and" and "or" operators in > Python simply do not return a boolean value. The expression "a or b" is > evaluated as: > if a is true then return a otherwise return b I prefer to say that as "if a is true-ish then return a otherwise return b" or even "if a quacks like a true value then return a otherwise return b" to emphasis that this is a form of duck-typing, and avoid any confusion with "if a is True". But otherwise, well said. -- Steven
[toc] | [prev] | [next] | [standalone]
| From | Nick the Gr33k <support@superhost.gr> |
|---|---|
| Date | 2013-06-16 11:20 +0300 |
| Message-ID | <kpjsfi$hmp$2@news.ntua.gr> |
| In reply to | #48399 |
On 16/6/2013 4:55 πμ, Tim Roberts wrote: > Nick the Gr33k <support@superhost.gr> wrote: > Because Python lets you use arbitrary values in a Boolean context, the net > result is exactly the same. What is an arbitrary value? don even knwo what arbitrary means literally in English. > In a long series separated by "or", the expression is true as soon as one > of the subexpressions is true. So, as a short-circuit, Python simply > returns the first one that has a "true" value. So, for example, these all > return 'abcd': > > 'abcd' or 'defg' or 'hjkl' ==> 'abcd' > 0 or 'abcd' or 'defg' or 'hjkl' ==> 'abcd' > 0 or None or 'abcd' or 'defg' or 'hjkl' ==> 'abcd' > > Similarly, "and" returns the first "false" value, or if they're all true, > the last value. Why? Because it can't know whether the whole expression > is true unless it looks at every value. So: > > 0 and 1 and 'what' ==> 0 > 1 and 0 and 'what' ==> 0 > 1 and None and 0 ==> None > 1 and 1 and 'what' ==> 'what' > Thank you Tim. I decided that it's better to thing it through as: The argument being returned in an "and" or "or" expression is the one that *determined' the evaluation of the expression. And actually what's being returned is not the argument itself but the argument's value. -- What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Tim Roberts <timr@probo.com> |
|---|---|
| Date | 2013-06-18 22:08 -0700 |
| Message-ID | <e2e2s8pbfbvequ26icu1avilqjcod48san@4ax.com> |
| In reply to | #48419 |
Nick the Gr33k <support@superhost.gr> wrote:
>
>On 16/6/2013 4:55 ??, Tim Roberts wrote:
>
>> Nick the Gr33k <support@superhost.gr> wrote:
>> Because Python lets you use arbitrary values in a Boolean context, the net
>> result is exactly the same.
>
>What is an arbitrary value? don even knwo what arbitrary means literally
>in English.
Basically, it means "any". In Python, you can use ANY value where a
Boolean is expected. All types have a Boolean meaning. For integers, 0 is
false, anything else is true. For strings, an empty string "" is false,
anything else is true. For lists, an empty list [] is false, anything else
is true. For tuples, an empty tuple () is false, anything else is true.
For dicts, an empty dict {} is false, anything else is true.
>The argument being returned in an "and" or "or" expression is the one
>that *determined' the evaluation of the expression.
That's not exactly how I'd put it, but the statement is correct. The last
thing it had to evaulate is the result of the expression.
>And actually what's being returned is not the argument itself but the
>argument's value.
But this is no different than any other programming language. Expressions
always use the value of their operands, and they always return a value.
The name vs value thing is critical to understanding Python, in my opinion,
and it can be a stumbling block when you're coming from another language.
Here's how I think about it.
Python had two distinct spaces: there is a space for names, and there is a
space for objects (which are values). Objects live in a nameless, faceless
object cloud.
A name is always bound to some object (which might be the "None" object). A
name always knows its object, but an object never knows what names it is
bound to.
The only things that can be used in expressions and function arguments are
objects. Names are merely the way we specify which objects to be used.
a = [3]
That creates a nameless list containing a single integer object with the
value 3. It then binds the name "a" to that list. Note that the list has
no clue that it is bound to any names.
b = a
That binds "b" to the same list. "b" and "a" are not related in any way,
except that they happen to be bound to the same object. Note that there is
still only one list.
a.append(4)
That modifies the list so that it now contains [3,4]. b is bound to the
same list, so if you
print(b)
you'll see [3,4]
Now, let's say I do this:
a = [5]
Here's where people get tripped up. This does not change our original
list. Instead, it creates a new nameless list containing 5, and binds the
name a to that list. a and b are no longer bound to the same object.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-19 01:42 -0400 |
| Message-ID | <mailman.3568.1371620544.3114.python-list@python.org> |
| In reply to | #48685 |
I think this is an excellent description of name binding with mutable
objects. I just have one clarification to insert below.
On 06/19/2013 01:08 AM, Tim Roberts wrote:
> Nick the Gr33k <support@superhost.gr> wrote:
>>
>> On 16/6/2013 4:55 ??, Tim Roberts wrote:
>>
>>> Nick the Gr33k <support@superhost.gr> wrote:
>>> Because Python lets you use arbitrary values in a Boolean context, the net
>>> result is exactly the same.
>>
>> What is an arbitrary value? don even knwo what arbitrary means literally
>> in English.
>
> Basically, it means "any". In Python, you can use ANY value where a
> Boolean is expected. All types have a Boolean meaning. For integers, 0 is
> false, anything else is true. For strings, an empty string "" is false,
> anything else is true. For lists, an empty list [] is false, anything else
> is true. For tuples, an empty tuple () is false, anything else is true.
> For dicts, an empty dict {} is false, anything else is true.
>
>> The argument being returned in an "and" or "or" expression is the one
>> that *determined' the evaluation of the expression.
>
> That's not exactly how I'd put it, but the statement is correct. The last
> thing it had to evaulate is the result of the expression.
>
>> And actually what's being returned is not the argument itself but the
>> argument's value.
>
> But this is no different than any other programming language. Expressions
> always use the value of their operands, and they always return a value.
>
> The name vs value thing is critical to understanding Python, in my opinion,
> and it can be a stumbling block when you're coming from another language.
> Here's how I think about it.
>
> Python had two distinct spaces: there is a space for names, and there is a
> space for objects (which are values). Objects live in a nameless, faceless
> object cloud.
>
> A name is always bound to some object (which might be the "None" object). A
> name always knows its object, but an object never knows what names it is
> bound to.
>
> The only things that can be used in expressions and function arguments are
> objects. Names are merely the way we specify which objects to be used.
Names are *one of* the ways we specify which objects are to be used.
(We can also specify objects via an container and a subscript or slice,
or via an attribute of another object. And probably another way or two.)
>
> a = [3]
>
> That creates a nameless list containing a single integer object with the
> value 3. It then binds the name "a" to that list. Note that the list has
> no clue that it is bound to any names.
>
> b = a
>
> That binds "b" to the same list. "b" and "a" are not related in any way,
> except that they happen to be bound to the same object. Note that there is
> still only one list.
>
> a.append(4)
>
> That modifies the list so that it now contains [3,4]. b is bound to the
> same list, so if you
> print(b)
> you'll see [3,4]
>
> Now, let's say I do this:
>
> a = [5]
>
> Here's where people get tripped up. This does not change our original
> list. Instead, it creates a new nameless list containing 5, and binds the
> name a to that list. a and b are no longer bound to the same object.
>
--
DaveA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-19 17:14 +1000 |
| Message-ID | <mailman.3570.1371626065.3114.python-list@python.org> |
| In reply to | #48685 |
On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel <davea@davea.name> wrote: > Names are *one of* the ways we specify which objects are to be used. (We can > also specify objects via an container and a subscript or slice, or via an > attribute of another object. And probably another way or two.) But you always have to bootstrap it with either a name. Or a literal. So those are the only two ways to specify which objects are to be used. (Anyone fanatically devoted to nice red uniforms?) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Νίκος <support@superhost.gr> |
|---|---|
| Date | 2013-06-19 10:49 +0300 |
| Message-ID | <kprnpm$2mj$1@news.grnet.gr> |
| In reply to | #48685 |
Στις 19/6/2013 8:08 πμ, ο/η Tim Roberts έγραψε:
> Nick the Gr33k <support@superhost.gr> wrote:
>>
>> On 16/6/2013 4:55 ??, Tim Roberts wrote:
>>
>>> Nick the Gr33k <support@superhost.gr> wrote:
>>> Because Python lets you use arbitrary values in a Boolean context, the net
>>> result is exactly the same.
>>
>> What is an arbitrary value? don even knwo what arbitrary means literally
>> in English.
>
> Basically, it means "any". In Python, you can use ANY value where a
> Boolean is expected. All types have a Boolean meaning. For integers, 0 is
> false, anything else is true. For strings, an empty string "" is false,
> anything else is true. For lists, an empty list [] is false, anything else
> is true. For tuples, an empty tuple () is false, anything else is true.
> For dicts, an empty dict {} is false, anything else is true.
>
>> The argument being returned in an "and" or "or" expression is the one
>> that *determined' the evaluation of the expression.
>
> That's not exactly how I'd put it, but the statement is correct. The last
> thing it had to evaulate is the result of the expression.
>
>> And actually what's being returned is not the argument itself but the
>> argument's value.
>
> But this is no different than any other programming language. Expressions
> always use the value of their operands, and they always return a value.
>
> The name vs value thing is critical to understanding Python, in my opinion,
> and it can be a stumbling block when you're coming from another language.
> Here's how I think about it.
>
> Python had two distinct spaces: there is a space for names, and there is a
> space for objects (which are values). Objects live in a nameless, faceless
> object cloud.
>
> A name is always bound to some object (which might be the "None" object). A
> name always knows its object, but an object never knows what names it is
> bound to.
>
> The only things that can be used in expressions and function arguments are
> objects. Names are merely the way we specify which objects to be used.
>
> a = [3]
>
> That creates a nameless list containing a single integer object with the
> value 3. It then binds the name "a" to that list. Note that the list has
> no clue that it is bound to any names.
>
> b = a
>
> That binds "b" to the same list. "b" and "a" are not related in any way,
> except that they happen to be bound to the same object. Note that there is
> still only one list.
>
> a.append(4)
>
> That modifies the list so that it now contains [3,4]. b is bound to the
> same list, so if you
> print(b)
> you'll see [3,4]
>
> Now, let's say I do this:
>
> a = [5]
>
> Here's where people get tripped up. This does not change our original
> list. Instead, it creates a new nameless list containing 5, and binds the
> name a to that list. a and b are no longer bound to the same object.
>
Thank you very much Tim for the simply and detailed put explanation.
--
What is now proved was at first only imagined!
[toc] | [prev] | [next] | [standalone]
| From | Dave Angel <davea@davea.name> |
|---|---|
| Date | 2013-06-19 04:06 -0400 |
| Message-ID | <mailman.3575.1371629183.3114.python-list@python.org> |
| In reply to | #48685 |
On 06/19/2013 03:14 AM, Chris Angelico wrote:
> On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel <davea@davea.name> wrote:
>> Names are *one of* the ways we specify which objects are to be used. (We can
>> also specify objects via an container and a subscript or slice, or via an
>> attribute of another object. And probably another way or two.)
>
> But you always have to bootstrap it with either a name.
Whatever bootstrap really means in this context. But if you have
myname[3] + myname[5], the two objects being added are identified by a
subscript operation, not just a name.
> Or a literal.
A literal is used to create an object, and acts like a temporary name
for that object, but once again the object being operated on isn't
necessarily that one. You can subscript and get attributes from a
literal as well.
> So those are the only two ways to specify which objects are to be
> used.
>
That would be a pretty weak language, and it wouldn't be python.
Now if you considered "." and "[" as operators, then I could understand
your point. But
http://docs.python.org/3/reference/lexical_analysis.html#operators
seems to say differently.
Also see
http://docs.python.org/3/reference/expressions.html#primaries
--
DaveA
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-19 18:21 +1000 |
| Message-ID | <mailman.3576.1371630102.3114.python-list@python.org> |
| In reply to | #48685 |
On Wed, Jun 19, 2013 at 6:06 PM, Dave Angel <davea@davea.name> wrote: > On 06/19/2013 03:14 AM, Chris Angelico wrote: >> >> On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel <davea@davea.name> wrote: >>> >>> Names are *one of* the ways we specify which objects are to be used. (We >>> can >>> also specify objects via an container and a subscript or slice, or via an >>> attribute of another object. And probably another way or two.) >> >> >> But you always have to bootstrap it with either a name. > > > Whatever bootstrap really means in this context. But if you have myname[3] > + myname[5], the two objects being added are identified by a subscript > operation, not just a name. > >> Or a literal. > > > A literal is used to create an object, and acts like a temporary name for > that object, but once again the object being operated on isn't necessarily > that one. You can subscript and get attributes from a literal as well. > > >> So those are the only two ways to specify which objects are to be >> used. >> > > That would be a pretty weak language, and it wouldn't be python. > > > Now if you considered "." and "[" as operators, then I could understand your > point. But > http://docs.python.org/3/reference/lexical_analysis.html#operators > seems to say differently. > > Also see > http://docs.python.org/3/reference/expressions.html#primaries They may not quite be "operators" per se, but the fact is that they're composites built of primitives. You can't reference an object without somewhere having either a name or a literal to start it off. Your example starts with the object identified by the name 'myname', and the objects referenced by the literals 3 and 5, and builds up from there. Rebinding 'myname' would change that expression, as would changing the meanings of 3 or 5, though I don't know of any way to do the latter :) ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2013-06-19 08:55 +0000 |
| Message-ID | <51c17208$0$29973$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #48698 |
On Wed, 19 Jun 2013 18:21:40 +1000, Chris Angelico wrote:
> You can't reference an object without
> somewhere having either a name or a literal to start it off.
True, but not necessarily a name bound to the object you are thinking of:
some_function()
gives you an object, but it's not a literal, and "some_function" is not
the name of the object you end up with.
In a sense, you're making a fairly uninteresting claim:
"You cannot refer to an object without referring to something"
which is obviously correct. The ways to refer to something are more
interesting:
* you can refer to a thing directly by referring to it as a literal;
* you can refer to a thing bound to a name by referring to the name;
* you can refer to a thing in a namespace by referring to the namespace
in some fashion, followed by a dot, followed by the name in that
namespace, e.g. some_object.attribute, __import__('math').pi;
* you can refer to a thing in a sequence by referring to the sequence in
some fashion, followed by an index number in square brackets, e.g. seq[3];
* you can refer to a thing that is returned by a callable (function,
method, type, etc.) by referring in some fashion to that callable object,
followed by calling it, e.g. functions[9](arg) gives you a reference to
some object which may not be any of `functions`, `9`, or `arg`.
Have I missed any?
--
Steven
[toc] | [prev] | [next] | [standalone]
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Date | 2013-06-19 19:14 +1000 |
| Message-ID | <mailman.3578.1371633261.3114.python-list@python.org> |
| In reply to | #48700 |
On Wed, Jun 19, 2013 at 6:55 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 19 Jun 2013 18:21:40 +1000, Chris Angelico wrote:
>
>> You can't reference an object without
>> somewhere having either a name or a literal to start it off.
>
> True, but not necessarily a name bound to the object you are thinking of:
>
> some_function()
>
> gives you an object, but it's not a literal, and "some_function" is not
> the name of the object you end up with.
You start with the object identified by some_function, then you call
it. Same thing. Okay, so according to the Python grammar some of these
things I've been treating as operators aren't classified as them; but
there are still operations done to existing objects to derive other
objects:
> The ways to refer to something are more
> interesting:
>
> * you can refer to a thing directly by referring to it as a literal;
>
> * you can refer to a thing bound to a name by referring to the name;
The two I started with
> * you can refer to a thing in a namespace by referring to the namespace
> in some fashion, followed by a dot, followed by the name in that
> namespace, e.g. some_object.attribute, __import__('math').pi;
Retrieving an attribute of an object, whether that object be
referenced by name or by function call.
> * you can refer to a thing in a sequence by referring to the sequence in
> some fashion, followed by an index number in square brackets, e.g. seq[3];
Ditto. These can call magic methods; as far as I'm concerned, they're
equivalent to operators. You can apply them to anything.
> * you can refer to a thing that is returned by a callable (function,
> method, type, etc.) by referring in some fashion to that callable object,
> followed by calling it, e.g. functions[9](arg) gives you a reference to
> some object which may not be any of `functions`, `9`, or `arg`.
And same again. You start with functions, 9, and arg, look up two of
them as names, traverse the series of operations, and get back a
result. Or maybe you throw an exception.
>>> class Foo:
def __call__(self):
print("Hello, world!")
>>> foo=Foo()
>>> foo()
Hello, world!
Is foo a function? Kinda. Sorta. We don't care. Is the function call
notation () an operator? Ditto - we don't care. It works like one.
There's little fundamental difference between:
>>> "asdf %d qwer"%5
'asdf 5 qwer'
and
>>> "asdf %d qwer"[5]
'%'
but one of them is called an operator and one's not. Would you say
that percent notation there is another way to reference an object? Is
it a different type of string literal? No. It's a string literal and
an operation done to it. Same with the subscripting, even though
that's not technically an operator. It's not a different way to get an
object. It's an operation on an object.
ChrisA
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2013-06-14 14:38 +0000 |
| Message-ID | <kpf9t9$o0e$2@reader1.panix.com> |
| In reply to | #48094 |
On 2013-06-14, Nick the Gr33k <support@superhost.gr> wrote:
> Well i do not understand it.
Yea. We know.
--
Grant Edwards grant.b.edwards Yow! I feel like a wet
at parking meter on Darvon!
gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Fábio Santos <fabiosantosart@gmail.com> |
|---|---|
| Date | 2013-06-14 10:05 +0100 |
| Message-ID | <mailman.3275.1371200712.3114.python-list@python.org> |
| In reply to | #48091 |
[Multipart message — attachments visible in raw view] — view raw
On 14 Jun 2013 09:56, "Nick the Gr33k" <support@superhost.gr> wrote:
>
> On 14/6/2013 11:03 πμ, Nick the Gr33k wrote:
>>
>> On 14/6/2013 4:14 πμ, Steven D'Aprano wrote:
>>>
>>> On Thu, 13 Jun 2013 17:26:18 +0300, Νικόλαος Κούρας wrote:
>>>
>>>> i just want 4 cases to examine so correct execute to be run:
>>>>
>>>> i'm reading and reading and reading this all over:
>>>>
>>>> if '-' not in ( name and month and year ):
>>>>
>>>> and i cant comprehend it.
>>>
>>>
>>> Don't just read it. Open the interactive interpreter and test it.
>>>
>>> name = "abcd"
>>> month = "efgh"
>>> year = "ijkl"
>>>
>>> print(name and month and year)
>>>
>>> If you run that, you will see what the result of
>>> (name and month and year) is. Now, ask yourself:
>>>
>>> "k" in (name and month and year)
>>>
>>> True or false? Check your answer:
>>>
>>> print("k" in (name and month and year))
>>
>>
>>
>> >>> name="abcd"
>> >>> month="efgh"
>> >>> year="ijkl"
>>
>> >>> print(name or month or year)
>> abcd
>>
>> Can understand that, it takes the first string out of the 3 strings that
>> has a truthy value.
>>
>> >>> print("k" in (name and month and year))
>> True
>>
>> No clue. since the expression in parenthesis returns 'abcd' how can 'k'
>> contained within 'abcd' ?
>>
>> >>> print(name and month and year)
>> ijkl
>>
>> Seems here is returning the last string out of 3 strings, but have no
>> clue why Python doing this.
>>
>> >>> print("k" in (name and month and year))
>> True
>> >>>
>>
>> yes, since expression returns 'ijkl', then the in operator can detect
>> the 'k' character within the returned string.
>>
>
> Someone want to explain this?
At the very least read the replies to your questions.
http://code.activestate.com/lists/python-list/644572/
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.python
csiph-web