checking if a list is empty
Jabba Laci
If I want to check if a list is empty, which is the more pythonic way?
li = []
(1) if len(li) == 0:
...
or
(2) if not li:
...
Thanks,
Laszlo
Chris Rebert
> Hi,
>
> If I want to check if a list is empty, which is the more pythonic way?
Option (2), IMO.
> li = []
>
> (1) if len(li) == 0:
> ...
FYI, also equivalent:
if not len(li):
...
> or
> (2) if not li:
Cheers,
Chris
Richard Thomas
I prefer (1), it feels more explicit about what I'm testing. The fact
that empty sequences evaluate as false feels like a bit of a quirk to
me. Actually the fact that 0 evaluates as false feels like a bit of a
quirk to me, I more of a "use booleans in boolean contexts" kind of
programmer.
James Mills
> If I want to check if a list is empty, which is the more pythonic way?
[...]
> (2) if not li:
This is fine.
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
Terry Reedy
> On Fri, May 6, 2011 at 4:36 PM, Jabba Laci<jabba...@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
harrismh777
>>> (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
Adam Tauno Williams
> 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].
Chris Rebert
<awil...@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
scattered
is there any problem with
(3) if li == []:
?
Seems to work when I test it and seems to clearly test what you are
trying to test. The only problem might be if in some contexts == has
the semantics of checking for object identity.
Raymond Hettinger
> Hi,
>
> If I want to check if a list is empty, which is the more pythonic way?
>
> li = []
>
> (1) if len(li) == 0:
> ...
> or
> (2) if not li:
The Python core developers use the second form.
See http://www.python.org/dev/peps/pep-0008/
for the official recommendation.
Raymond
Philip Semanchuk
On May 6, 2011, at 5:57 PM, scattered wrote:
> On May 6, 2:36 am, Jabba Laci <jabba.l...@gmail.com> wrote:
>> Hi,
>>
>> If I want to check if a list is empty, which is the more pythonic way?
>>
>> li = []
>>
>> (1) if len(li) == 0:
>> ...
>> or
>> (2) if not li:
>> ...
>>
>> Thanks,
>>
>> Laszlo
>
> is there any problem with
>
> (3) if li == []:
>
> ?
What if it's not a list but a tuple or a numpy array? Often I just want to iterate through an element's items and I don't care if it's a list, set, etc. For instance, given this function definition --
def print_items(an_iterable):
if not an_iterable:
print "The iterable is empty"
else:
for item in an_iterable:
print item
I get the output I want with all of these calls:
print_items( list() )
print_items( tuple() )
print_items( set() )
print_items( numpy.array([]) )
Given this slightly different definition, only the first call gives me the output I expect:
def print_items(an_iterable):
if an_iterable == []:
print "The iterable is empty"
else:
for item in an_iterable:
print item
I find I use the the former style ("if not an_iterable") almost exclusively.
bye
Philip
Ian Kelly
> What if it's not a list but a tuple or a numpy array? Often I just want to iterate through an element's items and I don't care if it's a list, set, etc. For instance, given this function definition --
>
> def print_items(an_iterable):
> if not an_iterable:
> print "The iterable is empty"
> else:
> for item in an_iterable:
> print item
>
> I get the output I want with all of these calls:
> print_items( list() )
> print_items( tuple() )
> print_items( set() )
> print_items( numpy.array([]) )
But sadly it fails on iterators:
print_items(xrange(0))
print_items(-x for x in [])
print_items({}.iteritems())
Jon Clements
My stab:
from itertools import chain
def print_it(iterable):
it = iter(iterable)
try:
head = next(it)
except StopIteration:
print 'Empty'
return
for el in chain( (head,), it ):
print el
Not sure if I'm truly happy with that though.
Jon
Jon.
Chris Angelico
<awil...@whitemice.org> wrote:
> On Fri, 2011-05-06 at 14:49 -0500, harrismh777 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.
>
>
> 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
Steven D'Aprano
> 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
Steven D'Aprano
> is there any problem with
>
> (3) if li == []:
>
> ?
>
> Seems to work when I test it and seems to clearly test what you are
> trying to test. The only problem might be if in some contexts == has the
> semantics of checking for object identity.
Yes, if li == [] works too. But how do you know li is a list and not some
other sequence type?
The advantage of the "if x" test is that it is independent of the type of
x.
--
Steven
Steven D'Aprano
> 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
harrismh777
>> ... 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
Ethan Furman
> 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~
Steven D'Aprano
> 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
Jussi Piitulainen
> 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.
Terry Reedy
> 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
Michael Torrie
> 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.
harrismh777
>> 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
harrismh777
>> 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
Ian Kelly
> 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"
James Mills
> "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.
Terry Reedy
> 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
harrismh777
> "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
Steven D'Aprano
> 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
Ben Finney
> 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
harrismh777
> 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
harrismh777
> 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
Hans Georg Schaathun
<steve+comp....@pearwood.info> wrote:
: On Fri, 06 May 2011 14:57:21 -0700, scattered wrote:
:
: > is there any problem with
: >
: > (3) if li == []:
: >
: > ?
: >
: > Seems to work when I test it and seems to clearly test what you are
: > trying to test. The only problem might be if in some contexts == has the
: > semantics of checking for object identity.
:
: Yes, if li == [] works too. But how do you know li is a list and not some
: other sequence type?
It says so in the Subject header :-)
: The advantage of the "if x" test is that it is independent of the type of
: x.
Sure, but the question wasn't ...
The problem with 'if x' is that it requires a much more detailed
understanding of python. li == [] is as explicit as it gets, and
leaves no room for doubt. len(li) == 0 is almost as explicit and
much more flexible. Just x is as generic as it gets, but depends
on python's convolved rules for duck processing and if you aim at
legibility it is better avoided.
--
:-- Hans Georg
Hans Georg Schaathun
<steve+comp....@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
Laurent Claessens
> 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
Hans Georg Schaathun
<et...@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
Steven D'Aprano
> 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
Laurent Claessens
> 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
Laurent Claessens
> 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
Steven D'Aprano
> The problem with 'if x' is that it requires a much more detailed
> understanding of python.
"Much" more detailed? Hardly.
Understanding that Python accepts any and all objects in truth-testing
concepts, and the rules thereof, is Python 101 territory. It's beginner-
level knowledge. It is far less advanced than the knowledge that ** is
used for exponentiation. After all, many programmers have never needed to
raise a number to a power, and might not learn about it for years, but
every programmer writes if or while statements at some point.
Not knowing that you can write "if x" instead of "if x == []" is like not
knowing that you can write
elif condition
instead of
else:
if condition
If somebody were to argue that it is "better to write else if explicitly,
instead of the confusing elif", we'd all laugh at them.
Every time the question of conditional testing comes up here, it never
ceases to astonish me how many developers argue against learning the
idioms of the language, and prefer to re-use the idioms of other
languages in Python.
Python is an object-oriented language where objects get to decide for
themselves whether they should be treated as true or false. Writing:
if x == []:
instead of
if x:
merely[1] because you worry that it isn't explicit enough, or could
confuse other developers, or out of some nagging concern that maybe
Python will do the wrong thing[2] unless you hold its hand through the
process, is as silly as writing this:
count = 0
for item in x:
count += 1
instead of:
count = len(x)
(As silly, but not as verbose.)
I don't mean to insult anyone, but I've heard and read all the arguments
against Python's truth-testing, and they don't impress me in the
slightest. Most of them strike me as silly. The only argument that
carries any weight to me is one which I haven't seen anyone raise:
"if x:" turns something which arguably could have been a mistake ("oops,
I forgot to write the condition!") into valid code.
[1] It may be that there are good, solid reasons for writing explicit
len(x)==0 tests, although I'm hard-pressed to think of any. The closest I
come to is when you wish to emphasize "equal to some number that just
happens to be zero" rather than "it's a false/empty value". If so, you
get a free pass to write the test the long way. E.g. you might write
"x % 2 == 1" rather than just "x % 2" because you want to highlight that
the remainder equals one, rather than the remainder merely being a true
value.
[2] Of course, a custom object x might misbehave when you test it for
truth value. That would be a bug, just like it would be a bug if it
misbehaved when you call len(x) == 0. If you can't trust "if x" to work,
what makes you think you can trust "len(x) == 0" either?
--
Steven
Roy Smith
> li == [] is as explicit as it gets, and
> leaves no room for doubt.
I was about to write, "this fails if li is an instance of a subclass of
list", but then I tried it. I was astounded to discover that:
class MyList(list):
"I'm a subclass"
li = MyList()
print li == []
print [] == li
prints True, twice! I expected them both to be false. In fact, the
docs (http://tinyurl.com/3qga3lb) explicitly say:
> If both are numbers, they are converted to a common type. Otherwise,
> objects of different types always compare unequal
Since these are different types, i.e.
print type(li)
print type([])
print type(li) == type([])
prints
<class '__main__.MyList'>
<type 'list'>
False
I conclude that li == [] should have returned False. Either I'm not
understanding things correctly, or this is a bug.
Steven D'Aprano
> Hans Georg Schaathun <h...@schaathun.net> wrote:
>
>> li == [] is as explicit as it gets, and leaves no room for doubt.
>
> I was about to write, "this fails if li is an instance of a subclass of
> list", but then I tried it. I was astounded to discover that:
>
> class MyList(list):
> "I'm a subclass"
>
> li = MyList()
> print li == []
> print [] == li
>
> prints True, twice! I expected them both to be false. In fact, the
> docs (http://tinyurl.com/3qga3lb) explicitly say:
>
>> If both are numbers, they are converted to a common type. Otherwise,
>> objects of different types always compare unequal
That should be understood as only applying for built-in types, not
arbitrary types. For arbitrary types, you can decide what counts as equal
by writing an __eq__ method, and you can do *anything*:
def __eq__(self, other):
if today() == "Tuesday": return True
else: ...
To understand the behaviour you are seeing, it helps to understand that
while li is a MyList, it is also a list:
>>> isinstance(li, list)
True
It therefore inherits the same behaviour as list, unless you override or
overload it. Since you did neither, MyLists work just like lists, right
down to their __eq__ method.
It is normally considered The Right Thing To Do for subclasses to be
usable anywhere where a superclass was. That is, subclasses like MyList
should only *add* behaviour, never *subtract* it. Since:
>>> li = list()
>>> li == []
True
applies, you should be able to replace list() with any subclass of list
and it should still work. (This is known as the Liskov Substitution
Principle, if you wish to google on it.)
This being Python, it's more of a guideline than a law, and you can
violate it if you choose, but you probably shouldn't unless you have good
reason. But if you want, just add a method:
def __eq__(self, other):
# untested
if type(self) is not type(other): return False
return super(self, MyList).__eq__(other)
to get the behaviour you are after.
So, not a bug, but a subtle point that isn't explained terribly well in
the docs.
--
Steven
Steven D'Aprano
> 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
Steven D'Aprano
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
Hans Georg Schaathun
<steve+comp....@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
Hans Georg Schaathun
<steve+comp....@pearwood.info> wrote:
: Not knowing that you can write "if x" instead of "if x == []" is like not
:
: elif condition
:
: instead of
:
: else:
: if condition
My concern was with the reader and not the writer.
What could elif mean other than else: if?
if x could, for instance, mean "if x is defined".
--
:-- Hans Georg
Hans Georg Schaathun
<steve+comp....@pearwood.info> wrote:
: Do you think that we should avoid chained comparisons, class methods,
: 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
D'Arcy J.M. Cain
> 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 <da...@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.
D'Arcy J.M. Cain
If run by an elf? Who knows. You do, of course, if you have learned
the basics of the language you are using.
> if x could, for instance, mean "if x is defined".
It could also mean "if x was created on a Tuesday." A short
introduction to the language explains what it actually means.
When did we come to the idea that people should be able to program in a
language without actually learning it? The fact that Python comes so
close to that possibility is nothing short of revolutionary. I suppose
one day a reasoning android will be able to sit down at the terminal of
a star ship computer and ask simple questions while making random hand
movements across a screen but for now I am afraid that programmers
still have to learn programming.
Chris Angelico
> 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
Redcat
> Non-programmers should be able to program?
Wasn't that sort of the premise behind Visual Basic? I don't know if that
was the intention, but it sure was the result in a lot of cases.
Ethan Furman
> On 11 May 2011 13:36:02 GMT, Steven D'Aprano
> <steve+comp....@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~
Steven D'Aprano
> My concern was with the reader and not the writer.
>
> What could elif mean other than else: if?
It could mean "Oh, the author has made a stupid typo, I better fix it."
It could mean "What does the elif command do?"
The first time I read Python code, I had literally no idea what to make
of elif. It seemed so obvious to me that any language would let you write
"else if ..." (on a single line) that I just assumed that elif must be
some other construct, and I had no idea what it was. It never even
crossed my mind that it could be "else if" rammed together into one word.
I soon learned better though.
Once you start dumbing down your code for readers who don't know your
language, it's a race to the bottom. There's very little you can write
that *somebody* won't misunderstand.
> if x could, for instance, mean "if x is defined".
Yes it could, if you're programming in Perl. But we're not.
When I write a sentence in English, and I use the word "gift" to mean a
thing which is given, I don't worry that German or Swedish readers will
think I'm talking about poison. If I use "preservative", I mean something
which preserves, and if Italian and Spanish readers mistake it for a
condom, that's their problem, not mine. Writing code is no different.
When I'm coding in Python, I use Python rules and meanings, not some
other language.
Why should I code according to what some hypothetical Python dummy
*might* think the code will do, instead of what the code *actually* does?
--
Steven
Chris Angelico
<steve+comp....@pearwood.info> wrote:
> On Wed, 11 May 2011 15:05:45 +0100, Hans Georg Schaathun wrote:
>
>> My concern was with the reader and not the writer.
>>
>> What could elif mean other than else: if?
>
> of elif. It seemed so obvious to me that any language would let you write
> "else if ..." (on a single line) that I just assumed that elif must be
> some other construct, and I had no idea what it was. It never even
> crossed my mind that it could be "else if" rammed together into one word.
In a Bourne shell script, if ends with fi... case ends with esac... so
file would end with... hmm. Yeah, I think it's best to know the
language you're trying to comprehend, and/or actually look at context
instead of shoving a piece of code under someone's nose and saying "I
bet you can't figure out what THIS does!".
Chris Angelico
Steven D'Aprano
> On 11 May 2011 13:45:52 GMT, Steven D'Aprano
> <steve+comp....@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
Ian Kelly
> 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.
Prasad, Ramit
>don't impress me in the slightest. Most of them strike me as silly. The only argument that carries any weight to me is
>one which I haven't seen anyone raise:
>"if x:" turns something which arguably could have been a mistake ("oops, I forgot to write the condition!") into valid
>code.
On the other hand, as a fairly n00b Python (and n00b Perl) developer, I find the notation "if not x:" to be far more English readable than "if x==None or len(x)== 0 or x==0 or bool(x):" (or some derivative/combination of those).
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.
Prasad, Ramit
>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 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.
Hans Georg Schaathun
<da...@druid.net> wrote:
: Non-programmers should be able to program?
That was not really what I suggested; I was primarily talking
about reading programs and commenting on formulæ and algorithms.
: Should non-doctors be able to doctor?
If I were God, I might consider simplifying the anatomy to allow that,
yes.
: 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?
That's out of my area so I don't know. However, contrary to
software, I have never seen any use of rebuilding the car to
do something other than transport ...
And, besides, as mechanics do not design cars or even engines, they
are not analogous to programmers, but rather to computer technicians
(maintenance, deployment, installation, etc).
: Why is
: programming so different that we can't expect people to actually learn
: their discipline?
It is not different from other engineering disciplines, where you would
have to interact with experts from other disciplines, and understand
and comment on their designs. That's the way to build a /system/.
Say, you want to create the software to make weather forcasts.
At the end of the day, that's programming, but no way that's going
to be a task for programmers alone. You need mathematicians,
algorithm theorists, physicists, programmers, and multiple
specialisations within each discipline. If you can make your
programs clear enough to be used as a language of communications,
you will simplify the development, and allow the code to be
validated by those who knows how the computation has to be done
without specialising in talking to the computer.
: This discussion is giving me some insight into some of the crap
: programming I see these days.
I wonder if you would do a better job at programming the software
to crack equations from quantum physics than the physicist :-)
--
:-- Hans Georg
Hans Georg Schaathun
<steve+comp....@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
Hans Georg Schaathun
<ros...@gmail.com> wrote:
: In a Bourne shell script, if ends with fi... case ends with esac... so
: file would end with... hmm. Yeah, I think it's best to know the
: language you're trying to comprehend, and/or actually look at context
: instead of shoving a piece of code under someone's nose and saying "I
: bet you can't figure out what THIS does!".
Code is quite often published to document algorithms, methods and
formulæ for the purpose of scientific research. Since there is no
universal language which suits everything and everyone, this
is exactly what happens. One has to have the rudimentary knowledge
to read half a dozen different languages to be able to read the
code and extract the algorithms. If one tried to maintain the
necessary programming skills to exploit all of those languages to
their full potential, one would simply not be able to keep up with
the application discipline.
If all you do is to write software for computer illiterate users, YMWV.
--
:-- Hans Georg
Hans Georg Schaathun
<da...@druid.net> wrote:
: When did we come to the idea that people should be able to program in a
: language without actually learning it? The fact that Python comes so
: close to that possibility is nothing short of revolutionary.
Revolutionary indeed, so why don't we exploit the revolution
and write the programs to be as accessible as possible?
(Although, python is not the most revolutionary in this respect.)
--
:-- Hans Georg
Hans Georg Schaathun
<ian.g...@gmail.com> wrote:
: (x + 3 for x in xs if x % 2 == 1)
Interesting. Thanks. That might come in handy some time.
--
:-- Hans Georg
Hans Georg Schaathun
<ramit....@jpmchase.com> wrote:
: I find this argument to be flawed. Should I stop using built-in
: 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
Prasad, Ramit
>legibility and effictiveness.
>It is just KISS.
Ramit
Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423
From: python-list-bounces+ramit.prasad=jpmcha...@python.org [mailto:python-list-bounces+ramit.prasad=jpmcha...@python.org] On Behalf Of Hans Georg Schaathun
Sent: Wednesday, May 11, 2011 1:16 PM
To: pytho...@python.org
Subject: Re: checking if a list is empty
On Wed, 11 May 2011 13:50:54 -0400, Prasad, Ramit
<ramit....@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
Chris Torek
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
Ethan Furman
'if li' *is* KISS.
~Ethan~
Hans Georg Schaathun
<ramit....@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
Hans Georg Schaathun
<et...@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
Prasad, Ramit
>language. Newbie, may be, but he knows most of the constructions
>and semantic principles to look for; most of it is learning the syntax.
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=jpmcha...@python.org [mailto:python-list-bounces+ramit.prasad=jpmcha...@python.org] On Behalf Of Hans Georg Schaathun
Sent: Wednesday, May 11, 2011 1:06 PM
To: pytho...@python.org
Subject: Re: checking if a list is empty
<steve+comp....@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.
: 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
Hans Georg Schaathun
<ramit....@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
Ian
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
harrismh777
> Code is quite often published to document algorithms, methods and
> formulæ for the purpose of scientific research. Since there is no
> universal language which suits everything and everyone, this
> is exactly what happens. One has to have the rudimentary knowledge
> to read half a dozen different languages to be able to read the
> code and extract the algorithms.
+1 QOTW
harrismh777
> Non-programmers should be able to program?
>
> anyone can intuitively fix them without a mechanic?
Non-programmers should not be expected to program in 'C' nor in lisp...
... but non-programmers were able to program in BASIC jes fine...
I contend that non-programmers are able to learn rudimentary python and
work with it to solve real problems 'without' formal training in
'programming'.
Python is the New BASIC for 'people'. At least, it has the potential to
be that... people should be able to talk to their computers (whatever
we mean by that) and have the computer respond with real-world
solutions. We need to move away from 'canned apps' to a new day where
the masses can sit down to their computer and solve new problems with it
through intuitive language skills. Why not?
Steven D'Aprano
> In article <4dcab8bf$0$29980$c3e8da3$5496...@news.astraweb.com> Steven
> D'Aprano <steve+comp....@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
Steven D'Aprano
> 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
Yes they do. Empty lists are nothing, ergo false, and non-empty lists are
something, ergo true.
--
Steven
Steven Howe
> >>> if a:
> ... print 'Yes'
> ...
> >>> a=[1]
> >>> if a:
> ... print 'Yes'
> ...
> Yes
Cool; I'd never of thought to try that method to determine if a list was
empty. I usually test it's length.
This looks faster.
harrismh777
>> modelled. Lists do not have truth values in the application domain
> Yes they do. Empty lists are nothing, ergo false, and non-empty lists are
> something, ergo true.
>
No they don't. Empty lists are empty lists... which just happen to
become False when type cast bool(list[])--> False.
lists cannot have a truth... binary False or True... however, when cast
with bool(list) they can be used in a test (even with 'not') to make
some decision.
Lists by themselves, empty or not, cannot have a 'truth' in an of
themselves.
kind regards,
m harris
Gregory Ewing
> 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.
0 does have some special properties, though, such as
being the additive identity and not having a multiplicative
inverse. Adding falseness as another special property isn't
too much of a stretch and turns out to be useful.
Likewise, it's useful to treat empty containers as having
a similar special property, since they're often a base or
terminating case in algorithms.
It's especially useful in a dynamic language where any
additional operations such as finding the length or
comparing with zero has a run-time cost.
Yes, you have to learn it, but it's a small thing to
learn with a considerable payoff.
--
Greg
harrismh777
> Lists by themselves, empty or not, cannot have a 'truth' in an of
> themselves.
... forgot.,
Based on Ian's comment a couple of days ago...
if alist:
... is actually :
if bool(alist):
I think this is more than just semantics or silly argumentation. Its
important to understand where the boolean truth is coming from... my
understanding 'now' is that the list[] has no such boolean attribute,
but is cast for the 'if' construct....
so... if alist: is --> if bool(alist):
and... if not alist: is also --> if not bool(alist):
The 'alist[]' has no boolean attribute, right??
kind regards,
m harris
Steven D'Aprano
> Steven D'Aprano wrote:
>>> modelled. Lists do not have truth values in the application domain
>> Yes they do. Empty lists are nothing, ergo false, and non-empty lists
>> are something, ergo true.
>>
>>
> No they don't. Empty lists are empty lists... which just happen to
> become False when type cast bool(list[])--> False.
>
> lists cannot have a truth... binary False or True... however, when cast
> with bool(list) they can be used in a test (even with 'not') to make
> some decision.
Have you been not paying any attention at all?
>>> alist = []
>>> if alist: pass
... else: print "alist is a false value"
...
alist is a false value
>>>
>>> if type(alist) is bool: pass
... else: print "but not a bool"
...
but not a bool
> Lists by themselves, empty or not, cannot have a 'truth' in an of
> themselves.
Despite your confident tone, they really do. Just like EVERY OTHER OBJECT
IN PYTHON. And Perl, and Ruby, and Javascript, and PHP, and many other
languages. You might not like that fact, but it is a fact.
--
Steven
alex23
> Revolutionary indeed, so why don't we exploit the revolution
> and write the programs to be as accessible as possible?
Where do you draw the line, though?
No decorators, as they're not intuitively obvious? No custom
descriptors, as that requires a deeper knowledge of Python internals
that utter ignorance allows?
Both of those aspects alone seem far more complex and advanced than
treating empty collections as False.
alex23
> We need to move away from 'canned apps' to a new day where
> the masses can sit down to their computer and solve new problems with it
> through intuitive language skills. Why not?
Because the vast majority of them don't seem to want to be bothered?
Teemu Likonen
> On Wed, 11 May 2011 14:44:37 -0400, Prasad, Ramit
> <ramit....@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:
Chris Torek
>
>"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]
Chris Angelico
> In the "real world" lists of zero items do not exist.
> You don't go shopping with a shopping list of zero items.
Actually, yes you do. You maintain your shopping list between trips;
whenever you need something, you put it on the list immediately. Then
when you go shopping, you just take the list with you (if you're
lucky, you don't need to move or copy it at all, you just get another
reference to it). Once you're done, you empty the list - you now have
a shopping list with zero items (until you get home and realize you
forgot something).
Chris Angelico
harrismh777
>> through intuitive language skills. Why not?
> Because the vast majority of them don't seem to want to be bothered?
>
That could very well be... but I have a hope for them. I honestly think
its not because they don't want to be bothered, rather they just think
its too far past them... and not do-able.
This is where I think it would be helpful at the undergraduate level to
insist that *all* students learn some programming (and yes, using
Python). Actually, I am thinking that it would be great to begin this in
grade school. But then, I'm also one of those Americans who believe that
every student should learn at least (1) non-English language beginning
in 1st grade--- mandatory. <sigh> (of course others are just hoping
they learn English...)
kind regards,
m harris
Gregory Ewing
>>objects of different types always compare unequal
That's just the default treatment for unrelated types that don't
know anything about each other.
I would guess that the list's == method is asking "Is the
other object a list?", and since a subclass of list is also
a list, it's happy and goes on to compare the elements.
--
Greg
D'Arcy J.M. Cain
harrismh777 <harri...@charter.net> wrote:
> D'Arcy J.M. Cain wrote:
> Non-programmers should not be expected to program in 'C' nor in lisp...
>
> ... but non-programmers were able to program in BASIC jes fine...
They still had to learn the language.
> I contend that non-programmers are able to learn rudimentary python and
> work with it to solve real problems 'without' formal training in
> 'programming'.
When did the discussion shift from "learn the language" to "formal
training?" How you learn the language is totally irrelevant.
> Python is the New BASIC for 'people'. At least, it has the potential to
> be that... people should be able to talk to their computers (whatever
> we mean by that) and have the computer respond with real-world
> solutions. We need to move away from 'canned apps' to a new day where
> the masses can sit down to their computer and solve new problems with it
> through intuitive language skills. Why not?
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.
--
D'Arcy J.M. Cain <da...@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.
Hans Georg Schaathun
<wuw...@gmail.com> wrote:
: Hans Georg Schaathun <h...@schaathun.net> wrote:
: > Revolutionary indeed, so why don't we exploit the revolution
: > and write the programs to be as accessible as possible?
:
: Where do you draw the line, though?
I said that, "as possible". You draw it at the limit of possibility.
: No decorators, as they're not intuitively obvious? No custom
: descriptors, as that requires a deeper knowledge of Python internals
: that utter ignorance allows?
When they help clarify or simplify the code, they are good.
When they do nothing of the sort, they aren't.
: Both of those aspects alone seem far more complex and advanced than
: treating empty collections as False.
Probably, but they also seem far more useful.
--
:-- Hans Georg
Hans Georg Schaathun
<steve+comp....@pearwood.info> wrote:
What application domain has established that terminology?
--
:-- Hans Georg
Hans Georg Schaathun
<greg....@canterbury.ac.nz> wrote:
: Roy Smith wrote:
: > Hans Georg Schaathun <h...@schaathun.net> wrote:
: >>If both are numbers, they are converted to a common type. Otherwise,
: >>objects of different types always compare unequal
Actually, I did not.
:-- hg
Steven D'Aprano
> alex23 wrote:
>>> through intuitive language skills. Why not?
>> Because the vast majority of them don't seem to want to be bothered?
>>
>>
> That could very well be... but I have a hope for them. I honestly think
> its not because they don't want to be bothered, rather they just think
> its too far past them... and not do-able.
An admirable hope, but there is a significant amount of research into
teaching computer programming that suggests that learning to program is
simply beyond a large portion of the population, no matter what you do or
what language you teach. Some 30-60% of people barely get past "Hello
World".
(That's not to imply that they're dumb, just that whatever mental skills
are needed for programming is beyond them, just as whatever mental skills
are needed for writing poetry are beyond me.)
Shorter version: it seems that programming aptitude is a bimodal
distribution, with very little migration from the "can't program" hump
into the "can program" hump. There does seem to be a simple predictor for
which hump you fall into: those who intuitively develop a consistent
model of assignment (right or wrong, it doesn't matter, so long as it is
consistent) can learn to program. Those who don't, can't.
--
Steven
Hans Georg Schaathun
<da...@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
Hans Georg Schaathun
<wuw...@gmail.com> wrote:
Why does that matter? There is a sizeable group who need computers
for purposes not (sufficiently) supported by the `canned apps'.
The fact that they are outnumbered by users who really only need
typewriters and entertainment theatres does in no way reduce the
need of those who actually need /computers/.
--
:-- Hans Georg
Hans Georg Schaathun
<steve+comp....@pearwood.info> wrote:
: *Potentially* different tests. Which is exactly the point. Given an
: 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
Ben Finney
> On Wed, 11 May 2011 20:31:45 -0700 (PDT), alex23
> <wuw...@gmail.com> wrote:
> : On May 12, 7:24 am, harrismh777 <harrismh...@charter.net> wrote:
> : > We need to move away from 'canned apps' to a new day where
> : > the masses can sit down to their computer and solve new problems with it
> : > through intuitive language skills. Why not?
> :
> : Because the vast majority of them don't seem to want to be bothered?
>
> Why does that matter? There is a sizeable group who need computers
> for purposes not (sufficiently) supported by the `canned apps'.
Those people, outnumbered by the masses as you say, are thereby not
themselves “the masses”.
--
\ “Hey Homer! You're late for English!” “Pff! English, who needs |
`\ that? I'm never going to England!” —Barney & Homer, _The |
_o__) Simpsons_ |
Ben Finney
Hans Georg Schaathun
<ben+p...@benfinney.id.au> wrote:
: Hans Georg Schaathun <h...@schaathun.net> writes:
:
: > On Wed, 11 May 2011 20:31:45 -0700 (PDT), alex23
: > <wuw...@gmail.com> wrote:
: > : On May 12, 7:24 am, harrismh777 <harrismh...@charter.net> wrote:
: > : > We need to move away from 'canned apps' to a new day where
: > : > the masses can sit down to their computer and solve new problems with it
: > : > through intuitive language skills. Why not?
: > :
: > : Because the vast majority of them don't seem to want to be bothered?
: >
: > Why does that matter? There is a sizeable group who need computers
: > for purposes not (sufficiently) supported by the `canned apps'.
:
: Those people, outnumbered by the masses as you say, are thereby not
: themselves “the masses”.
So what? Do we only need solutions and systems for the masses?
What about systems for those who develop systems for the masses?
Or the theory necessary to develop the systems to develop more
advanced systems for the masses in the future?
Get real, software development and programming is more than just
overpriced web systems that just almost manage to replicate the
functionality of IBM page based terminals and mainframes of 1973,
just slower and with more eye candy.
--
:-- Hans Georg
Ben Finney
> On Thu, 12 May 2011 16:46:38 +1000, Ben Finney
> <ben+p...@benfinney.id.au> wrote:
> : Hans Georg Schaathun <h...@schaathun.net> writes:
> :
> : > On Wed, 11 May 2011 20:31:45 -0700 (PDT), alex23
> : > <wuw...@gmail.com> wrote:
> : > : On May 12, 7:24 am, harrismh777 <harrismh...@charter.net> wrote:
> : > : > We need to move away from 'canned apps' to a new day where
> : > : > the masses can sit down to their computer and solve new problems with it
> : > : > through intuitive language skills. Why not?
> : > :
> : > : Because the vast majority of them don't seem to want to be bothered?
> : >
> : > Why does that matter? There is a sizeable group who need computers
> : > for purposes not (sufficiently) supported by the `canned apps'.
> :
> : Those people, outnumbered by the masses as you say, are thereby not
> : themselves “the masses”.
>
> So what? Do we only need solutions and systems for the masses?
Your “why does that matter?” was addressed to an answer specifically in
the context of “a new day where the masses can sit down to their
computer and …”. The question is asked and answered.
If you want to raise a *new* topic – that of the non-masses who have
different needs – it's best not to start with “Why does that matter?”
but to lay out your separate case.
--
\ “Visitors are expected to complain at the office between the |
`\ hours of 9 and 11 a.m. daily.” —hotel, Athens |
_o__) |
Ben Finney