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

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

checking if a list is empty

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

Contents

  checking if a list is empty Jabba Laci <jabba.laci@gmail.com> - 2011-05-06 02:36 -0400
    Re: checking if a list is empty Richard Thomas <chardster@gmail.com> - 2011-05-06 03:34 -0700
    Re: checking if a list is empty scattered <tooscattered@gmail.com> - 2011-05-06 14:57 -0700
      Re: checking if a list is empty Philip Semanchuk <philip@semanchuk.com> - 2011-05-06 18:21 -0400
      Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-06 17:51 -0600
        Re: checking if a list is empty Jon Clements <joncle@googlemail.com> - 2011-05-06 17:43 -0700
          Re: checking if a list is empty Hans Mulder <hansmu@xs4all.nl> - 2011-05-14 10:52 +0200
      Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-07 02:51 +0000
        Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 10:02 +0100
          Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 12:14 +0000
            Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 15:05 +0100
              Re: checking if a list is empty "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-11 10:27 -0400
                Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 18:59 +0100
                  Re: checking if a list is empty alex23 <wuwei23@gmail.com> - 2011-05-11 20:16 -0700
                    Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 06:20 +0100
              Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 15:50 +0000
                Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-12 02:05 +1000
                  Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 18:56 +0100
                    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-11 16:13 -0500
            RE: checking if a list is empty "Prasad, Ramit" <ramit.prasad@jpmchase.com> - 2011-05-11 13:39 -0400
          Re: checking if a list is empty Roy Smith <roy@panix.com> - 2011-05-11 08:26 -0400
            Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 13:29 +0000
            Re: checking if a list is empty Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-12 17:44 +1200
              Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 07:06 +0100
              Re: checking if a list is empty Roy Smith <roy@panix.com> - 2011-05-12 07:36 -0400
                Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-13 00:16 +0000
                  Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-12 23:46 -0700
                    Re: checking if a list is empty Chris Rebert <clp2@rebertia.com> - 2011-05-13 01:02 -0700
                      Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-13 03:58 -0700
                    Re: checking if a list is empty Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-14 14:34 +1200
                      Re: checking if a list is empty David Robinow <drobinow@gmail.com> - 2011-05-14 10:28 -0400
                        Re: checking if a list is empty Roy Smith <roy@panix.com> - 2011-05-14 11:04 -0400
                    Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-14 07:39 +0000
                      Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-14 00:45 -0700
                        Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-14 23:42 +1000
                          Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-14 08:47 -0700
                            Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-15 01:55 +1000
                              Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-14 10:43 -0700
                                Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-14 17:29 -0400
                            Re: checking if a list is empty Ben Finney <ben+python@benfinney.id.au> - 2011-05-15 09:26 +1000
                              Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-14 19:41 -0700
                                Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-15 05:07 +0000
                                  Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-15 10:33 -0700
                                    Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-15 17:36 -0400
                                      Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-15 22:56 -0700
                                    Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-16 00:36 +0000
                                      Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-15 20:59 -0500
                                      Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-15 22:40 -0700
                                    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-15 20:25 -0500
                                    Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-15 21:57 -0400
                        Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-14 16:59 -0400
                        Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-15 05:00 +0000
                      Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-14 16:53 -0400
            Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-12 15:37 -0400
            Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-12 18:00 -0400
    Re: checking if a list is empty Raymond Hettinger <python@rcn.com> - 2011-05-06 15:52 -0700

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

#5109

Hans Georg Schaathun <hg@schaathun.net> wrote:

> li == [] is as explicit as it gets, and
> leaves no room for doubt.

I was about to write, "this fails if li is an instance of a subclass of 
list", but then I tried it.  I was astounded to discover that:

class MyList(list):
    "I'm a subclass"

li = MyList()
print li == []
print [] == li

prints True, twice!  I expected them both to be false.  In fact, the 
docs (http://tinyurl.com/3qga3lb) explicitly say:

> If both are numbers, they are converted to a common type. Otherwise, 
> objects of different types always compare unequal

Since these are different types, i.e.

print type(li)
print type([])
print type(li) == type([])

prints

<class '__main__.MyList'>
<type 'list'>
False

I conclude that li == [] should have returned False.  Either I'm not 
understanding things correctly, or this is a bug.

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

#5112

On Wed, 11 May 2011 08:26:53 -0400, Roy Smith wrote:

> Hans Georg Schaathun <hg@schaathun.net> wrote:
> 
>> li == [] is as explicit as it gets, and leaves no room for doubt.
> 
> I was about to write, "this fails if li is an instance of a subclass of
> list", but then I tried it.  I was astounded to discover that:
> 
> class MyList(list):
>     "I'm a subclass"
> 
> li = MyList()
> print li == []
> print [] == li
> 
> prints True, twice!  I expected them both to be false.  In fact, the
> docs (http://tinyurl.com/3qga3lb) explicitly say:
> 
>> If both are numbers, they are converted to a common type. Otherwise,
>> objects of different types always compare unequal

That should be understood as only applying for built-in types, not 
arbitrary types. For arbitrary types, you can decide what counts as equal 
by writing an __eq__ method, and you can do *anything*:

    def __eq__(self, other):
        if today() == "Tuesday": return True
        else: ...


To understand the behaviour you are seeing, it helps to understand that 
while li is a MyList, it is also a list:

>>> isinstance(li, list)
True

It therefore inherits the same behaviour as list, unless you override or 
overload it. Since you did neither, MyLists work just like lists, right 
down to their __eq__ method.

It is normally considered The Right Thing To Do for subclasses to be 
usable anywhere where a superclass was. That is, subclasses like MyList 
should only *add* behaviour, never *subtract* it. Since:

>>> li = list()
>>> li == []
True

applies, you should be able to replace list() with any subclass of list 
and it should still work. (This is known as the Liskov Substitution 
Principle, if you wish to google on it.)

This being Python, it's more of a guideline than a law, and you can 
violate it if you choose, but you probably shouldn't unless you have good 
reason. But if you want, just add a method:

    def __eq__(self, other):
        # untested
        if type(self) is not type(other): return False
        return super(self, MyList).__eq__(other)

to get the behaviour you are after.


So, not a bug, but a subtle point that isn't explained terribly well in 
the docs.



-- 
Steven

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

#5198

Roy Smith wrote:
> Hans Georg Schaathun <hg@schaathun.net> wrote:
>>If both are numbers, they are converted to a common type. Otherwise, 
>>objects of different types always compare unequal

That's just the default treatment for unrelated types that don't
know anything about each other.

I would guess that the list's == method is asking "Is the
other object a list?", and since a subclass of list is also
a list, it's happy and goes on to compare the elements.

-- 
Greg

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

#5202

On Thu, 12 May 2011 17:44:07 +1200, Gregory Ewing
  <greg.ewing@canterbury.ac.nz> wrote:
:  Roy Smith wrote:
: > Hans Georg Schaathun <hg@schaathun.net> wrote:
: >>If both are numbers, they are converted to a common type. Otherwise, 
: >>objects of different types always compare unequal

Actually, I did not.
:-- hg

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

#5227

In article <931adaF9g1U1@mid.individual.net>,
 Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Roy Smith wrote:
> >>If both are numbers, they are converted to a common type. Otherwise, 
> >>objects of different types always compare unequal
> 
> That's just the default treatment for unrelated types that don't
> know anything about each other.
> 
> I would guess that the list's == method is asking "Is the
> other object a list?", and since a subclass of list is also
> a list, it's happy and goes on to compare the elements.

Well, that explains what's happening, but the behavior still doesn't 
match the docs.  Is this a bug or are the docs wrong?

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

#5272

On Thu, 12 May 2011 07:36:27 -0400, Roy Smith wrote:

> In article <931adaF9g1U1@mid.individual.net>,
>  Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:
> 
>> Roy Smith wrote:
>> >>If both are numbers, they are converted to a common type. Otherwise,
>> >>objects of different types always compare unequal
>> 
>> That's just the default treatment for unrelated types that don't know
>> anything about each other.
>> 
>> I would guess that the list's == method is asking "Is the other object
>> a list?", and since a subclass of list is also a list, it's happy and
>> goes on to compare the elements.
> 
> Well, that explains what's happening, but the behavior still doesn't
> match the docs.  Is this a bug or are the docs wrong?


The docs are incomplete.

You are missing two facts:

* The docs you are quoting refer only to built-in types. That it doesn't 
make so clear is a documentation bug.

* Talking about "different" and "same" types is ambiguous. It depends on 
how you compare types:

type(a) is type(b)

isinstance(a, type(b))

You are reading the docs as if the first comparison is the way to do it, 
but the second is usually preferred.

Any time you read something about "the same type", you should mentally 
add "(or an instance of a sub-class)" to it, unless explicitly told 
different. Whether it is better to add that parenthetical comment every 
time it is needed, or to assume that the read knows enough about object-
oriented programming to assume it, is an open question.

Me personally, I think it's part of the mental landscape that can be 
assumed, like C docs might state "dereference the pointer" without adding 
"(unless it is a nul pointer)" *every single time*.


-- 
Steven

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

#5282

Mathematics has existed for millenia.
Hindu-arabic numerals (base-10 numbers) have been known for about one
millennium
The boolean domain is only a 100 years old.
Unsurprisingly it is not quite 'first-class' yet: See
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1070.html
[Lifted from http://c2.com/cgi/wiki?EqualVsTrueFalse ]

----------------------------
"In retrospect, one might be tempted to regard the introduction of
something as simple as the boolean domain as a minor invention, but I
think that that would be a grave mistake: it is a great invention
because, being so simple, it is such a powerful simplifier. It is of
the same level as the introduction of natural numbers, which enabled
us to add 3 to 5, regardless of whether we are adding apples or
pears."

"George Boole made a radical invention, so radical, in fact, that now,
more than a century later, the scientific community has not absorbed
it yet. (To stay with the metaphor: officially, boolean expressions
may have reached the status of first-class citizens, in practice —
because old habits and prejudices die hard— they are still the victims
of discrimination.) Let me give you a few examples."

"In the programming language FORTRAN, as conceived a century after
Boole published his invention, boolean expressions are allowed, but
there are no boolean variables! Their introduction into programming
had to wait until the design of ALGOL 60."

------------------------
So, M Harris problem is that python could almost be a language for the
'masses' (whatever that might mean) were it not for warts like "l not
is empty" is shorten-able to just "l"

Dijkstra's problem (paraphrased) is that python, by choosing the
FORTRAN alternative of having a non-first-class boolean type, hinders
scientific/mathematical thinking/progress.

I tend to agree with Dijkstra's view that the boolean type should be
given more respect
except for the small fact that the computer's ALU is based on the
logic-arithmetic pun:
half-adder = xor
(half)-carry = and

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

#5284

On Thu, May 12, 2011 at 11:46 PM, rusi <rustompmody@gmail.com> wrote:
<snip>
> The boolean domain is only a 100 years old.
> Unsurprisingly it is not quite 'first-class' yet: See

It is nowadays. Every halfway-mainstream language I can think of has
an explicit boolean datatype. Heck, as of C99, even C has one now. I
conjecture the only languages still lacking one are exotic
niche/fringe languages. I would be interested to see a counterexample.

> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1070.html
> [Lifted from http://c2.com/cgi/wiki?EqualVsTrueFalse ]
>
> ----------------------------
> "In retrospect, one might be tempted to regard the introduction of
> something as simple as the boolean domain as a minor invention, but I
> think that that would be a grave mistake: it is a great invention
> because, being so simple, it is such a powerful simplifier. It is of
> the same level as the introduction of natural numbers, which enabled
> us to add 3 to 5, regardless of whether we are adding apples or
> pears."
>
> "George Boole made a radical invention, so radical, in fact, that now,
> more than a century later, the scientific community has not absorbed
> it yet. (To stay with the metaphor: officially, boolean expressions
> may have reached the status of first-class citizens, in practice —
> because old habits and prejudices die hard— they are still the victims
> of discrimination.) Let me give you a few examples."
>
> "In the programming language FORTRAN, as conceived a century after
> Boole published his invention, boolean expressions are allowed, but
> there are no boolean variables! Their introduction into programming
> had to wait until the design of ALGOL 60."
>
> ------------------------
> So, M Harris problem is that python could almost be a language for the
> 'masses' (whatever that might mean) were it not for warts like "l not
> is empty" is shorten-able to just "l"

One language's wart is another language's idiom. And I think the
irrational hate towards syntactically-significant indentation is by
far a much larger barrier to "mass" adoption of Python; C++ has some
features that are at least (if not more) subtle/unobvious than
Python's __bool__(), yet it still enjoys "mass" use.

> Dijkstra's problem (paraphrased) is that python, by choosing the
> FORTRAN alternative of having a non-first-class boolean type, hinders
> scientific/mathematical thinking/progress.

Python has *not* chosen the Fortran alternative; *it has a first-class
Boolean type*, namely bool. This line of argument thus fails.
The fact that other types are implicitly coercible to bools doesn't
make `bool` itself any less first-class.

It is also ironic that one of the projects that exploits Python's
flexible typing regarding normally-Boolean operators is a scientific
one (NumPy).

Cheers,
Chris
--
http://rebertia.com

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

#5289

On May 13, 1:02 pm, Chris Rebert <c...@rebertia.com> wrote:
> On Thu, May 12, 2011 at 11:46 PM, rusi <rustompm...@gmail.com> wrote:
>
> > The boolean domain is only a 100 years old.
> > Unsurprisingly it is not quite 'first-class' yet: See
>
> It is nowadays. Every halfway-mainstream language I can think of has
> an explicit boolean datatype.

I guess you did not quite see my 'quite' -- which itself is a
summarization of Dijkstra's "officially" vs "in practice" ? [Heres the
quote]


> >http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1070.html
> > [Lifted fromhttp://c2.com/cgi/wiki?EqualVsTrueFalse]
>
> > ----------------------------
> > "In retrospect, one might be tempted to regard the introduction of
> > something as simple as the boolean domain as a minor invention, but I
> > think that that would be a grave mistake: it is a great invention
> > because, being so simple, it is such a powerful simplifier. It is of
> > the same level as the introduction of natural numbers, which enabled
> > us to add 3 to 5, regardless of whether we are adding apples or
> > pears."
>
> > "George Boole made a radical invention, so radical, in fact, that now,
> > more than a century later, the scientific community has not absorbed
> > it yet. (To stay with the metaphor: officially, boolean expressions
> > may have reached the status of first-class citizens, in practice —
> > because old habits and prejudices die hard— they are still the victims
> > of discrimination.) Let me give you a few examples."
>
> > "In the programming language FORTRAN, as conceived a century after
> > Boole published his invention, boolean expressions are allowed, but
> > there are no boolean variables! Their introduction into programming
> > had to wait until the design of ALGOL 60."


As an analogy, in Perl, a list can get coerced to its length "... when
in scalar context.." or something like that.  Most programmers from
the static-typechecked-languages camp would balk at that laissez faire
attitude.  Likewise Harris is pointing out that noob python
programmers may feel a bit unnerved by non-boolean types unexpectedly
showing 'boolean-ness.'  Maybe we are just more in noob category and
we've not got the zen of python?? Dunno...

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

#5333

rusi wrote:

> Dijkstra's problem (paraphrased) is that python, by choosing the
> FORTRAN alternative of having a non-first-class boolean type, hinders
> scientific/mathematical thinking/progress.

Python doesn't have the flaw that Dijkstra was talking about.
Fortran's flaw wasn't so much the lack of a boolean type, but
that you couldn't assign the result of a logical expression to
a variable. Python has always been able to do that, even before
it had a distinct boolean type.

-- 
Greg

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

#5367

On Fri, May 13, 2011 at 10:34 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> rusi wrote:
>
>> Dijkstra's problem (paraphrased) is that python, by choosing the
>> FORTRAN alternative of having a non-first-class boolean type, hinders
>> scientific/mathematical thinking/progress.
>
> Python doesn't have the flaw that Dijkstra was talking about.
> Fortran's flaw wasn't so much the lack of a boolean type, but
> that you couldn't assign the result of a logical expression to
> a variable. Python has always been able to do that, even before
> it had a distinct boolean type.
And Fortran could do it at least 25 years before Python was invented.

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

#5369

In article <mailman.1549.1305383294.9059.python-list@python.org>,
 David Robinow <drobinow@gmail.com> wrote:

> On Fri, May 13, 2011 at 10:34 PM, Gregory Ewing
> <greg.ewing@canterbury.ac.nz> wrote:
> > rusi wrote:
> >
> >> Dijkstra's problem (paraphrased) is that python, by choosing the
> >> FORTRAN alternative of having a non-first-class boolean type, hinders
> >> scientific/mathematical thinking/progress.
> >
> > Python doesn't have the flaw that Dijkstra was talking about.
> > Fortran's flaw wasn't so much the lack of a boolean type, but
> > that you couldn't assign the result of a logical expression to
> > a variable. Python has always been able to do that, even before
> > it had a distinct boolean type.
> And Fortran could do it at least 25 years before Python was invented.

I vaguely remember that Fortran called the data type LOGICAL, but yes, 
it was exactly what most modern languages call a bool or boolean.  And 
the operators were spelled .NOT., .AND., .OR., etc but that's because 
Fortran was designed for punch cards, which didn't have much in the way 
of special characters.

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

#5344

On Thu, 12 May 2011 23:46:12 -0700, rusi wrote:

> Mathematics has existed for millenia. Hindu-arabic numerals (base-10
> numbers) have been known for about one millennium
> The boolean domain is only a 100 years old. Unsurprisingly it is not
> quite 'first-class' yet: See
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1070.html
> [Lifted from http://c2.com/cgi/wiki?EqualVsTrueFalse ]

Th money-quote as regards using arbitrary objects in truth tests:

    [quote]
    All this changed with the introduction of the two-element 
    boolean domain {true, false} which provides the vocabulary 
    needed to assign values to boolean expressions: 3<4 is a 
    way for writing true, 3>4 is a way for writing false, 
    whereas the value of x>0 depends on the value of x ...
    [end quote]


In Python, [1, 2, 3] is another way of writing true, and [] is another 
way of writing false. Similarly with any other arbitrary objects. The 
only things that bools True and False are good for are:

* giving functions a canonical way of spelling true/false when they want 
to emit a Boolean value;

* giving documentation writers a canonical way of spelling true/false 
when they want to discuss passing a Boolean value.

Other than those conveniences, there's nothing you can do with True and 
False in Python that you can't do with any other set of objects.


-- 
Steven

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

#5347

On May 14, 12:39 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Thu, 12 May 2011 23:46:12 -0700, rusi wrote:
> > Mathematics has existed for millenia. Hindu-arabic numerals (base-10
> > numbers) have been known for about one millennium
> > The boolean domain is only a 100 years old. Unsurprisingly it is not
> > quite 'first-class' yet: See
> >http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1070.html
> > [Lifted fromhttp://c2.com/cgi/wiki?EqualVsTrueFalse]
>
> Th money-quote as regards using arbitrary objects in truth tests:
>
>     [quote]
>     All this changed with the introduction of the two-element
>     boolean domain {true, false} which provides the vocabulary
>     needed to assign values to boolean expressions: 3<4 is a
>     way for writing true, 3>4 is a way for writing false,
>     whereas the value of x>0 depends on the value of x ...
>     [end quote]
>
> In Python, [1, 2, 3] is another way of writing true, and [] is another
> way of writing false. Similarly with any other arbitrary objects.

Well so is [1,2] another way of writing True

And then we get the interesting result that
(True = True) is False

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

#5364

On Sat, May 14, 2011 at 5:45 PM, rusi <rustompmody@gmail.com> wrote:
> And then we get the interesting result that
> (True = True) is False

How does this work? In Python, the = sign is illegal there, and if you
mean True == True, then it's True (obviously), which is not False.

Chris Angelico

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

#5371

On May 14, 6:42 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, May 14, 2011 at 5:45 PM, rusi <rustompm...@gmail.com> wrote:
> > And then we get the interesting result that
> > (True = True) is False
>
> How does this work? In Python, the = sign is illegal there, and if you
> mean True == True, then it's True (obviously), which is not False.
>
> Chris Angelico

1. = vs ==
Ok to be true to python syntax I should have said (True == True) is
False.
But then the question arises, is the is a python is or an English is?
If its python then that's fine but its just bland code with no
discussion about it.
To say something about it (in English) one would have to say
(True == True) is False is True (where the first is is a python is and
the second an English one).

2. True == True is (obviously) True

Here is the quote (with internal quote from Dijkstra) from Steven that
I was answering:

------------------------------
[Dijkstra quote]
    All this changed with the introduction of the two-element
    boolean domain {true, false} which provides the vocabulary
    needed to assign values to boolean expressions: 3<4 is a
    way for writing true, 3>4 is a way for writing false,
    whereas the value of x>0 depends on the value of x ...
    [end quote]

[Steven quote]
In Python, [1, 2, 3] is another way of writing true, and [] is another
way of writing false. Similarly with any other arbitrary objects. The
only things that bools True and False are good for are:
<snipped>
[end Steven quote]
------------------------

So since
[1,2,3] is one way of writing True (lets call it True3)
and [1,2] is another (call it True2)
then we have True3 == True2 is False

But since according to Steven (according to Python?) True3 *is the
same* as True2
we get
  False
= [1,2,3] == [1,2]
= True3  == True2
= True == True
= True

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

#5373

On Sun, May 15, 2011 at 1:47 AM, rusi <rustompmody@gmail.com> wrote:
> So since
> [1,2,3] is one way of writing True (lets call it True3)
> and [1,2] is another (call it True2)
> then we have True3 == True2 is False
>
> But since according to Steven (according to Python?) True3 *is the
> same* as True2
> we get
>  False
> = [1,2,3] == [1,2]
> = True3  == True2
> = True == True
> = True

Okay, I see what you're doing here.

http://www.rinkworks.com/ithink/search.cgi?words=compress

When you condense a whole lot of information down to just two states,
True and False, *obviously* there'll be a huge amount that fits into
one or the other without being identical. It's not an argument for
whether [1,2,3] ought to be True or ought to be False. You could make
the exact same argument if they evaluated to False. You have proven
nothing and just wasted your time proving it.

Chris Angelico

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

#5375

On May 14, 8:55 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, May 15, 2011 at 1:47 AM, rusi <rustompm...@gmail.com> wrote:
> > So since
> > [1,2,3] is one way of writing True (lets call it True3)
> > and [1,2] is another (call it True2)
> > then we have True3 == True2 is False
>
> > But since according to Steven (according to Python?) True3 *is the
> > same* as True2
> > we get
> >  False
> > = [1,2,3] == [1,2]
> > = True3  == True2
> > = True == True
> > = True
>
> Okay, I see what you're doing here.
>
> http://www.rinkworks.com/ithink/search.cgi?words=compress

LOL -- Thanks for that.

But it seems you did not get the moral? Spelt out: "Beware of lossy
compression!"
[Which is also the moral of my 'proof']

>
> When you condense a whole lot of information down to just two states,
> True and False, *obviously* there'll be a huge amount that fits into
> one or the other without being identical. It's not an argument for
> whether [1,2,3] ought to be True or ought to be False. You could make
> the exact same argument if they evaluated to False. You have proven
> nothing and just wasted your time proving it.
>
> Chris Angelico

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

#5389

On 5/14/2011 1:43 PM, rusi wrote:

> But it seems you did not get the moral? Spelt out: "Beware of lossy
> compression!"
> [Which is also the moral of my 'proof']

I get it now. As I suggested in response to Stephen, [] and [1] spell 
False and True only in boolean contexts (if/while headers) where they 
are implicitly wrapped with a bool() call, which is to say, where their 
boolean value is extracted from them. As you point out, there is 
information loss as all other context-irrelevant details are ignored.

-- 
Terry Jan Reedy

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

#5392

rusi <rustompmody@gmail.com> writes:

> [Steven quote]
> In Python, [1, 2, 3] is another way of writing true, and [] is another
> way of writing false. Similarly with any other arbitrary objects. The
> only things that bools True and False are good for are:
> <snipped>
> [end Steven quote]
> ------------------------
>
> So since
> [1,2,3] is one way of writing True (lets call it True3)

No. Steven knew exactly why he was using “true” versus “True”. He's
explained why elsewhere in this thread. The former does not refer to the
Python boolean singleton, the latter does.

The only object that is True is the True singleton. But there are many
objects that are true.

-- 
 \         “I got up the other day, and everything in my apartment has |
  `\   been stolen and replaced with an exact replica.” —Steven Wright |
_o__)                                                                  |
Ben Finney

[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