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

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

Re: checking if a list is empty

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.

Contents

  Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-06 15:31 -0400
    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-06 14:49 -0500
      Re: checking if a list is empty Adam Tauno Williams <awilliam@whitemice.org> - 2011-05-06 16:05 -0400
        Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-07 02:49 +0000
          Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 10:14 +0100
            Re: checking if a list is empty Laurent Claessens <moky.math@gmail.com> - 2011-05-11 11:48 +0200
              Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 11:14 +0000
                Re: checking if a list is empty Laurent Claessens <moky.math@gmail.com> - 2011-05-11 13:45 +0200
                Re: checking if a list is empty Laurent Claessens <moky.math@gmail.com> - 2011-05-11 13:45 +0200
            Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 13:36 +0000
              Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 15:00 +0100
                Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-12 00:46 +1000
                Re: checking if a list is empty Ethan Furman <ethan@stoneleaf.us> - 2011-05-11 08:53 -0700
                RE: checking if a list is empty "Prasad, Ramit" <ramit.prasad@jpmchase.com> - 2011-05-11 13:50 -0400
                  Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 19:15 +0100
                    RE: checking if a list is empty "Prasad, Ramit" <ramit.prasad@jpmchase.com> - 2011-05-11 14:59 -0400
                      Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 20:08 +0100
                    Re: checking if a list is empty Ethan Furman <ethan@stoneleaf.us> - 2011-05-11 12:17 -0700
                      Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 20:13 +0100
                        Re: checking if a list is empty Ian <hobson42@gmail.com> - 2011-05-11 22:02 +0100
                          Re: checking if a list is empty Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-05-22 22:41 +0200
                        Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 21:47 +0000
                          Re: checking if a list is empty Steven Howe <howe.steven@gmail.com> - 2011-05-11 15:09 -0700
                          Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-11 17:38 -0500
                            Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-11 18:12 -0500
                            Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-12 01:07 +0000
                          Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 06:21 +0100
                        Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-12 13:51 +1000
                        Re: checking if a list is empty Ethan Furman <ethan@stoneleaf.us> - 2011-05-12 07:02 -0700
                        Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-13 00:13 +1000
                        Re: checking if a list is empty Ian <hobson42@gmail.com> - 2011-05-22 10:20 +0100
                Re: checking if a list is empty Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-12 11:08 +1200
                  Re: checking if a list is empty John J Lee <jjl@pobox.com> - 2011-05-21 15:46 +0100
                    Re: checking if a list is empty Emile van Sebille <emile@fenx.com> - 2011-05-21 08:52 -0700
                    Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-21 16:11 -0400
                      Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-21 20:02 -0700
                        Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-22 13:52 +1000
                          Re: checking if a list is empty rusi <rustompmody@gmail.com> - 2011-05-21 21:32 -0700
                            Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-22 15:16 +1000
                    Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-22 01:02 +0000
                      Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-22 12:56 +1000
      Re: checking if a list is empty Chris Rebert <clp2@rebertia.com> - 2011-05-06 13:46 -0700
      Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-07 10:51 +1000
      Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-07 08:28 +0000
        Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-07 22:50 -0500
          Re: checking if a list is empty Ethan Furman <ethan@stoneleaf.us> - 2011-05-07 21:57 -0700
            Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 11:47 +0100
              Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 13:45 +0000
                Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 15:34 +0100
                  Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 16:26 +0000
                    Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 19:05 +0100
                      RE: checking if a list is empty "Prasad, Ramit" <ramit.prasad@jpmchase.com> - 2011-05-11 14:44 -0400
                        Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 20:26 +0100
                          Learning new languages (was: checking if a list is empty) Teemu Likonen <tlikonen@iki.fi> - 2011-05-12 06:37 +0300
                    Re: checking if a list is empty Chris Torek <nospam@torek.net> - 2011-05-11 19:05 +0000
                      Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-11 21:42 +0000
                        Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 07:23 +0100
                  Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-11 10:31 -0600
                    Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 18:46 +0100
              Re: checking if a list is empty "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-11 10:33 -0400
                Re: checking if a list is empty Redcat <redcat@catfolks.net> - 2011-05-11 15:31 +0000
                Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-11 18:44 +0100
                Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-11 16:24 -0500
                  Re: checking if a list is empty alex23 <wuwei23@gmail.com> - 2011-05-11 20:31 -0700
                    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-11 22:53 -0500
                      Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-12 06:13 +0000
                        Re: checking if a list is empty "rurpy@yahoo.com" <rurpy@yahoo.com> - 2011-05-12 10:42 -0700
                          Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-13 14:41 -0500
                            Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-13 14:21 -0600
                              Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-13 19:48 -0500
                                Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-13 19:52 -0600
                                  Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-13 23:47 -0500
                                    Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-14 00:14 -0600
                                Re: checking if a list is empty Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-14 14:32 +1200
                              Re: checking if a list is empty Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-14 14:26 +1200
                    Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 07:13 +0100
                      Re: checking if a list is empty Ben Finney <ben+python@benfinney.id.au> - 2011-05-12 16:46 +1000
                        Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 08:28 +0100
                          Re: checking if a list is empty Ben Finney <ben+python@benfinney.id.au> - 2011-05-12 17:37 +1000
                  Re: checking if a list is empty "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-12 01:49 -0400
                    Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 07:21 +0100
                      Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-12 22:16 +1000
                        Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-12 13:43 +0100
                          Re: checking if a list is empty Chris Angelico <rosuav@gmail.com> - 2011-05-12 23:20 +1000
                            Re: checking if a list is empty Hans Georg Schaathun <hg@schaathun.net> - 2011-05-13 09:47 +0100
          Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-08 14:07 +0000
            Re: checking if a list is empty Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-05-08 18:59 +0300
            Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-08 18:41 -0400
            Re: checking if a list is empty Michael Torrie <torriem@gmail.com> - 2011-05-08 21:31 -0600
            Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-08 22:33 -0500
              Re: checking if a list is empty Ian Kelly <ian.g.kelly@gmail.com> - 2011-05-08 22:34 -0600
                Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-09 16:58 -0500
                  Re: checking if a list is empty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-09 23:34 +0000
                    Re: checking if a list is empty Ben Finney <ben+python@benfinney.id.au> - 2011-05-10 09:54 +1000
                    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-09 19:10 -0500
                    Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-09 19:19 -0500
              Re: checking if a list is empty James Mills <prologic@shortcircuit.net.au> - 2011-05-09 14:46 +1000
            Re: checking if a list is empty harrismh777 <harrismh777@charter.net> - 2011-05-08 22:56 -0500
            Re: checking if a list is empty Terry Reedy <tjreedy@udel.edu> - 2011-05-09 17:30 -0400
            Re: checking if a list is empty Chris Torek <nospam@torek.net> - 2011-05-12 03:49 +0000

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#5205

On Thu, 12 May 2011 01:49:05 -0400, D'Arcy J.M. Cain
  <darcy@druid.net> wrote:
:  That's not programming.  That's using a canned app that a programmer
:  wrote that takes your unstructured input and does something useful with
:  it.  Spreadsheets are a primitive example of that.  Google is a more
:  advanced example.

You are really trying to defend the programmers' status as a modern
day priesthood, mastering a mystic art completely inaccessible to
those not initiated.  

For ages, the literate elite deliberately made the language cryptic
to protect their art and their status.  Some programmers seem to do
the same.

The fact is that it is not black and white.  There are programmers
with domain expertise, programmers without domain expertise, 
domain experts with decent programming skills, domain experts with
rudimentary programming skills, monolingual programmers, domain
experts without programming skills, polyglot programmers etc.

Only very narrow-purpose applications can be created by one of
these groups on their own, and to collaborate their abilities
must be overlapping.

-- 
:-- Hans Georg

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

#5229

On Thu, May 12, 2011 at 4:21 PM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Thu, 12 May 2011 01:49:05 -0400, D'Arcy J.M. Cain
>  <darcy@druid.net> wrote:
> :  That's not programming.  That's using a canned app that a programmer
> :  wrote that takes your unstructured input and does something useful with
> :  it.  Spreadsheets are a primitive example of that.  Google is a more
> :  advanced example.
>
> You are really trying to defend the programmers' status as a modern
> day priesthood, mastering a mystic art completely inaccessible to
> those not initiated.

Anyone can join. Not everyone wants to join. Me, I'm happy here as a
priest of the software industry, and I have no desire to become a
priest of, say, automotive engineering or concrete pouring. Would an
expert concreter be expected to explain to me exactly how to make
different sorts of concrete, or would he be expected simply to fulfill
his contract and provide me with my structure?

Chris Angelico

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

#5232

On Thu, 12 May 2011 22:16:10 +1000, Chris Angelico
  <rosuav@gmail.com> wrote:
:  Anyone can join. Not everyone wants to join. Me, I'm happy here as a
:  priest of the software industry, and I have no desire to become a
:  priest of, say, automotive engineering or concrete pouring. Would an
:  expert concreter be expected to explain to me exactly how to make
:  different sorts of concrete, or would he be expected simply to fulfill
:  his contract and provide me with my structure?

Of course he would.  When a piece of software to calculate the
properties or recipes for different kinds of concrete is needed.

-- 
:-- Hans Georg

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

#5234

On Thu, May 12, 2011 at 10:43 PM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> On Thu, 12 May 2011 22:16:10 +1000, Chris Angelico
>  <rosuav@gmail.com> wrote:
> :  Anyone can join. Not everyone wants to join. Me, I'm happy here as a
> :  priest of the software industry, and I have no desire to become a
> :  priest of, say, automotive engineering or concrete pouring. Would an
> :  expert concreter be expected to explain to me exactly how to make
> :  different sorts of concrete, or would he be expected simply to fulfill
> :  his contract and provide me with my structure?
>
> Of course he would.  When a piece of software to calculate the
> properties or recipes for different kinds of concrete is needed.

Writing a program requires expertise both in programming and in the
purpose for which it's being written. Ultimately, a programmer is a
translator; without proper comprehension of the material he's
translating, he can't make a clear translation. But that's completely
different from hiring someone to do a job, and then looking at the job
afterwards; if I order a concreting job, I'll look at whether it's
properly suited to the task, but I won't expect an explanation of
exactly what went into it, and I do not expect to understand the exact
chemistry of it. Only another expert in concrete would truly
comprehend it all.

Chris Angelico

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

#5285

On Thu, 12 May 2011 23:20:20 +1000, Chris Angelico
  <rosuav@gmail.com> wrote:
:  Writing a program requires expertise both in programming and in the
:  purpose for which it's being written. Ultimately, a programmer is a
:  translator; without proper comprehension of the material he's
:  translating, he can't make a clear translation. But that's completely
:  different from hiring someone to do a job, and then looking at the job
:  afterwards;

True.  When you are able completely to specify the job and commission 
it, then it is possible to isolate the disciplines, and reduce the
programmer to translator.

The challenge is that that very often is not the case.  

The double challenge in computing is that software its development 
is still not as well understood as hardware or construction.
We still do not have sufficient tools, experience and frameworks
to project and precisely plan a software development projects.
They go over time, over budget, and under specifications far more
often and more seriously than projects in other disciplines.
Civil and electronic engineers spend much of their time learning to
project and cost solutions.  Computer engineers very rarely do; they
just hack it.  In other trades, there tend to be clear role divisions
with different roles and specialisations, complementing eachothers.
We have not yet quite managed to work out what a programmer, architect,
designer, engineer, et cetera are in software.  We have the idea that
we need them, but we have not formalised them to the point where we
know what to expect from each role, and we struggle communicating
between them.

Therefore, a programmer is not just a translator.  The language to
specify precisely what is required is not good enough, and therefor
the programmer also needs to be a system designer, to some extent.
What extent depends much on the situation.

From my point of view, it is just harder to instruct a programmer
to write a code than it is to instruct a python interpreter.

:              if I order a concreting job, I'll look at whether it's
:  properly suited to the task, but I won't expect an explanation of
:  exactly what went into it, and I do not expect to understand the exact
:  chemistry of it. Only another expert in concrete would truly
:  comprehend it all.

Now you are thinking black and white, while reality is a gray blur.
You may not care about your concrete, but someone commissioning
concrete to build a skyscraper would surely want to check the
spec's to quite some level of detail.  The construction engineers
will surely need to know a lot more about the exact composition and 
science behind the recipe than the manager renting the top floor,
and still much less than the concrete engineer.

And the main difference here, is that the civil engineers have a much
better language to share information.  The best programmers have is
the programmming language, and we ought to make that as good as
possible.

-- 
:-- Hans Georg

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

#4958

On Sat, 07 May 2011 22:50:55 -0500, harrismh777 wrote:

> Steven D'Aprano wrote:

>>> >  and implies in any case that li does not exist
>> It does nothing of the sort. If li doesn't exist, you get a NameError.
> 
>       That was the point.   'not' implies something that is not logical;

I'm afraid that makes no sense to me. How does "does not exist" imply 
something not logical? In what way is "this is not my house" implying 
something not logical?


> which is irony extreme since 'not' is typically considered a logical
> operator.

Because "not" is typically used as a logical operator.

In English, it negates a word or statement:

"the cat is not on the mat" --> "the cat is on the mat" is false.

As an operator, "not" negates a true value to a false value. In 
mathematical Boolean algebra, there only is one true value and one false 
value, conventionally called True/False or 1/0. In non-Boolean algebras, 
you can define other values. In three-value logic, the negation of True/
False/Maybe is usually False/True/Maybe. In fuzzy logic, the logic values 
are the uncountable infinity (that's a technical term, not hyperbole) of 
real numbers between 0 and 1.

Python uses a boolean algebra where there are many ways of spelling the 
true and false values. The "not" operator returns the canonical bool 
values:

not <any true value> returns False
not <any false value> returns True

Take note of the distinction between lower-case true/false, which are 
adjectives, and True/False, which are objects of class bool.

This is not unique to Python. I understand the practice of allowing any 
value to be used in boolean expressions comes from Lisp in 1958, which 
makes it practically antediluvian.

Lisp uses the empty list and the special atom NIL as false values, any 
other s-expression is true. Scheme is different: it defines a special 
false atom, and empty lists are considered true. In Ruby, only the false 
object and the null object are considered false. In Forth, any non-zero 
word is true. In Javascript, the empty string, null, undefined, NaN, +0, 
-0, and false are all considered false.



> What does it mean to say  not <list name>?  Well, apparently
> it means the list is 'empty'... but why should it mean that? 

Because that is the definition chosen by the language designers. It is 
based on the fact that distinguishing between "something" and "nothing" 
is useful, common, fundamental, and applies to nearly all data types.


> Why not
> have it mean the list has been reversed in place?  Why not have it mean
> that the list isn't homogeneous?  Why not have it mean that its not
> mutable?  I could think of more... 

Because those tests are not fundamental tests that deserve to be elevated 
to a language design feature, any more than we need a built-in function 
to add 27 and three quarters to the argument.


> Why should 'not' mean 'empty'?

Because the test of "is this nothing, or something?" is a common, useful 
test:

0 (nothing) vs 1, 2, 3, ... (something)
empty list versus non-empty list
empty dict versus non-empty dict
empty set versus non-empty set
empty string versus non-empty string
no search results returned versus some search results returned
no network connection available versus some network connection available
no food in the cupboard versus food in the cupboard

This is a fundamental distinction which is very useful in practice. 


>>> >  or worse is some kind of boolean.
>> Only if you're still thinking in some language that isn't Python.
> 
>     Which most of us are... hate to remind you...   

Time to stop then. This is Python, not whatever language you're thinking 
in. Don't force language A into the conceptual pigeonholes of language B. 
To be effective in a programming language, you need to understand how 
that language works, and not see everything filtered through the 
conceptual framework of another language.

Bringing the viewpoints of other languages is a good thing. Python 
borrows concepts from many languages (sometimes what it borrows is the 
idea of "that's not how to do it"). And many idioms do cross language 
boundaries. But in general, it pays to think, and code, in the 
appropriate style for whatever language you are writing in. And 
certainly, you should not argue that a language feature is invalid or 
wrong merely because that's not how another language does it.

Or, to put it another way:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-is-not-python-either.html



> Python is the new kid on the block, 

Nonsense. Python is 20 years old (1991), which makes it older than:

Java, PHP, Ruby (1995)
Javascript (1996)
C# (2000)
Visual Basic .Net (2001)

to say nothing of dozens of other languages.


> and most of us are coming at this from multiple
> filters in comp sci experience.  Its just the truth.

There's nothing wrong with having experience in many languages. That's a 
good thing.




-- 
Steven

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

#4959

Steven D'Aprano writes:

> Lisp uses the empty list and the special atom NIL as false values,
> any other s-expression is true. Scheme is different: it defines a
> special false atom, and empty lists are considered true. In Ruby,

I'll inject a pedantic note: there is only one false value in both
Lisp (which now is mostly Common Lisp) and Scheme.

The empty list () and the symbol NIL in Lisp are one value, not two
values. The first Google hit (for me, just now) explains it the way I
understand it: <http://www.ida.liu.se/imported/cltl/clm/node9.html>.
(Common Lisp The Language, 2nd edition. Odd place to find that book.
It predates the formal standard, but then I think this particular
feature of the language is, indeed, as old as you say, and unlikely to
have changed.)

Scheme was the same. Then for a time it was not specified whether the
empty list was distinct from the false value or the symbol nil -
people disagreed and implementations were allowed to differ - until
the three were definitely separated.

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

#4965

On 5/8/2011 10:07 AM, Steven D'Aprano wrote:

> Because the test of "is this nothing, or something?" is a common, useful
> test:

Because inductive algorithms commonly branch on 'input is something' 
(not done, change args toward 'nothing'and recurse or iterate) versus 
'input is nothing (done, return base expression).

> 0 (nothing) vs 1, 2, 3, ... (something)
> empty list versus non-empty list
> empty dict versus non-empty dict
> empty set versus non-empty set
> empty string versus non-empty string

and non-inductive algorithms also branch on the same question.

> no search results returned versus some search results returned
> no network connection available versus some network connection available
> no food in the cupboard versus food in the cupboard
>
> This is a fundamental distinction which is very useful in practice.

Definitely. Python commonly hides the distinction inside of iterators 
called by for statememts, but StopIteration is understood as 'collection 
is empty'. An I suspect something vs. nothing is also the most common 
overt condition in if and while statements.

-- 
Terry Jan Reedy

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

#4972

On 05/08/2011 05:36 PM, Dan Stromberg wrote:
> Just what is an inductive algorithm?

>From what I can remember, it's just an implementation of a proof
essentially.  Any algorithm that can be inductively proven can be
implemented with recursion and specific base cases.  In other words you
program just like you'd do the proof.  First you deal with the base
cases and then you can call yourself for F(n) and F(n-1).  The inductive
proof provides the pattern for the code.

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

#4974

Steven D'Aprano wrote:
>> which is irony extreme since 'not' is typically considered a logical
>> >  operator.
> Because "not" is typically used as a logical operator.
>
> In English, it negates a word or statement:
>
> "the cat is not on the mat" -->  "the cat is on the mat" is false.

    Your pedantic bogus cat analogy talks past my point entirely, as 
well as making you look silly... if you would stop being pedantic long 
enough to think about what I'm saying you might come to some 
understanding...

... yes, 'not' is a logical negation. Why would you waste time with a 
pedantic explanation of 'not' ?   Wait--- its a rhetorical question...


    Why should the negation of a list imply that the list empty?  ... 
nor any other abstract condition which is not well suited to 'not' ? 
(forget python for a moment... then move on to my argument...)

    What made the python development team (or individual) decide that 
the logical construct   'not list'   would return True if the list is 
empty?   To say that "This is the way we do it in Python because Python 
does it this way"---  goes beyond pedantic becoming circular and redundant.

    On the other hand, if you were to tell me *why* you think that the 
logical construct 'not list' should be logically True when the list is 
empty--- when clearly negating a list would not necessarily mean to make 
the list empty (including destroying it)... then you might be seeing my 
point.

    Here's the bottom line you missed...

... although syntactically correct, the following test is not a logical 
construct that makes sense (except for the syntactically initiated):

     if not list      <=====  this makes no logical sense...

     ... to test for an empty list . . .

     ... although, it is legal syntax.   :-}


    I know that is the way Python does it... I've been coding it that 
way for a long time...  but that doesn't answer my concern....


    To say this another way, IMHO,

         if not list


         ...  should return True only if 'list' is bound to NULL, or if 
the name 'list' would throw a name exception...

         ...  and, Python should have an explicit way of testing for an 
empty list that is clear, concise, and easy to understand even for the 
relatively new Python programmer.  This is not intended to generate 
counter argument, its just my feedback on a language construct that I 
find to be inconsistent logically. ... Please, no pedantic discourse 
explaining why I'm wrong... just put in into a PEP and move on.  :)





kind regards,
m harris

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

#4977

On Sun, May 8, 2011 at 9:33 PM, harrismh777 <harrismh777@charter.net> wrote:
>   Why should the negation of a list imply that the list empty?  ... nor any
> other abstract condition which is not well suited to 'not' ? (forget python
> for a moment... then move on to my argument...)
>
>   What made the python development team (or individual) decide that the
> logical construct   'not list'   would return True if the list is empty?
> To say that "This is the way we do it in Python because Python does it this
> way"---  goes beyond pedantic becoming circular and redundant.
>
>   On the other hand, if you were to tell me *why* you think that the logical
> construct 'not list' should be logically True when the list is empty--- when
> clearly negating a list would not necessarily mean to make the list empty
> (including destroying it)... then you might be seeing my point.

"bool(list)" describes whether the list contains something.  "Not"
being a logical operator, it stands to reason that "not list" should
mean the same thing as "not bool(list)".  Anything else would be
surprising and pointlessly convoluted.  If "not list" bothers you,
then I would suggest that your problem is actually with "bool(list)".

>        ...  should return True only if 'list' is bound to NULL, or if the
> name 'list' would throw a name exception...

Why?  Should "not False" return True only if "False" is bound to NULL
(whatever you mean by that), or if the name "False" would throw a name
exception?

>        ...  and, Python should have an explicit way of testing for an empty
> list that is clear, concise, and easy to understand even for the relatively
> new Python programmer.  This is not intended to generate counter argument,
> its just my feedback on a language construct that I find to be inconsistent
> logically. ... Please, no pedantic discourse explaining why I'm wrong...
> just put in into a PEP and move on.  :)

It does.  "if len(list) == 0"

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

#5037

Ian Kelly wrote:
> "bool(list)" describes whether the list contains something.  "Not"
> being a logical operator, it stands to reason that "not list" should
> mean the same thing as "not bool(list)".

Ian, James,

    Agreed, and thank you.  This *is* the explanation I was trying to 
prompt D'Aprano for, rather than getting his 'not cat' analogy.

    James, the argument is not for argument sake. The argument is to 
better facilitate understanding for others who are also trying to make 
sense of new ideas, some of whom are lurking.  :)   This argument 
actually goes back to a previous discussion D'Aprano and I (and others) 
were having pertaining to whether software is mathematics.

    It is easy to see how that negating a binary value ( on or off ) 
works with 'not'...   because there are only two possible states.

not on, means off....   not off, means on.

Same with '1' and '0'  where we have only two states, or True and False 
where we have only two states... &etc.   But when we have a list, what 
two states are we really discussing?  Aren't we really talking about set 
theory?  A list is an ordered collection of 'stuff' comprising a set. 
Negating the set   'not set'  is saying   'not bool(set)'  /

The two states are either 1) the elements of the set, or 2) not the 
elements of the set--- the empty set, or that 'stuff' outside the set.

The answer to the 'not list' question has to do with the conceived 
semantics of Python ordered collections, which are based more in 
mathematics proper (set theory) than in logic--- the 'not' operator. It 
is better to explain to students where the syntax is based (as Ian did) 
than to state uniformly, "This is just the way Python does it!".

As a side point, the answer, "This is the way Python does it!"... would 
be o.k. if-and-only-if Python were a standardized language, which it 
isn't.   Python's greatest strength is also its greatest weakness... 
that it is constantly evolving through the PEP process. James, one of 
the reasons we argue about language features is for that very purpose 
invited by PEP (and other feedback mechanisms, including this list). The 
community decides over time how Python does things (along with the final 
stamp, I suppose, of Guido the BDFL). So, we must needs be arguing, but 
its not for pedantic squabbling sake....   :-)


kind regards,
m harris

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

#5039

On Mon, 09 May 2011 16:58:14 -0500, harrismh777 wrote:

> Ian Kelly wrote:
>> "bool(list)" describes whether the list contains something.  "Not"
>> being a logical operator, it stands to reason that "not list" should
>> mean the same thing as "not bool(list)".
> 
> Ian, James,
> 
>     Agreed, and thank you.  This *is* the explanation I was trying to
> prompt D'Aprano for, rather than getting his 'not cat' analogy.

Your dislike of analogies is leading you to see them where they aren't. 
The "cat on the mat" sentence I gave is a concrete example of the use of 
negation in English, not an analogy. It is virtually the opposite of an 
analogy.

In that same post that annoyed you with the cat on the mat example, I 
wrote:

    Python uses a boolean algebra where there are many ways of 
    spelling the true and false values. The "not" operator returns 
    the canonical bool values:

    not <any true value> returns False
    not <any false value> returns True

    Take note of the distinction between lower-case true/false, 
    which are adjectives, and True/False, which are objects of 
    class bool.

and later on, I contrasted:

    empty list versus non-empty list

Ergo, "not (empty list)" returns True, and "not (non-empty list)" returns 
False, because the empty list is considered false and any non-empty list 
is considered true. I'm sorry that I failed to make that more explicit. 
If I were talking to a programming n00b, I would have been more careful, 
but you've made numerous references to your long, long programming 
experience and I thought you would be able to draw the obvious connection 
without me insulting you by stating the obvious.



-- 
Steven

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

#5040

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> I'm sorry that I failed to make that more explicit. If I were talking
> to a programming n00b, I would have been more careful, but you've made
> numerous references to your long, long programming experience and I
> thought you would be able to draw the obvious connection without me
> insulting you by stating the obvious.

+1 QOTW

-- 
 \       “Never use a long word when there's a commensurate diminutive |
  `\                                    available.” —Stan Kelly-Bootle |
_o__)                                                                  |
Ben Finney

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

#5042

Steven D'Aprano wrote:
>      Python uses a boolean algebra where there are many ways of
>      spelling the true and false values. The "not" operator returns
>      the canonical bool values:

>      Take note of the distinction between lower-case true/false,
>      which are adjectives, and True/False, which are objects of
>      class bool.

    Yes, yes... to your previous comments, and to move the discussion 
forward a bit...

...  the interesting thing about this part of the discussion is the 
class bool... because it looks like 'list' is being 'promoted' to type 
class bool in the following:

     if not list:   <=== this is not logical on the surface...

... if the equivalent is:

     if not bool(list):   <=== this is more explicit, and more readable 
although it still doesn't tell a casual reader how the bool(list) 
evaluates... is it empty? is it name exception? other?   I'm just 
saying; no need to respond...  just that its easier to understand the 
syntax of 'not list' in the knowledge that what is happening under the 
hood is that the 'not' operator does require a bool() and that list is 
being evaluated bool(list) as one of two logical states.


     Having played around a little bit with this today I am again 
impressed that bool() can take *any* object as a parm and derive the 
correct binary state, whatever that happens to be:

bool({})     False
bool([])     False
bool(0)      False
bool('')     False
bool(())     False


    Therefore,

    if not str      tests for the empty string...

    if not dict     tests for the empty dictionary...

    &etc.


     ... is at least consistent ...


kind regards,
m harris

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

#5043

Steven D'Aprano wrote:
> If I were talking to a programming n00b, I would have been more careful,
> but you've made numerous references to your long, long programming
> experience and I thought you would be able to draw the obvious connection
> without me insulting you by stating the obvious.

Pedantics is always potentially insulting, which was your intent, me 
thinks. Whether I choose to be insulted is my own prerogative, and I 
choose to 'not' be insulted. I would only suggest an argumentation style 
that is clear, 'not' pedantic, and 'not' potentially insulting when 
possible. (not necessarily for my sake)

uh,  not bool(insulting)




kind regards,
m harris

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

#4979

On Mon, May 9, 2011 at 2:34 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> "bool(list)" describes whether the list contains something.  "Not"
> being a logical operator, it stands to reason that "not list" should
> mean the same thing as "not bool(list)".  Anything else would be
> surprising and pointlessly convoluted.  If "not list" bothers you,
> then I would suggest that your problem is actually with "bool(list)".

I concur! +1

>>        ...  should return True only if 'list' is bound to NULL, or if the
>> name 'list' would throw a name exception...

[...]

>>        ...  and, Python should have an explicit way of testing for an empty
>> list that is clear, concise, and easy to understand even for the relatively
>> new Python programmer.  This is not intended to generate counter argument,
>> its just my feedback on a language construct that I find to be inconsistent
>> logically. ... Please, no pedantic discourse explaining why I'm wrong...
>> just put in into a PEP and move on.  :)
>
> It does.  "if len(list) == 0"

Again +1 on the if len(list) == 0:

Now... One thing that really concerns me about the Python
community as a whole is the no. of varying opinions of
"correct" ways of doing things and the distaste for a lot of
things (which in Python are just obvious).

If you are an opinionated individuals and disagree with the
suggestion (even if it is "right"), perhaps keep that to yourself.

if not my_list:

is a perfectly valid and fine idiom to use in Python.

If you prefer some other way, that's fine. Quite frankly
I'm sick of seeing posts that argue for the sake of arguing.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

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

#4975

Steven D'Aprano wrote:
>> Python is the new kid on the block,
> Nonsense. Python is 20 years old (1991), which makes it older than:
>
> Java, PHP, Ruby (1995)
> Javascript (1996)
> C# (2000)
> Visual Basic .Net (2001)

    Python is the new kid on the block.


    ... not chronologically perhaps, but measured in terms of acceptance 
and widespread use it is only really now coming into its own. It usually 
takes an advance in technology about 20 - 25 years to catch on... and 
Python has finally arrived IMHO.

    As an example of this... in many default setups in linux distros 
today Python is now the default 'Programming' environment. This was not 
true in 1991, nor was it true in 2001... in fact, this has not been true 
until the past couple of years. Python is catching on in the community 
at large... not just specialized development shops. As I've given my 
opinion before on this list, Python is finally becoming the New BASIC 
for 'people'.

    Python is also the new kid on the block in educational settings. 
Haskell and Erlang have dominated for some time now (in fact, many 
colleges and universities have focused beginning classes on pure 
functional programming)... and before that Pascal and Lisp... and in 
limited ways C  or C++  ./  Python is moving into that arena lately.

    For me personally, the environment provided by TCL/Tk was the way 
for many years... TCL was the glue, Tk was the graphics, and 'C' was the 
engine  (it all works together seamlessly with great performance and 
minimal lines of coding).  Python takes it up a notch; big time. 
Because, as you've pointed out, less has to be written in 'C'.  Almost 
all of the app can be written in Python, with only one (or three) mods 
written in 'C'... frankly, for most scripting, the whole thing can be 
written in Python. But *this* is a relatively *new* discovery for much 
of the community at large. (I'm not talking here about Google, nor YouTube).

    Linux is in this same boat... Linux is twenty years old; however, 
Linux has not enjoyed wide-spread use on the Desktop (until this year, 
and part of last) and has only enjoyed wide-spread use on servers over 
the past ten years. Linux is now coming into its own, and when 
everything is said and done and all the dust settles history is going to 
find Windows as a minor footnote in personal computing (I'm talking 100 
years from now).

    Linux is the new kid on the block, twenty years old and kicking 
it...   Python is the new kid on the block... twenty years old and 
kicking it....  many of us are catching up with the new trend; however, 
we will be evaluating the new trends through historic filters. This 
cannot be avoided--- for linux, nor for python.


kind regards,
m harris

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

#5034

On 5/8/2011 7:36 PM, Dan Stromberg wrote:
>
> On Sun, May 8, 2011 at 3:41 PM, Terry Reedy <tjreedy@udel.edu
> <mailto:tjreedy@udel.edu>> wrote:

>     Because inductive algorithms commonly branch on 'input is something'
>     (not done, change args toward 'nothing'and recurse or iterate)
>     versus 'input is nothing (done, return base expression).
>
>
> Just what is an inductive algorithm?

The parenthesized comments were meant to define common patterns such as:

def f(x):
   if x:
     return g(f(reduce_arg(x))
   else:
     return base(x)

def f(x)
   ret = start(x)
   while x:
     ret = reduce_arg(x)
   return x

More generally, an inductive algorithm computes by looping (with 
recursion or iteration). That is my definition. That includes most of 
the 'interesting' algorithms. You might ask, what is not an inductive 
algorithm? One that does no looping and just returns non-recursive 
expressions, perhaps in multiple branches. The functions in the 
expression are taken as primitives and their internal use of induction 
is ignored. Of course, a computer is nothing but an induction machine:

while not halted:
   get next instruction
   get args
   compute result

Michal Torrie's response is right. Inductive algorithms follow the 
pattern of inductive proofs.

-- 
Terry Jan Reedy

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

#5188

In article <4dc6a39a$0$29991$c3e8da3$5496439d@news.astraweb.com>
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>In English, [the word "not"] negates a word or statement:
>
>"the cat is not on the mat" --> "the cat is on the mat" is false.

As a mostly off topic aside, English is considerably more complicated
than that.  There are people who use the word "not" as a purely
boolean operator (a la computer languages), so that "the cat is
not not on the mat" means "the cat IS on the mat", but others use
double negation as a form of intensifier, so that the phrase with
multiple "not"s is simply a more emphatic claim: the cat is really,
truly, *definitely*, not on that particular mat. :-)

In various other "natural languages" -- i.e., languages meant for
human-to-human communications, rather than for computers -- multiple
negatives are more often (or always?) intensifiers.  Some languages
have the idea of "negative matching" in much the same sense that
English has number [%] matching: "the cat is on the mat" and "the cats
are on the mat" are OK because the noun and verb numbers match,
but neither "the cats is on the mat" nor "the cat are on the mat"
are correct.

[% "Number" here is really 1 vs not-1: no cats, one cat, two cats.]

Of course, there are descriptivists and prescriptivists, and many
of the latter claim that using multi-valued boolean logic in English
is "nonstandard" or "invalid".  Many of those in turn will tell
you that "ain't good English" ain't good English.  Still, one should
be aware of these forms and their uses, in much the same way as
one should be able to boldly split infinitives. :-)

Moving back towards on-topic-ness:

>As an operator, "not" negates a true value to a false value. In 
>mathematical Boolean algebra, there only is one true value and one false 
>value, conventionally called True/False or 1/0. In non-Boolean algebras, 
>you can define other values. In three-value logic, the negation of True/
>False/Maybe is usually False/True/Maybe. In fuzzy logic, the logic values 
>are the uncountable infinity (that's a technical term, not hyperbole) of 
>real numbers between 0 and 1.

Or, to put it another way, before we can communicate clearly, we have
to pick out a set of rules.  Most computer languages do this pretty
well, and Python does a good (and reasonably conventional) job:

>Python uses a boolean algebra where there are many ways of spelling the 
>true and false values. The "not" operator returns the canonical bool 
>values:
>
>not <any true value> returns False
>not <any false value> returns True
>
>Take note of the distinction between lower-case true/false, which are 
>adjectives, and True/False, which are objects of class bool.

(At least as of current versions of Python -- in much older versions
there was no real distinction between booleans and type "int",
presumably a a holdover from C.)

[remainder snipped as I have nothing else to add]
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

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

csiph-web