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

#5949

On Sun, May 22, 2011 at 11:02 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 21 May 2011 15:46:01 +0100, John J Lee wrote:
>
> Er, yes? But in any realistic example (your trivial function xyzzyx below
> is not very realistic) you'll almost certainly get additional hints in
> the function body.

True, but sometimes those hints will be buried in nested calls, making
it less obvious. It might well take some digging to figure out just
what sort of object it's meant to be accepting. That's why I prefer to
have some sort of type declarations; or alternatively, a good
docstring / autodoc comment that says what the function wants and
gives.

Chris Angelico

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

#4864

On Fri, May 6, 2011 at 1:05 PM, Adam Tauno Williams
<awilliam@whitemice.org> wrote:
<snip>
> - and ignore the Pythonistas [they're nuts;  that x.count() doesn't work
> is amazingly stupid].

Eh? It works fine. [5, 2, 2, 1, 2].count(2) == 3. If you mean you want
len(x) to be spelled x.count(), that's equally stupid; `count` would
be a lousy name (people would confuse it with what the current
.count() does). `length` or `size` would make much more sense.

Cheers,
Chris

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

#4879

On Sat, May 7, 2011 at 6:05 AM, Adam Tauno Williams
<awilliam@whitemice.org> wrote:
> 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!

As a C and C++ programmer, I probably shouldn't offer an opinion, but
it is quite normal in C++ to compare objects for truth/falseness - for
instance, stream objects return false on error/eof, so you can
efficiently code a loop with "while (infile) {...}". Not to mention
that the nullness of a C string (a PSZ) is quite happily and safely
tested by seeing if the pointer is true (non-null) or false (null).

That said, though, readability is a relative thing. A construct is
transparently obvious if it does something in the exact same way that
it's always been done, no matter how obscure it was the first time.
Why is it, for instance, that putting two short strokes perpendicular
to one another indicates addition? Yet if you see the construct "x +
y", you know exactly what it means - it's readable, it's not cryptic
at all. People assume and expect that this compact syntax will be
available, and object heavily to such notation as "add(x,y)" which
says exactly what it does.

if not li:

is perfectly readable; you just need a comprehension of what truth
means for a list.

Chris Angelico

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

#4890

On Fri, 06 May 2011 14:49:24 -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.
> 
> ... if not li  says nothing about what li is supposed to 'be' 

Yes, and? Neither does:

isempty(li)  # li could be anything that polymorphic isempty can deal with
li.isempty()  # li could be anything with a "isempty" method
len(li) == 0  # li could be anything with a length (list, dict, set, ...)


That's duck-typing for you, and it is generally a strength rather than a 
weakness. For those times when it is a weakness, that's where we have 
naming conventions, type-testing, and (in some languages) static types.


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


> or worse is some kind of boolean.

Only if you're still thinking in some language that isn't Python.

Boolean tests in Python are polymorphic. bool() exists mainly to provide 
a canonical representation of true and false values, not because you are 
limited to using booleans in truth-testing. Far from it: it is often very 
useful to do something like this:

settings = local_settings or global_settings or builtin_settings

where the first non-empty *_settings wins.


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

For the same reason that we don't have an int method that makes zero 
testing more explicit:

n = 0
n.iszero()  # returns True


Because sometimes you can have too much explicitness.


-- 
Steven

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

#4936

Steven D'Aprano wrote:
>> ... if not li  says nothing about what li is supposed to 'be'
> Yes, and? Neither does:
>
> isempty(li)  # li could be anything that polymorphic isempty can deal with
> li.isempty()  # li could be anything with a "isempty" method
> len(li) == 0  # li could be anything with a length (list, dict, set, ...)

      Sure.

> That's duck-typing for you, and it is generally a strength rather than a
> weakness. For those times when it is a weakness, that's where we have
> naming conventions, type-testing, and (in some languages) static types.

      I can fix almost anything with duck-type...    :)

>> >  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; 
which is irony extreme since 'not' is typically considered a logical 
operator.   What does it mean to say  not <list name>?  Well, apparently 
it means the list is 'empty'... but why should it mean that? 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... Why should 'not' mean 'empty'?

>> >  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...   Python is the new 
kid on the block, and most of us are coming at this from multiple 
filters in comp sci experience.  Its just the truth.

>> >       Why not have a list method that makes this more explicit:
> For the same reason that we don't have an int method that makes zero
> testing more explicit:

> Because sometimes you can have too much explicitness.

     True.


kind regards,

m harris

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

#4939

harrismh777 wrote:
> Steven D'Aprano wrote:
 >>>  attribution lost 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; 
> which is irony extreme since 'not' is typically considered a logical 
> operator.   What does it mean to say  not <list name>?  Well, apparently 
> it means the list is 'empty'... but why should it mean that? 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... Why should 'not' mean 'empty'?

Because this is Python, and in Python that's what it means.

> 
>>> >  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...   Python is the new kid 
> on the block, and most of us are coming at this from multiple filters in 
> comp sci experience.  Its just the truth.

And your point would be?

If you're going to use a language, and use it well, you have to learn 
how that language works.

~Ethan~

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

#5103

On Sat, 07 May 2011 21:57:13 -0700, Ethan Furman
  <ethan@stoneleaf.us> wrote:
:  If you're going to use a language, and use it well, you have to learn 
:  how that language works.

And if the world evolves around the compiler and you, that advice
suffices.

However, programming is often as much about developing ideas in a large
and complex community, where perfect universal mastery of one language
is not an option, because half the community do not normally use that
language or aren't really programmers at all.  The less you assume about
the skill of the reader, the better it is.

-- 
:-- Hans Georg

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

#5116

On Wed, 11 May 2011 11:47:42 +0100, Hans Georg Schaathun wrote:

> On Sat, 07 May 2011 21:57:13 -0700, Ethan Furman
>   <ethan@stoneleaf.us> wrote:
> :  If you're going to use a language, and use it well, you have to learn
> :  how that language works.
> 
> And if the world evolves around the compiler and you, that advice
> suffices.
> 
> However, programming is often as much about developing ideas in a large
> and complex community, where perfect universal mastery of one language
> is not an option, because half the community do not normally use that
> language or aren't really programmers at all.  The less you assume about
> the skill of the reader, the better it is.

Do you think that we should avoid chained comparisons, class methods, 
closures, co-routines, decorators, default values to functions, 
delegation, doc tests, exceptions, factory functions, generator 
expressions, inheritance, iterators, list comprehensions, operator 
overloading, properties, regular expressions, tuple unpacking, or unit 
tests, to say nothing of *advanced* techniques like descriptors or 
metaclasses, just in case the person reading your code is a clueless n00b?

We routinely and uncontroversially use all of these techniques (well, 
sometimes metaclasses get a few raised eyebrows). Truth testing is MUCH 
simpler than any of those.

It is extremely patronizing to say that we should avoid truth-testing 
arbitrary objects because it is too complicated for other people. It's 
not hard, and they can learn.



-- 
Steven

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

#5119

On 11 May 2011 13:45:52 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  Do you think that we should avoid chained comparisons, class methods, 
:  closures, co-routines, decorators, default values to functions, 
:  delegation, doc tests, exceptions, factory functions, generator 
:  expressions, inheritance, iterators, list comprehensions, operator 
:  overloading, properties, regular expressions, tuple unpacking, or unit 
:  tests, to say nothing of *advanced* techniques like descriptors or 
:  metaclasses, just in case the person reading your code is a clueless n00b?

Not at all.  On both accounts.
1. My concern was not about clueless newbies.  They need to
  learn.  My concern is about experienced scientists and engineers 
  who are simply new to python.  They will be dealing with a dozen
  different languages (programming and otherwise), with a need to
  read more languages than they can possibly learn to master.

2. You should avoid constructs which can /reasonably/ be avoided to 
  /increase/ legibility.  Writing if x for if len(x) > 0 when you
  know that x is of some sort of collection type with len defined
  does nothing to help legibility.  Many of the socalled advanced
  constructs you mention are used to increase legibility one way or
  another.  Others will simply allow functionality which would otherwise
  be impossible.

  I don't object to using if x in a case where x may or may not have
  len() defined.

:  We routinely and uncontroversially use all of these techniques (well, 
:  sometimes metaclasses get a few raised eyebrows). Truth testing is MUCH 
:  simpler than any of those.

Simpler, yes, but it surely depends on more detailed knowledge.  One has
to remember how the boolean conversion works, for each possible data type.
This requires looking up the rules for each data type.

E.g. Anyone who has used list/set comprehension in Z, haskell, set theory,
or whereever will understand python list comprehension immediately.

:  It is extremely patronizing to say that we should avoid truth-testing 
:  arbitrary objects because it is too complicated for other people. It's 
:  not hard, and they can learn.

Again you miss the point.  It is not /too/ complicated.
It is /unnecessarily/ complicated.  You don't noticeably
gain anything by using if x instead of if len(x) > 0, if
you know that the latter is defined.  

If everyone who ever needs to see your program is a python
programmer, then your approach works as well as mine.  

-- 
:-- Hans Georg

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

#5130

On Wed, 11 May 2011 15:34:28 +0100, Hans Georg Schaathun wrote:

> On 11 May 2011 13:45:52 GMT, Steven D'Aprano
>   <steve+comp.lang.python@pearwood.info> wrote:
> :  Do you think that we should avoid chained comparisons, class methods,
> :  closures, co-routines, decorators, default values to functions, : 
> delegation, doc tests, exceptions, factory functions, generator : 
> expressions, inheritance, iterators, list comprehensions, operator : 
> overloading, properties, regular expressions, tuple unpacking, or unit :
>  tests, to say nothing of *advanced* techniques like descriptors or : 
> metaclasses, just in case the person reading your code is a clueless
> n00b?
> 
> Not at all.  On both accounts.
> 1. My concern was not about clueless newbies.  They need to
>   learn.  My concern is about experienced scientists and engineers who
>   are simply new to python.

Which makes them clueless newbies *about Python*. I don't care how 
experienced they are in astrophysics or biology or calculating the 
average airspeed of an unladen swallow.


>   They will be dealing with a dozen different
>   languages (programming and otherwise), with a need to read more
>   languages than they can possibly learn to master.

Yeah, life is hard and then you die, and scientists don't even get paid 
that much. So what? Do physicists write their scientific papers about 
string theory with the thought "What if some Python programmer who knows 
nothing about string theory is reading this? I better dumb it down."

Of course not. A ridiculous idea. They use their tools the way they are 
designed to be used, and outsiders have to learn the language and the 
jargon to make sense of it. This is not a problem that needs solving.

It's one thing to simplify code that you are explicitly using as a 
teaching aid. That's a good thing, I approve of that. But it's a 
completely different thing to dumb down production code because you think 
some non-programmer might have to read it.



> 2. You should avoid constructs which can /reasonably/ be avoided to
>   /increase/ legibility.  Writing if x for if len(x) > 0 when you know
>   that x is of some sort of collection type with len defined does
>   nothing to help legibility.

Of course it does. 

It means you don't have to care about implementation details of what 
emptiness means for a list. It means you don't force the reader to read, 
parse and understand three extraneous terms. It means you don't force the 
reader to wonder why you bothered to use a long-winded test when a short 
test would do, or be concerned that maybe > 0 is a typo and you actually 
meant > 10.


[...]
> Simpler, yes, but it surely depends on more detailed knowledge.  One has
> to remember how the boolean conversion works, for each possible data
> type. This requires looking up the rules for each data type.

No. You have that exactly backwards. The point of "if x" is that you 
DON'T have to care about how the boolean conversion works, because the 
object itself encapsulates that behaviour. This is basic object-oriented 
principles.

When you call len(x) you don't care about the details of how to calculate 
the length of x. The object itself knows so that you don't have to. The 
same applies to truth testing.

I have a data type that is an array of lists. When you call "if len(x) > 
0" on it, it will blow up in your face, because len(x) returns a list of 
lengths like [12, 0, 2, 5]. But if you say "if x", it will do the right 
thing. You don't need to care how to truth-test my data type, because it 
does it for you. By ignoring my type's interface, and insisting on doing 
the truth-test by hand, you shoot yourself in the foot.



> E.g. Anyone who has used list/set comprehension in Z, haskell, set
> theory, or whereever will understand python list comprehension
> immediately.

Yes. And anyone who hasn't, probably won't. But they will learn.



-- 
Steven

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

#5141

On 11 May 2011 16:26:40 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
: > 1. My concern was not about clueless newbies.  They need to
: >   learn.  My concern is about experienced scientists and engineers who
: >   are simply new to python.
: 
:  Which makes them clueless newbies *about Python*. I don't care how 
:  experienced they are in astrophysics or biology or calculating the 
:  average airspeed of an unladen swallow.

Someone who knows how to program is never clueless starting a new
language.  Newbie, may be, but he knows most of the constructions
and semantic principles to look for; most of it is learning the syntax.

:  Yeah, life is hard and then you die, and scientists don't even get paid 
:  that much. So what? Do physicists write their scientific papers about 
:  string theory with the thought "What if some Python programmer who knows 
:  nothing about string theory is reading this? I better dumb it down."

That depends on the purpose of that particular paper, but the real 
question is, who writes the software to test that string theory 
empirically?  Please tell.

-- 
:-- Hans Georg

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

#5156

> Someone who knows how to program is never clueless starting a new
>language.  Newbie, may be, but he knows most of the constructions
>and semantic principles to look for; most of it is learning the syntax.

I claim to be able to program (Java/Python), but would be absolutely lost programming in Lisp. It is more than just "learning the syntax", it includes a thought paradigm as well.

Just like I claim to be able to do math, but severely suck at RPN math. (Okay, that analogy is bad but it is all I can come up with at the moment.)

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:06 PM
To: python-list@python.org
Subject: Re: checking if a list is empty

On 11 May 2011 16:26:40 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
: > 1. My concern was not about clueless newbies.  They need to
: >   learn.  My concern is about experienced scientists and engineers who
: >   are simply new to python.
: 
:  Which makes them clueless newbies *about Python*. I don't care how 
:  experienced they are in astrophysics or biology or calculating the 
:  average airspeed of an unladen swallow.

:  Yeah, life is hard and then you die, and scientists don't even get paid 
:  that much. So what? Do physicists write their scientific papers about 
:  string theory with the thought "What if some Python programmer who knows 
:  nothing about string theory is reading this? I better dumb it down."

That depends on the purpose of that particular paper, but the real 
question is, who writes the software to test that string theory 
empirically?  Please tell.

-- 
:-- 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]

#5158

On Wed, 11 May 2011 14:44:37 -0400, Prasad, Ramit
  <ramit.prasad@jpmchase.com> wrote:
: > Someone who knows how to program is never clueless starting a new
: >language.  Newbie, may be, but he knows most of the constructions
: >and semantic principles to look for; most of it is learning the syntax.
: 
:  I claim to be able to program (Java/Python), but would be absolutely
: lost programming in Lisp. It is more than just "learning the syntax",
: it includes a thought paradigm as well.

OK.  I should written 'how to program imperatively' ... 'new imperative
language'.  Or substitute functional/logical/whatever for imperative.

You would not be completely clueless moving to
ada/fortran/C/pascal/simula.  There may be new concepts,
and some concepts which must be adapted to another level of
abstraction, but you do have a clue about the core concepts.

-- 
:-- Hans Georg

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

#5186 — Learning new languages (was: checking if a list is empty)

* 2011-05-11T20:26:48+01:00 * Hans Georg Schaathun wrote:

> On Wed, 11 May 2011 14:44:37 -0400, Prasad, Ramit
>   <ramit.prasad@jpmchase.com> wrote:
>> I claim to be able to program (Java/Python), but would be absolutely
>> lost programming in Lisp. It is more than just "learning the syntax",
>> it includes a thought paradigm as well.
>
> OK. I should written 'how to program imperatively' ... 'new imperative
> language'. Or substitute functional/logical/whatever for imperative.

Common Lisp is an imperative language. It is also functional and
object-oriented language. It does not force any paradigm but supports
many. Thus, it is called a multi-paradigm language. I understand that
Lisp can be scary, though. Lisp code looks weird and it seems that the
myth that it's a functional language can't be busted.

Anyway, I agree with this:

    * 2011-05-11T19:05:31+01:00 * Hans Georg Schaathun wrote:
    > Someone who knows how to program is never clueless starting a new
    > language. Newbie, may be, but he knows most of the constructions
    > and semantic principles to look for; most of it is learning the
    > syntax.

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

#5151

In article <4dcab8bf$0$29980$c3e8da3$5496439d@news.astraweb.com>
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>When you call len(x) you don't care about the details of how to calculate 
>the length of x. The object itself knows so that you don't have to. The 
>same applies to truth testing.
>
>I have a data type that is an array of lists. When you call "if len(x) > 
>0" on it, it will blow up in your face, because len(x) returns a list of 
>lengths like [12, 0, 2, 5]. But if you say "if x", it will do the right 
>thing. You don't need to care how to truth-test my data type, because it 
>does it for you. By ignoring my type's interface, and insisting on doing 
>the truth-test by hand, you shoot yourself in the foot.

What this really points out is that "if x" and "if len(x) > 0" are
*different tests*.  Consider xml.etree.ElementTree "Element" objects.
The documentation says, in part:

    In ElementTree 1.2 and earlier, the sequence behavior means
    that an element without any subelements tests as false (since
    it's an empty sequence), even if it contains text and
    attributions. ...

    Note: This behavior is likely to change somewhat in ElementTree
    1.3.  To write code that is compatible in both directions, use
    ... "len(element)" to test for non-empty elements.

In this case, when x is an Element, the result of bool(x) *could*
mean just "x has sub-elements", but it could also/instead mean "x
has sub-elements, text, or attributions".

The issue raised at the beginning of this thread was: which test
is "better" when x is a list, the test that invokes bool(x), or
the test that invokes len(x)?  There is no answer to that, any more
than there is to which ice cream flavor is "best". [%]  A more
interesting question to ask, in any given bit of code, is whether
bool(x) or len(x) is more appropriate for *all* the types x might
take at that point, rather than whether one or the other is better
for lists, where the result is defined as equivalent.

(The biggest problem with answering that tends to be deciding
what types x might take.)

[% Chocolate with raspberry, or mint, or similar.]
-- 
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] | [next] | [standalone]

#5165

On Wed, 11 May 2011 19:05:03 +0000, Chris Torek wrote:

> In article <4dcab8bf$0$29980$c3e8da3$5496439d@news.astraweb.com> Steven
> D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>>When you call len(x) you don't care about the details of how to
>>calculate the length of x. The object itself knows so that you don't
>>have to. The same applies to truth testing.
>>
>>I have a data type that is an array of lists. When you call "if len(x) >
>>0" on it, it will blow up in your face, because len(x) returns a list of
>>lengths like [12, 0, 2, 5]. But if you say "if x", it will do the right
>>thing. You don't need to care how to truth-test my data type, because it
>>does it for you. By ignoring my type's interface, and insisting on doing
>>the truth-test by hand, you shoot yourself in the foot.
> 
> What this really points out is that "if x" and "if len(x) > 0" are
> *different tests*.

*Potentially* different tests. Which is exactly the point. Given an 
arbitrary object, the developer doesn't know what test is appropriate. 
Should I write len(x) == 0 or list(x) == [] or x.next is None or 
something else? How can I tell which is appropriate without knowing 
everything about the internals of every object I ever see?

But if x is a non-broken object, then you don't have to. Just test on x 
itself, because it knows what to do to be considered a truth value.

Of course there may be objects where this doesn't work. There are no 
guarantees in Python. You can't even guarantee that printing an object 
won't blow up:

>>> class Broken:
...      def __str__(self):
...          return "... %s ..." % 1/2
...      __repr__ = __str__
...
>>> b = Broken()
>>> b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __str__
TypeError: unsupported operand type(s) for /: 'str' and 'int'


> Consider xml.etree.ElementTree "Element" objects.
> The documentation says, in part:
> 
>     In ElementTree 1.2 and earlier, the sequence behavior means that an
>     element without any subelements tests as false (since it's an empty
>     sequence), even if it contains text and attributions. ...
> 
>     Note: This behavior is likely to change somewhat in ElementTree 1.3.
>      To write code that is compatible in both directions, use ...
>     "len(element)" to test for non-empty elements.
> 
> In this case, when x is an Element, the result of bool(x) *could* mean
> just "x has sub-elements", but it could also/instead mean "x has
> sub-elements, text, or attributions".

Either behaviour is correct, but a semantic change to the class means 
that you have to do more work if you care about supporting both versions 
in the same code base. That is a neat example of where you might choose 
*not* to let an object decide for itself whether it is true or false, but 
instead impose your own definition on it.




-- 
Steven

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

#5206

On 11 May 2011 21:42:10 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  *Potentially* different tests. Which is exactly the point. Given an 
:  arbitrary object, the developer doesn't know what test is appropriate. 
:  Should I write len(x) == 0 or list(x) == [] or x.next is None or 
:  something else? How can I tell which is appropriate without knowing 
:  everything about the internals of every object I ever see?

Sure, but the question asked was how to check if a /list/ is empty.
You defend your answer assuming a different question.  You could
at least have the decency to change the subject header when you
go down that route.


-- 
:-- Hans Georg

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

#5133

On Wed, May 11, 2011 at 8:34 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
> E.g. Anyone who has used list/set comprehension in Z, haskell, set theory,
> or whereever will understand python list comprehension immediately.

They would understand the underlying concept.  But would somebody who
is not a Python programmer intuitively understand the difference
between this:

[x + 3 for x in xs if x % 2 == 1]

and this:

{x + 3 for x in xs if x % 2 == 1}

and this:

(x + 3 for x in xs if x % 2 == 1)

Somebody with rudimentary Python knowledge might even reason that
since the first two create a list and a set respectively, the third
must therefore create a tuple, which is wrong.

None of this should be taken as an argument against using generator expressions.

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

#5144

On Wed, 11 May 2011 10:31:59 -0600, Ian Kelly
  <ian.g.kelly@gmail.com> wrote:
:  (x + 3 for x in xs if x % 2 == 1)

Interesting.  Thanks.  That might come in handy some time.

-- 
:-- Hans Georg

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

#5120

On Wed, 11 May 2011 11:47:42 +0100
Hans Georg Schaathun <hg@schaathun.net> wrote:
> However, programming is often as much about developing ideas in a large
> and complex community, where perfect universal mastery of one language
> is not an option, because half the community do not normally use that
> language or aren't really programmers at all.  The less you assume about
> the skill of the reader, the better it is.

Non-programmers should be able to program?

Should non-doctors be able to doctor?  Should cars be built so that
anyone can intuitively fix them without a mechanic?  Should trucks be
built so that drivers don't have to learn how to split shift?  Why is
programming so different that we can't expect people to actually learn
their discipline?

This discussion is giving me some insight into some of the crap
programming I see these days.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

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

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

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

csiph-web