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 1 of 5  [1] 2 3 4 5  Next page →

#4852 — Re: checking if a list is empty

On 5/6/2011 7:34 AM, James Mills wrote:
> On Fri, May 6, 2011 at 4:36 PM, Jabba Laci<jabba.laci@gmail.com>  wrote:
>> If I want to check if a list is empty, which is the more pythonic way?
>
> [...]
>
>> (2) if not li:
>
> This is fine.

This is the intended way. Anything in addition is extra noise and wasted 
calculation. In other words, let Python do the boilerplate work for you.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#4856

Terry Reedy wrote:
>>> (2) if not li:
>>
>> This is fine.
>
> This is the intended way. Anything in addition is extra noise and wasted
> calculation. In other words, let Python do the boilerplate work for you.

    I agree, but I don't like it.

... if not li  says nothing about what li is supposed to 'be' and 
implies in any case that li does not exist, or worse is some kind of 
boolean.

    li is in fact an empty list [] and will identify as such, and of 
course (as a list object) has all of the attributes and methods of a list...

    Why not have a list method that makes this more explicit:


    if not li.emptylist()

    if not li.empty([])

       there might be others...



kind regards,
m harris

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

#4863

On Fri, 2011-05-06 at 14:49 -0500, harrismh777 wrote:
> Terry Reedy wrote:
> >>> (2) if not li:
> >> This is fine.
> > This is the intended way. Anything in addition is extra noise and wasted
> > calculation. In other words, let Python do the boilerplate work for you.
>     I agree, but I don't like it.

+1  This is the Python reality-distortion-field at work.

Motto#1: Python is all about readability!
Motto#2: Crytic code is awesome if it is Pythoncally cryptic!

I'd never accept code like "if not x" as an empty test.

> ... if not li  says nothing about what li is supposed to 'be' and 
> implies in any case that li does not exist, or worse is some kind of 
> boolean.
> li is in fact an empty list [] and will identify as such, and of 
> course (as a list object) has all of the attributes and methods of a list...
> Why not have a list method that makes this more explicit:
> if not li.emptylist()
> if not li.empty([])
> there might be others...

Good luck.  Just code -
  # You can immediately tell what this is meant to do!
  if len(x) == 0:  
- and ignore the Pythonistas [they're nuts;  that x.count() doesn't work
is amazingly stupid].

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

#4882

On Fri, 06 May 2011 16:05:09 -0400, Adam Tauno Williams wrote:

> I'd never accept code like "if not x" as an empty test.

So much the worse for you then.

The point of the "if x" idiom is that it is a polymorphic test which is 
independent of the type. It works with any non-broken object[1], no 
matter what x is, since it allows x to decide for itself whether it is 
empty or not.

Of course, you can write your own polymorphic test:


try:
    flag = len(x) == 0
except TypeError:
    # This *should* succeed, for anything not broken. If not, we can't
    # recover, so just let the exception propagate.
    flag = bool(x)
    # Hilariously, bool(x) may also try len(x) == 0... oh well.
if flag:
    ...

Congratulations! You've now found a way to write "if x:" in five lines, 
53 characters (plus whitespace and comments) and an extraneous variable 
polluting the namespace. If you're being paid per line of code, this is a 
good win.

Of course, sometimes you don't want polymorphism (or at least, not too 
much polymorphism). Sometimes I'll write "if x == 0" or similar if I want 
to emphasize that x is a special case unrelated to the truth/falseness of 
x. But that's quite rare. Normally I trust x to decide for itself whether 
it is empty or not.





[1] Arguably with the exception of iterables. But then the len(x) test 
doesn't work for them either.


-- 
Steven

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

#5101

On 07 May 2011 02:49:53 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  On Fri, 06 May 2011 16:05:09 -0400, Adam Tauno Williams wrote:
: 
: > I'd never accept code like "if not x" as an empty test.
: 
:  So much the worse for you then.
: 
:  The point of the "if x" idiom is that it is a polymorphic test which is 
:  independent of the type.

Normally, polymorphisms implies multiple forms only, where the different
forms has some form of common interpretation.  That's what makes
polymorphism useful and helpful, increasing legibility.

In this case, the interpretation of an arbitrary object as a boolean
is peculiar for python.  An empty list is a real, existing object, and 
the supposition that [] be false is counter-intuitive.  It can be
learnt, and the shorthand may be powerful when it is, but it will 
confuse many readers.

-- 
:-- Hans Georg

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

#5102

> In this case, the interpretation of an arbitrary object as a boolean
> is peculiar for python.  An empty list is a real, existing object, and
> the supposition that [] be false is counter-intuitive.  It can be
> learnt, and the shorthand may be powerful when it is, but it will
> confuse many readers.

Once I wrote something like:

def f(x=None):
    if x:
       print x
    else:
       print "I have no value"


The caller of that function was something like f(cos(2*theta)) where 
theta come from some computations.

Well. When it turned out that theta was equal to pi/4, I got "I have no 
value". I spent a while to figure out the problem :)

Conclusion: the boolean value of an object is to be used with care in 
order to tests if an optional parameter is given or not (when default 
value is None).


Have a good noon
Laurent

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

#5105

On Wed, 11 May 2011 11:48:16 +0200, Laurent Claessens wrote:

> Once I wrote something like:
> 
> def f(x=None):
>     if x:
>        print x
>     else:
>        print "I have no value"
> 
> 
> The caller of that function was something like f(cos(2*theta)) where
> theta come from some computations.
> 
> Well. When it turned out that theta was equal to pi/4, I got "I have no
> value". I spent a while to figure out the problem :)

I believe you are grossly oversimplifying whatever code you had. Using 
the definition of f from above:

>>> theta = math.pi/4
>>> f(math.cos(2*theta))
6.12303176911e-17

But even if you rounded the result of cos(2*theta) to zero, you will get 
the same result regardless of whether you test for "if x" or "if x != 0".


> Conclusion: the boolean value of an object is to be used with care in
> order to tests if an optional parameter is given or not (when default
> value is None).

Or, to put it another way: if you want to test for an object being None, 
test for the object being None.


-- 
Steven

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

#5106

> I believe you are grossly oversimplifying whatever code you had. Using
> the definition of f from above:
>
>>>>  theta = math.pi/4
>>>>  f(math.cos(2*theta))
> 6.12303176911e-17

Yes: its oversimplifued. The angle come from a normal vector of a curve 
and so on.... In particular, I was using Sage; the computations are 
exact: pi is pi and cos(pi) is zero.

>>  Conclusion: the boolean value of an object is to be used with care in
>>  order to tests if an optional parameter is given or not (when default
>>  value is None).
>
> Or, to put it another way: if you want to test for an object being None,
> test for the object being None.

It was my conclusion too ;)

Laurent

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

#5107

> I believe you are grossly oversimplifying whatever code you had. Using
> the definition of f from above:
>
>>>>  theta = math.pi/4
>>>>  f(math.cos(2*theta))
> 6.12303176911e-17

Yes: its oversimplifued. The angle come from a normal vector of a curve 
and so on.... In particular, I was using Sage; the computations are 
exact: pi is pi and cos(pi) is zero.

>>  Conclusion: the boolean value of an object is to be used with care in
>>  order to tests if an optional parameter is given or not (when default
>>  value is None).
>
> Or, to put it another way: if you want to test for an object being None,
> test for the object being None.

It was my conclusion too ;)

Laurent

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

#5114

On Wed, 11 May 2011 10:14:38 +0100, Hans Georg Schaathun wrote:

> In this case, the interpretation of an arbitrary object as a boolean is
> peculiar for python.  

Incorrect. It is widespread among many languages. Programmers have been 
writing conditional tests using arbitrary values since 1958 when Lisp 
introduced the concept.

C, Forth and Visual Basic treat any non-zero number as true, and zero as 
false; that's not quite arbitrary objects, but it's arbitrary integer 
values. Similarly, Objective C has two different boolean types, "BOOL" 
which is a C char where 0 is false and everything else is true, and 
"bool" which is more like the Java boolean type.

Perl treats the empty string, "0", 0 and undefined variables as false, 
and everything else as true.

Ruby treats null and false as false, and everything else as true.

JavaScript treats "", null, undefined, NaN, 0 and false as false values, 
and everything else as true.

PHP treats FALSE, 0, "", "0", empty arrays, objects with no member 
variables, NULL, unset variables, and SimpleXML objects created from 
empty tags as false, everything else as true.

Clojure treats nil and false as false, everything else as true.

SQL's boolean type has three or four values: true, false, null and 
unknown, where implementations are free to treat null and unknown as 
either the same or different values. (So a 3 or 4 value logic, not 
actually Boolean at all.)

So Python is hardly unique, nor is this some new-fangled innovation.



> An empty list is a real, existing object, and the
> supposition that [] be false is counter-intuitive.

Not to me, nor to anyone who has an intuition about "something" versus 
"nothing". I believe this distinction is fundamental to the universe, and 
that nearly every person understands this intuitively. The distinction 
between something and nothing is so strong that it took centuries of 
argument for the finest minds in Europe[1] to finally decide that, yes, 
zero is a number -- and they only did it because the Arabs and Indians 
had proven how useful it was, and Roman numerals really do suck for doing 
calculations.



> It can be learnt,
> and the shorthand may be powerful when it is, but it will confuse many
> readers.

In my experience, it does not confuse newbies or beginners. The only 
people it confuses are those who are over-educated into thinking that the 
One Correct Way of doing truth testing is with a dedicated boolean type, 
and anything else is heresy.


[1] At least is you asked them.


-- 
Steven

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

#5117

On 11 May 2011 13:36:02 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
: > In this case, the interpretation of an arbitrary object as a boolean is
: > peculiar for python.  
: 
:  Incorrect. It is widespread among many languages. Programmers have been 
:  writing conditional tests using arbitrary values since 1958 when Lisp 
:  introduced the concept.

The fact that you need to list language by language which objects
evaluate as false or equivalent to false illustrates that this has
to be learnt language by language.  Allowing arbitrary objects is
one thing, the particular interpretation is peculiar.

The fact that if and while accepts any object for the condition may
be chapter 1 stuff, but the memorisation of exactly how the
interpretation does not come early (unless you learn it by rote of
course).

:  C, Forth and Visual Basic treat any non-zero number as true, and zero as 
:  false; that's not quite arbitrary objects, but it's arbitrary integer 
:  values. Similarly, Objective C has two different boolean types, "BOOL" 
:  which is a C char where 0 is false and everything else is true, and 
:  "bool" which is more like the Java boolean type.

Mentioning C, with no Boolean type at all, in this context is a bit
absurd.  Understanding boolean evaluation in C is very little help
when you want to understand it in python.

: > An empty list is a real, existing object, and the
: > supposition that [] be false is counter-intuitive.
: 
:  Not to me, nor to anyone who has an intuition about "something" versus 
:  "nothing". I believe this distinction is fundamental to the universe, and 
:  that nearly every person understands this intuitively. The distinction 
:  between something and nothing is so strong that it took centuries of 
:  argument for the finest minds in Europe[1] to finally decide that, yes, 
:  zero is a number -- and they only did it because the Arabs and Indians 
:  had proven how useful it was, and Roman numerals really do suck for doing 
:  calculations.

Exactly.  By now we have gotten past that old-fashioned idea that 0
is not a number.  Computer scientists even tend to count 0 as a
natural number.  When 0 is a number as real and existent as any other,
one would think that the empty list is also as real and existent as
any other list.

:  In my experience, it does not confuse newbies or beginners. The only 
:  people it confuses are those who are over-educated into thinking that the 
:  One Correct Way of doing truth testing is with a dedicated boolean type, 
:  and anything else is heresy.

What kind of beginners are you talking about?  Beginners to python
or beginners to programming.

The audience I am concerned about is the ones who are over-educated 
into using and having used a score of different meanings of the same
symbols.  They will be used to their intuition being wrong when they
move into a new context.  Being explicit will help them.


-- 
:-- Hans Georg

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

#5122

On Thu, May 12, 2011 at 12:00 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> The fact that you need to list language by language which objects
> evaluate as false or equivalent to false illustrates that this has
> to be learnt language by language.  Allowing arbitrary objects is
> one thing, the particular interpretation is peculiar.

Languages have to be learned language by language. Yes, you want to be
similar to others if you can (and in 'most every language where it's
legal syntax, "1+2" will mean "3"), but whenever I'm working in a
language with which I'm not _really_ fluent, I like to keep an
operator table handy (precedence, plus oddments like what the
exponentiation operator is, or whether & is bitwise or boolean). They
do differ, and if I'm writing in PHP or Python or Pike or C++ or Java
or whatever else it be, I have to use the operators the way the
interpreter/compiler will understand them, not in some other way that
I "deem better".

> Mentioning C, with no Boolean type at all, in this context is a bit
> absurd.  Understanding boolean evaluation in C is very little help
> when you want to understand it in python.

Actually, it's not.

# Python code:
if x:
 statements

/* C code: */
if (x) {
 statements;
}

What's the difference? Both of them let you test the truth of some
arbitrary object or expression, and neither of those statements
implies a Boolean type. In C++, this is exploited extensively with,
for instance, the stream I/O objects evaluating as false when in an
error or EOF state:

while (infile) infile >> *ptr++; // Compact and convenient way to read
into an array

Actually that one can be combined down even further, but for clarity I
leave it like that.

Chris Angelico

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

#5126

Hans Georg Schaathun wrote:
> On 11 May 2011 13:36:02 GMT, Steven D'Aprano
>   <steve+comp.lang.python@pearwood.info> wrote:
> : > In this case, the interpretation of an arbitrary object as a boolean is
> : > peculiar for python.  
> : 
> :  Incorrect. It is widespread among many languages. Programmers have been 
> :  writing conditional tests using arbitrary values since 1958 when Lisp 
> :  introduced the concept.
> 
> The fact that you need to list language by language which objects
> evaluate as false or equivalent to false illustrates that this has
> to be learnt language by language.  Allowing arbitrary objects is
> one thing, the particular interpretation is peculiar.


Like so many other things Python got right, I think it got this right as 
well.  "something" vs "nothing" is simple, useful, and easy to remember.


> By now we have gotten past that old-fashioned idea that 0
> is not a number.  Computer scientists even tend to count 0 as a
> natural number.  When 0 is a number as real and existent as any other,
> one would think that the empty list is also as real and existent as
> any other list.

Python is not concerned with whether it exists -- that's a name binding; 
  Python is concerned with whether anything is there.  0 apples is 
nothing and a an empty list is nothing as well.

~Ethan~

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

#5136

>The audience I am concerned about is the ones who are over-educated 
>into using and having used a score of different meanings of the same
>symbols.  They will be used to their intuition being wrong when they
>move into a new context.  Being explicit will help them.

I find this argument to be flawed. Should I stop using built-in generators instead of range/xrange for looping through lists? Certainly for loops with loop counting are understood more widely than generators. Should I stop using any advanced feature Python because it is difficult to understand without knowing Python?

I do not code for absolute beginner in Python to read my code. That way lies madness! I code with the assumption that someone with intermediate knowledge can read my code (unless I am forced into optimizing and then I rely on comments to explain). Actually, that is how I attempt to code in any language.

I may not have made the point well, but I cannot see any advantage for trying to program for the lowest common denominator.


Ramit



Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423

This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

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

#5146

On Wed, 11 May 2011 13:50:54 -0400, Prasad, Ramit
  <ramit.prasad@jpmchase.com> wrote:
:  I find this argument to be flawed. Should I stop using built-in 
: generators instead of range/xrange for looping through lists?
: Certainly for loops with loop counting are understood more widely
: than generators. Should I stop using any advanced feature Python
: because it is difficult to understand without knowing Python?

No; I'd suggest the most legible and intuitive construct that /does/ the
job.  Never something which requires one extra (illegible) page to do
the job, or something which does not do the job at all.

:  I may not have made the point well, but I cannot see any advantage 
: for trying to program for the lowest common denominator.

Common to what?  I'd try the lowest common denominator of
legibility and effictiveness.

It is just KISS.

-- 
:-- Hans Georg

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

#5150

>Common to what?  I'd try the lowest common denominator of
>legibility and effictiveness.
>It is just KISS.

Fair enough. I am a sheep, so I do what other (more knowledgeable) people do. It is a fair assumption (for my specific code writing environments) that everyone who is going to read my code understands "if x:" notation or is expected to learn enough Python to understand it.




Ramit



Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423


-----Original Message-----
From: python-list-bounces+ramit.prasad=jpmchase.com@python.org [mailto:python-list-bounces+ramit.prasad=jpmchase.com@python.org] On Behalf Of Hans Georg Schaathun
Sent: Wednesday, May 11, 2011 1:16 PM
To: python-list@python.org
Subject: Re: checking if a list is empty

On Wed, 11 May 2011 13:50:54 -0400, Prasad, Ramit
  <ramit.prasad@jpmchase.com> wrote:
:  I find this argument to be flawed. Should I stop using built-in 
: generators instead of range/xrange for looping through lists?
: Certainly for loops with loop counting are understood more widely
: than generators. Should I stop using any advanced feature Python
: because it is difficult to understand without knowing Python?

No; I'd suggest the most legible and intuitive construct that /does/ the
job.  Never something which requires one extra (illegible) page to do
the job, or something which does not do the job at all.

:  I may not have made the point well, but I cannot see any advantage 
: for trying to program for the lowest common denominator.

-- 
:-- Hans Georg
-- 
http://mail.python.org/mailman/listinfo/python-list
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

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

#5154

On Wed, 11 May 2011 14:59:34 -0400, Prasad, Ramit
  <ramit.prasad@jpmchase.com> wrote:
:  Fair enough. I am a sheep, so I do what other (more knowledgeable)
: people do. It is a fair assumption (for my specific code writing 
: environments) that everyone who is going to read my code understands 
: "if x:" notation or is expected to learn enough Python to understand it.

That's fair enough.  You know your code, so it is probably true.
It would not be true for the code I am writing.

-- 
:-- Hans Georg

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

#5152

Hans Georg Schaathun wrote:
> On Wed, 11 May 2011 13:50:54 -0400, Prasad, Ramit
>   <ramit.prasad@jpmchase.com> wrote:
> :  I find this argument to be flawed. Should I stop using built-in 
> : generators instead of range/xrange for looping through lists?
> : Certainly for loops with loop counting are understood more widely
> : than generators. Should I stop using any advanced feature Python
> : because it is difficult to understand without knowing Python?
> 
> No; I'd suggest the most legible and intuitive construct that /does/ the
> job.  Never something which requires one extra (illegible) page to do
> the job, or something which does not do the job at all.
> 
> :  I may not have made the point well, but I cannot see any advantage 
> : for trying to program for the lowest common denominator.
> 
> Common to what?  I'd try the lowest common denominator of
> legibility and effictiveness.
> 
> It is just KISS.

'if li' *is* KISS.

~Ethan~

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

#5155

On Wed, 11 May 2011 12:17:33 -0700, Ethan Furman
  <ethan@stoneleaf.us> wrote:
:  'if li' *is* KISS.

It /might/ be in some contexts, but a priori it is not, as it
superimposes a truth value on a data type which is otherwise
a pretty accurate model of real objects (outside python).

One principle of object oriented programming is to bestow the
objects with properties reflecting known properties from the
domain being modelled.  Lists do not have truth values in the
application domain, and therefore truth values in the
implementation domain is complicated.

-- 
:-- Hans Georg

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

#5159

On 11/05/2011 20:13, Hans Georg Schaathun wrote:
> On Wed, 11 May 2011 12:17:33 -0700, Ethan Furman
>    <ethan@stoneleaf.us>  wrote:
> :  'if li' *is* KISS.
>
> It /might/ be in some contexts, but a priori it is not, as it
> superimposes a truth value on a data type which is otherwise
> a pretty accurate model of real objects (outside python).
>
> One principle of object oriented programming is to bestow the
> objects with properties reflecting known properties from the
> domain being modelled.  Lists do not have truth values in the
> application domain, and therefore truth values in the
> implementation domain is complicated.
>
Exactly. Its just a convention.  If it exists, its true, if if doesn't 
its false.

In the "real world"  lists of zero items do not exist.
You don't go shopping with a shopping list of zero items.
You don't take a journey going nowhere.
You wouldn't have a party and invite nobody.
What kind of building is one with zero floors?
Would you have an Aircraft Carrier with no aircraft?

Oh Wait - the UK has one of those coming into service soon.

Regards

Ian

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web