Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #48106 > unrolled thread

Eval of expr with 'or' and 'and' within

Back to article view | Back to comp.lang.python

Contents

  Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-14 12:50 +0300
    Re: Eval of expr with 'or' and 'and' within Fábio Santos <fabiosantosart@gmail.com> - 2013-06-14 11:03 +0100
    Re: Eval of expr with 'or' and 'and' within Robert Kern <robert.kern@gmail.com> - 2013-06-14 11:14 +0100
      Re: Eval of expr with 'or' and 'and' within Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 16:09 +0000
        Re: Eval of expr with 'or' and 'and' within rusi <rustompmody@gmail.com> - 2013-06-14 09:21 -0700
        Re: Eval of expr with 'or' and 'and' within Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-06-14 20:03 +0200
          Re: Eval of expr with 'or' and 'and' within rusi <rustompmody@gmail.com> - 2013-06-14 11:37 -0700
            Re: Eval of expr with 'or' and 'and' within Joshua Landau <joshua.landau.ws@gmail.com> - 2013-06-14 19:47 +0100
        Re: Eval of expr with 'or' and 'and' within alex23 <wuwei23@gmail.com> - 2013-06-14 23:50 -0700
          Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 10:04 +0300
            Re: Eval of expr with 'or' and 'and' within Denis McMahon <denismfmcmahon@gmail.com> - 2013-06-15 07:49 +0000
              Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 10:59 +0300
    Re: Eval of expr with 'or' and 'and' within Grant Edwards <invalid@invalid.invalid> - 2013-06-14 14:49 +0000
      Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-14 18:16 +0300
        Re: Eval of expr with 'or' and 'and' within Nobody <nobody@nowhere.com> - 2013-06-14 17:42 +0100
          Re: Eval of expr with 'or' and 'and' within Grant Edwards <invalid@invalid.invalid> - 2013-06-14 19:30 +0000
            Re: Eval of expr with 'or' and 'and' within Nobody <nobody@nowhere.com> - 2013-06-15 00:02 +0100
          Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 10:57 +0300
    Re: Eval of expr with 'or' and 'and' within Michael Torrie <torriem@gmail.com> - 2013-06-14 10:29 -0600
      Re: Eval of expr with 'or' and 'and' within Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 16:49 +0000
        Re: Eval of expr with 'or' and 'and' within Michael Torrie <torriem@gmail.com> - 2013-06-14 11:28 -0600
        Re: Eval of expr with 'or' and 'and' within MRAB <python@mrabarnett.plus.com> - 2013-06-14 18:49 +0100
        Re: Eval of expr with 'or' and 'and' within Chris Angelico <rosuav@gmail.com> - 2013-06-15 03:56 +1000
          Re: Eval of expr with 'or' and 'and' within Grant Edwards <invalid@invalid.invalid> - 2013-06-14 19:33 +0000
            Re: Eval of expr with 'or' and 'and' within Chris Angelico <rosuav@gmail.com> - 2013-06-15 09:56 +1000
          Re: Eval of expr with 'or' and 'and' within Nobody <nobody@nowhere.com> - 2013-06-15 00:09 +0100
            Re: Eval of expr with 'or' and 'and' within Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-15 01:34 +0000
              Re: Eval of expr with 'or' and 'and' within Cameron Simpson <cs@zip.com.au> - 2013-06-15 12:03 +1000
                NANs [was Re: Eval of expr with 'or' and 'and' within] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-15 04:22 +0000
              Re: Eval of expr with 'or' and 'and' within Chris Angelico <rosuav@gmail.com> - 2013-06-15 12:21 +1000
        Re: Eval of expr with 'or' and 'and' within Nobody <nobody@nowhere.com> - 2013-06-15 00:06 +0100
          Re: Eval of expr with 'or' and 'and' within MRAB <python@mrabarnett.plus.com> - 2013-06-15 01:26 +0100
    Re: Eval of expr with 'or' and 'and' within Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-06-14 09:47 -0700
      Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-14 20:01 +0300
        Re: Eval of expr with 'or' and 'and' within Robert Kern <robert.kern@gmail.com> - 2013-06-14 18:27 +0100
        Re: Eval of expr with 'or' and 'and' within Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-06-14 22:05 +0300
        Re: Eval of expr with 'or' and 'and' within Grant Edwards <invalid@invalid.invalid> - 2013-06-14 19:36 +0000
    Re: Eval of expr with 'or' and 'and' within Cameron Simpson <cs@zip.com.au> - 2013-06-15 10:14 +1000
      Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 11:20 +0300
        Re: Eval of expr with 'or' and 'and' within Lele Gaifax <lele@metapensiero.it> - 2013-06-15 11:48 +0200
          Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 16:24 +0300
          Re: Eval of expr with 'or' and 'and' within Nick the Gr33k <support@superhost.gr> - 2013-06-15 16:28 +0300

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#48193

On 06/14/2013 10:49 AM, Steven D'Aprano wrote:
> Correct. In Python, all boolean expressions are duck-typed: they aren't 
> restricted to True and False, but to any "true-ish" and "false-ish" 
> value, or as the Javascript people call them, truthy and falsey values.
> <snip>
> There are a couple of anomalies -- the timestamp representing midnight is 
> falsey, because it is implemented as a zero number of seconds; also 
> exhausted iterators and generators ought to be considered falsey, since 
> they are empty, but because they don't know they are empty until called, 
> they are actually treated as truthy. But otherwise, the model is very 
> clean.

Good explanation! Definitely enlightened me.  Thank you.

[toc] | [prev] | [next] | [standalone]

#48196

On 14/06/2013 18:28, Michael Torrie wrote:
> On 06/14/2013 10:49 AM, Steven D'Aprano wrote:
>> Correct. In Python, all boolean expressions are duck-typed: they aren't
>> restricted to True and False, but to any "true-ish" and "false-ish"
>> value, or as the Javascript people call them, truthy and falsey values.
>> <snip>
>> There are a couple of anomalies -- the timestamp representing midnight is
>> falsey, because it is implemented as a zero number of seconds; also
>> exhausted iterators and generators ought to be considered falsey, since
>> they are empty, but because they don't know they are empty until called,
>> they are actually treated as truthy. But otherwise, the model is very
>> clean.
>
> Good explanation! Definitely enlightened me.  Thank you.
>
The general rule is that an object is true-ish unless it's false-ish
(there are fewer false-ish objects than true-ish objects, e.g. zero vs
non-zero int).

[toc] | [prev] | [next] | [standalone]

#48199

On Sat, Jun 15, 2013 at 3:49 AM, MRAB <python@mrabarnett.plus.com> wrote:
> The general rule is that an object is true-ish unless it's false-ish
> (there are fewer false-ish objects than true-ish objects, e.g. zero vs
> non-zero int).

With a few random oddities:

>>> bool(float("nan"))
True

I somehow expected NaN to be false. Maybe that's just my expectations
that are wrong, though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48214

On 2013-06-14, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jun 15, 2013 at 3:49 AM, MRAB <python@mrabarnett.plus.com> wrote:
>> The general rule is that an object is true-ish unless it's false-ish
>> (there are fewer false-ish objects than true-ish objects, e.g. zero vs
>> non-zero int).
>
> With a few random oddities:
>
>>>> bool(float("nan"))
> True
>
> I somehow expected NaN to be false. Maybe that's just my expectations
> that are wrong, though.

If you work with floating point long enough you realize that most of
your expectations are wrong.  Sometimes.  Eventually.

-- 
Grant Edwards               grant.b.edwards        Yow! My pants just went to
                                  at               high school in the Carlsbad
                              gmail.com            Caverns!!!

[toc] | [prev] | [next] | [standalone]

#48226

On Sat, Jun 15, 2013 at 5:33 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-06-14, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Jun 15, 2013 at 3:49 AM, MRAB <python@mrabarnett.plus.com> wrote:
>>> The general rule is that an object is true-ish unless it's false-ish
>>> (there are fewer false-ish objects than true-ish objects, e.g. zero vs
>>> non-zero int).
>>
>> With a few random oddities:
>>
>>>>> bool(float("nan"))
>> True
>>
>> I somehow expected NaN to be false. Maybe that's just my expectations
>> that are wrong, though.
>
> If you work with floating point long enough you realize that most of
> your expectations are wrong.  Sometimes.  Eventually.

NaN is like NULL in SQL. It's a weird beast. Just when you think
you've pinned it down, it slips out from under your taxonomic
classifications and thumbs its nose at you...

I think they're cousins to the platypus.

http://tvtropes.org/pmwiki/pmwiki.php/Main/EverythingsBetterWithPlatypi

ChrisA

[toc] | [prev] | [next] | [standalone]

#48224

On Sat, 15 Jun 2013 03:56:28 +1000, Chris Angelico wrote:

> With a few random oddities:
> 
>>>> bool(float("nan"))
> True
> 
> I somehow expected NaN to be false. Maybe that's just my expectations
> that are wrong, though.

In general, you should expect the behaviour of NaN to be the opposite of
what you expect.

[toc] | [prev] | [next] | [standalone]

#48239

On Sat, 15 Jun 2013 00:09:31 +0100, Nobody wrote:

> On Sat, 15 Jun 2013 03:56:28 +1000, Chris Angelico wrote:
> 
>> With a few random oddities:
>> 
>>>>> bool(float("nan"))
>> True
>> 
>> I somehow expected NaN to be false. Maybe that's just my expectations
>> that are wrong, though.
> 
> In general, you should expect the behaviour of NaN to be the opposite of
> what you expect.

... even taking that into account! *wink*


Everyone is aware that there is more than one NAN, right? If my 
calculations are correct, there are 9007199254740992 distinct float NANs 
in Python (although there is no direct way of distinguishing them). Half 
have the sign bit set, half do not; half are quiet NANs and half are 
signalling NANs. It would be too easy if "sign bit set" meant signalling, 
so in fact there are four equal-numbered groups of NANs, 2251799813685248 
each of:

+quiet
+signalling
-quiet
-signalling

where the - sign should be interpreted as "sign bit is set" rather than 
"negative", and + sign as "sign bit not set".

They differ according to their bit-pattern, or payload. Some systems 
actually give standard meanings to different bit patterns, e.g. in the 
old SANE (Standard Apple Numerics Environment) system, different NANs 
were produced according to different kinds of errors, e.g:

Payload  Description
=======  ==========================================
1        Invalid sqrt
2        Invalid addition, e.g. +INF + -INF
3        Invalid division, e.g. 0/0
17       Convert invalid string
21       Attempt to create NAN with 0 as payload

etc.

(Assigning meaning to the payload is optional, according to the IEEE 754 
standard, if I recall correctly.)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#48242

On 15Jun2013 01:34, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
| On Sat, 15 Jun 2013 00:09:31 +0100, Nobody wrote:
| 
| > On Sat, 15 Jun 2013 03:56:28 +1000, Chris Angelico wrote:
| >> With a few random oddities:
| >>>>> bool(float("nan"))
| >> True
| >> I somehow expected NaN to be false. Maybe that's just my expectations
| >> that are wrong, though.
| > 
| > In general, you should expect the behaviour of NaN to be the opposite of
| > what you expect.
| 
| ... even taking that into account! *wink*
| 
| Everyone is aware that there is more than one NAN, right?

I was not. Interesting.

| If my 
| calculations are correct, there are 9007199254740992 distinct float NANs 
| in Python (although there is no direct way of distinguishing them).

Wouldn't id() do it? At least in terms of telling them apart?
I gather they're not inspectable in Python?

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

2 strokes are quicker than 4.

[toc] | [prev] | [next] | [standalone]

#48247 — NANs [was Re: Eval of expr with 'or' and 'and' within]

On Sat, 15 Jun 2013 12:03:08 +1000, Cameron Simpson wrote:

> | ... even taking that into account! *wink* |
> | Everyone is aware that there is more than one NAN, right?
> 
> I was not. Interesting.
> 
> | If my
> | calculations are correct, there are 9007199254740992 distinct float
> | NANs in Python (although there is no direct way of distinguishing
> | them).
> 
> Wouldn't id() do it? At least in terms of telling them apart? I gather
> they're not inspectable in Python?

I'm not talking about different *objects*. It would be terribly wasteful 
for Python to pre-allocate 9-gazillion NAN objects. I'm talking about 
distinct values, in the C-double sense.

Python may or may not cache floats in general. In general, it doesn't:

py> x = 2.5
py> y = 2.5
py> x is y
False


but in principle Python might choose to cache some, or all float objects, 
like it does with some ints and strings:

# simulated, not real
py> x = 0.0
py> y = 0.0
py> x is y
True

So you can always distinguish two floats, including NANs, *by value* with 
== and by *object identity* with id() and `is`. But that's not what I'm 
referring to.

The layout of a C double (the numeric value of a float object) is 64 bits:

|s|..e..|......f......|

where s is a single sign bit, e is an 11-bit biased exponent, and f is a 
52-bit binary fraction. If e is 2047 (0b11111111111) then the double is a 
special value, either an INF or a NAN:

e = 2047, f == 0: double is +INF or -INF, depending on s

e = 2047, f != 0: double is a NAN

With a 52-bit f field, there are 4503599627370496 distinct payloads with 
the sign bit set, and another 4503599627370496 with it cleared. Python 
gives you no direct way of testing or setting that payload, or for that 
matter the sign bit, on a NAN, although you can use the struct module to 
cast a float to a 64-bit int and then do bit twiddling. But in principle, 
with 51 (why not 52? see below) bits available, you can stuff quite a 
fair bit of diagnostic information in a NAN, if you need to.

The high bit of f is reserved for a special purpose. If the high bit is 
set (i.e. f >> 51 == 1) the NAN is considered a signalling NAN, which (in 
implementations that comply with the IEEE 754 standard) are guaranteed to 
halt the calculation immediately. Those with it cleared are quiet NANs, 
and are intended to propagate through calculations[1], although that is 
configurable[2].




[1] It's not quite true that once a NAN has entered a calculation, it is 
guaranteed to be the final result. There are circumstances where NANs can 
legitimately disappear from a calculation, leaving an actual number.

[2] Python doesn't allow you to configure float's behaviour but the 
Decimal module does.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#48245

On Sat, Jun 15, 2013 at 12:03 PM, Cameron Simpson <cs@zip.com.au> wrote:
> On 15Jun2013 01:34, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> | Everyone is aware that there is more than one NAN, right?
>
> I was not. Interesting.
>
> | If my
> | calculations are correct, there are 9007199254740992 distinct float NANs
> | in Python (although there is no direct way of distinguishing them).
>
> Wouldn't id() do it? At least in terms of telling them apart?
> I gather they're not inspectable in Python?

You could recognize one float object as distinct from another, but
that's true of all floats:

>>> float("1.0") is float("1.0")
False

All NaNs are different in terms of the == operator, so conceptually
there are an infinite number of unique NaNs. The fact that they're
stored in memory using a certain number of bits means that there must
be a finite number of possible representations, but that's really an
implementation detail. I suppose you could figure out the
representation differences by fiddling with ctypes (in C I'd just use
a union), but that's really all.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48222

On Fri, 14 Jun 2013 16:49:11 +0000, Steven D'Aprano wrote:

> Unlike Javascript though, Python's idea of truthy and falsey is actually 
> quite consistent:

Beyond that, if a user-defined type implements a __nonzero__() method then
it determines whether an instance is true or false. If it implements a
__len__() method, then an instance is true if it has a non-zero length.

[toc] | [prev] | [next] | [standalone]

#48232

On 15/06/2013 00:06, Nobody wrote:
> On Fri, 14 Jun 2013 16:49:11 +0000, Steven D'Aprano wrote:
>
>> Unlike Javascript though, Python's idea of truthy and falsey is actually
>> quite consistent:
>
> Beyond that, if a user-defined type implements a __nonzero__() method then
> it determines whether an instance is true or false. If it implements a
> __len__() method, then an instance is true if it has a non-zero length.
>
It's __nonzero__ in Python 2, __bool__ in Python 3.

[toc] | [prev] | [next] | [standalone]

#48180

[Multipart message — attachments visible in raw view] — view raw

On Jun 14, 2013 9:34 AM, "Michael Torrie" <torriem@gmail.com> wrote:
>
> On 06/14/2013 03:50 AM, Nick the Gr33k wrote:
> >  >>> print(name or month or year)
> > abcd
> >  >>> print(name and month and year)
> > ijkl
>
> Interesting.  I'd have thought a boolean expression would return True or
> False, not a string.  Learn something new every day.
>
>
>

Python didn't have a Boolean type for quite some time (2.2?). Until then,
True and False were ints. Since every object had a Boolean value, you
didn't need to turn the result into an integer. In an "and" clause, python
returns the first false value or the last value, because that will evaluate
to the correct Boolean value. In an "or" clause, python returns the first
true value or the last value. When Python finally got a Boolean type, no
one wanted to break backwards compatibility for this.

[toc] | [prev] | [next] | [standalone]

#48184

On 14/6/2013 7:47 μμ, Benjamin Kaplan wrote:
  In an "and" clause,
> python returns the first false value or the last value, because that
> will evaluate to the correct Boolean value. In an "or" clause, python
> returns the first true value or the last value. When Python finally got
> a Boolean type, no one wanted to break backwards compatibility for this.


This is exactly what i dont understand and thats why i keep asking and 
people call me an idiot. I just dont understand why it behaves like that.

Why return first or last value?

because that will evaluate to the correct Boolean value ????

How do you mean? Please elaborate.

-- 
What is now proved was at first only imagined!

[toc] | [prev] | [next] | [standalone]

#48192

On 2013-06-14 18:01, Nick the Gr33k wrote:
> On 14/6/2013 7:47 μμ, Benjamin Kaplan wrote:
>   In an "and" clause,
>> python returns the first false value or the last value, because that
>> will evaluate to the correct Boolean value. In an "or" clause, python
>> returns the first true value or the last value. When Python finally got
>> a Boolean type, no one wanted to break backwards compatibility for this.
>
>
> This is exactly what i dont understand and thats why i keep asking and people
> call me an idiot. I just dont understand why it behaves like that.
>
> Why return first or last value?
>
> because that will evaluate to the correct Boolean value ????
>
> How do you mean? Please elaborate.

Please read the link I gave. It explains why.

   http://docs.python.org/2/reference/expressions.html#boolean-operations

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

[toc] | [prev] | [next] | [standalone]

#48207

Nick the Gr33k writes:

> Why return first or last value?
> 
> because that will evaluate to the correct Boolean value ????

That value will either behave exactly the same as the Boolean value
you call correct, or else it will be more useful. That is, most of the
time it doesn't matter, and when it matters, Python's way is better.

You can turn any expression E into a strictly Boolean value by writing
bool(E) instead. Often E is already guaranteed to be a Boolean and the
whole question does not arise in the first place.

This doesn't prevent you from writing your program.

[toc] | [prev] | [next] | [standalone]

#48215

On 2013-06-14, Nick the Gr33k <support@superhost.gr> wrote:
> On 14/6/2013 7:47 ????, Benjamin Kaplan wrote:
>   In an "and" clause,
>> python returns the first false value or the last value, because that
>> will evaluate to the correct Boolean value. In an "or" clause, python
>> returns the first true value or the last value. When Python finally got
>> a Boolean type, no one wanted to break backwards compatibility for this.
>
>
> This is exactly what i dont understand and thats why i keep asking and 
> people call me an idiot. I just dont understand why it behaves like that.
>
> Why return first or last value?

There are cases where it's useful not only to know wether an
expression was True or False, but _why_ it was true or false.

> because that will evaluate to the correct Boolean value ????

Yes.  All values in Pyton have a "truthness" and you can be guaranteed
that 

     if A or B or C:

will behave exactly the same way whether the "or" operator returns
True or it returns one of it's operands.  

-- 
Grant Edwards               grant.b.edwards        Yow! Where do your SOCKS
                                  at               go when you lose them in
                              gmail.com            th' WASHER?

[toc] | [prev] | [next] | [standalone]

#48238

On 14Jun2013 12:50, Nikos as SuperHost Support <support@superhost.gr> wrote:
| I started another thread because the last one was !@#$'ed up by
| irrelevant replies and was difficult to jeep track.
| 
| >>> 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' ?

Did you print the result of "name and month and year"? It is the
_last_ value (if true at all).  You used "or" in the first example
and "and" in the second.

| >>> 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.

To evaluate an "and" it must test all of them to be true, and it
keeps the last value tested.  (Or False, of course, if they are not
all true, in which case Python stops testing at the first False).

But for what you are doing, "and" and "or" are not good operations.

Something like:

  "k" in (name+month+year)

or

  "k" in name or "k" in month or "k" in year

is a more direct and accurate way to write what I imagine you're trying to do.

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

No one is completely worthless...  they can always serve as a bad example.

[toc] | [prev] | [next] | [standalone]

#48268

On 15/6/2013 3:14 πμ, Cameron Simpson wrote:
> On 14Jun2013 12:50, Nikos as SuperHost Support <support@superhost.gr> wrote:
> | I started another thread because the last one was !@#$'ed up by
> | irrelevant replies and was difficult to jeep track.
> |
> | >>> 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' ?
>
> Did you print the result of "name and month and year"? It is the
> _last_ value (if true at all).  You used "or" in the first example
> and "and" in the second.

okey, lets see it again:

 >>> print (name or month or year)
abcd
 >>>

Yes, 'k' isn't contained in the result string 'abcd'

 >>> print (name and month and year)
hijk
 >>> print( "k" in (name and month and year) )
True

Yes they work as expected, i was mistaken, sorry.


>
> | >>> 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.
>
> To evaluate an "and" it must test all of them to be true, and it
> keeps the last value tested.  (Or False, of course, if they are not
> all true, in which case Python stops testing at the first False).

Yes, i know it behaves like that, the question is why:

As "Nobody" explained to me, the reason is that Python expressions 
results back the argument that determined the evaluation of the Boolean 
expression, which in turn can be a truthy or a falsey used in 'or' or 
'and' respectively.

Returning a truthy value equals True
returning a falsey value equals False

so it all boils down to the Booleans type of values True or False.


> But for what you are doing, "and" and "or" are not good operations.
>
> Something like:
>
>    "k" in (name+month+year)
>
> or
>
>    "k" in name or "k" in month or "k" in year

Used to wrote it myself like the latter but needed a more compact way of 
writing it for clarity so i used the former.

but those 2 gives the same results back

"k" in (name+month+year) == "k" in (name and month and year)
True

so both seem to work as expected.
-- 
What is now proved was at first only imagined!

[toc] | [prev] | [next] | [standalone]

#48276

Nick the Gr33k <support@superhost.gr> writes:

> On 15/6/2013 3:14 πμ, Cameron Simpson wrote:
>> But for what you are doing, "and" and "or" are not good operations.
>>
>> Something like:
>>
>>    "k" in (name+month+year)
>>
>> or
>>
>>    "k" in name or "k" in month or "k" in year
>
> Used to wrote it myself like the latter but needed a more compact way
> of writing it for clarity so i used the former.
>
> but those 2 gives the same results back
>
> "k" in (name+month+year) == "k" in (name and month and year)
> True
>
> so both seem to work as expected.

That happens only by chance: it seems you now understand the evaluation
of "boolean" expressions in Python, so the following should be clear to
you: 

>>> "k" in ("there" + "is" + "a" + "k" + "character" + "somewhere")
True
>>> "k" in ("there" and "is" and "a" and "k" and "character" and "somewhere")
False

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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web