Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

checking if a list is empty

 

 

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded


jjl at pobox

May 21, 2011, 7:46 AM

Post #151 of 161 (1544 views)
Permalink
Re: checking if a list is empty [In reply to]

Gregory Ewing <greg.ewing [at] canterbury> writes:

> Hans Georg Schaathun wrote:
>> 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.

(apologies if somebody already bikeshedded this argument in this thread)

In the absence of an explicit interface declaration (have any standards
emerged for that in Python 3, BTW?), the use of len() does give you some
information about the interface, which sometimes makes it easier to
change the function.

I'm sure you fully understand this, but I'll spell it out. Consider
this function:

def xyzzy(x):
if x:
print "yes"


Let's say I've read the function, and I've seen this call site:

xyzzy(["spam", "eggs"])


Now I want to change xyzzy:

def xyzzy(x):
if x:
print "probably"
if len(x) == 1:
print "definitely"


But there may be many call sites. Perhaps xyzzy even implements part of
a poorly-documented external API. So can x be None? There's no way to
know short of checking all call sites, which may be impossible. It may
not even be feasible to check the *only* call site, if you're
implementing somebody else's poorly documented closed-source API (a
situation I came across at work only yesterday, when that situation
resulted in a bug report). If it's written this way, it's clear that it
can't be None:

def xyzzy(x):
if len(x) != 0:
print "yes"


John
--
http://mail.python.org/mailman/listinfo/python-list


emile at fenx

May 21, 2011, 8:52 AM

Post #152 of 161 (1540 views)
Permalink
Re: checking if a list is empty [In reply to]

On 5/21/2011 7:46 AM John J Lee said...
> Gregory Ewing<greg.ewing [at] canterbury> writes:
>
>> Hans Georg Schaathun wrote:
>>> 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.
>
> (apologies if somebody already bikeshedded this argument in this thread)
>
> In the absence of an explicit interface declaration (have any standards
> emerged for that in Python 3, BTW?), the use of len() does give you some
> information about the interface, which sometimes makes it easier to
> change the function.
>
> I'm sure you fully understand this, but I'll spell it out. Consider
> this function:
>
> def xyzzy(x):
> if x:
> print "yes"
>
>
> Let's say I've read the function, and I've seen this call site:
>
> xyzzy(["spam", "eggs"])
>
>
> Now I want to change xyzzy:
>
> def xyzzy(x):
> if x:
> print "probably"
> if len(x) == 1:
> print "definitely"
>
>
> But there may be many call sites. Perhaps xyzzy even implements part of
> a poorly-documented external API. So can x be None? There's no way to
> know short of checking all call sites, which may be impossible. It may
> not even be feasible to check the *only* call site, if you're
> implementing somebody else's poorly documented closed-source API (a
> situation I came across at work only yesterday, when that situation
> resulted in a bug report). If it's written this way, it's clear that it
> can't be None:

qualified: "...without having been trapped or crashing" so if I found
this function in running code it would be clear to me that, given that
the app is running and hasn't been crashing, either it hasn't yet been
None, or the code isn't accessed at all.

Emile



>
> def xyzzy(x):
> if len(x) != 0:
> print "yes"
>
>
> John


--
http://mail.python.org/mailman/listinfo/python-list


tjreedy at udel

May 21, 2011, 1:11 PM

Post #153 of 161 (1536 views)
Permalink
Re: checking if a list is empty [In reply to]

On 5/21/2011 10:46 AM, John J Lee wrote:

> In the absence of an explicit interface declaration (have any standards
> emerged for that in Python 3, BTW?), the use of len() does give you some
> information about the interface, which sometimes makes it easier to
> change the function.
>
> I'm sure you fully understand this, but I'll spell it out. Consider
> this function:
>
> def xyzzy(x):
> if x:
> print "yes"

To me, this trivial procedure (it is not a mathematical function) is too
unrealistic to be a basis for argument.

> Let's say I've read the function, and I've seen this call site:
>
> xyzzy(["spam", "eggs"])
>
> Now I want to change xyzzy:
>
> def xyzzy(x):
> if x:
> print "probably"
> if len(x) == 1:
> print "definitely"

You are not changing xyzzy, you are replacing a procedure whose domain
is all python objects with a new procedure with a much reduced domain.
In other words, you are changing (and contracting) the idea of the
procedure. This is a somewhat crazy thing to do and if Python developers
did something like that in the stdlib, I would expect multiple protest
posting ;-). (Adding code to *expand* the domain is a different matter.)

If xyzzy were really about sized collections, then
1. That should be documented *before* it is ever used in permanent code.
2. There should be code in the first production version that uses that
fact and which would raise an error on other inputs.

> But there may be many call sites. Perhaps xyzzy even implements part of
> a poorly-documented external API. So can x be None? There's no way to
> know short of checking all call sites, which may be impossible. It may
> not even be feasible to check the *only* call site, if you're
> implementing somebody else's poorly documented closed-source API (a
> situation I came across at work only yesterday, when that situation
> resulted in a bug report). If it's written this way, it's clear that it
> can't be None:
>
> def xyzzy(x):
> if len(x) != 0:
> print "yes"

I agree that the domain of a function should be defined from the start
(and only expanded in the future). This means considering from the
start, or certainly once it runs correctly for intended inputs, what
will happen for other inputs. For instance, I believe functions defined
on counts (0, 1, 2, ...) should be written to avoid infinite looping on
other inputs, in particular, fractional and negative numbers. I can
imagine in theory that a gratuitous call to len() might be useful for
defining an interface, but as explained above, I am dubious about that
in practice and do not find thid example convincing.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list


steve+comp.lang.python at pearwood

May 21, 2011, 6:02 PM

Post #154 of 161 (1528 views)
Permalink
Re: checking if a list is empty [In reply to]

On Sat, 21 May 2011 15:46:01 +0100, John J Lee wrote:

> In the absence of an explicit interface declaration (have any standards
> emerged for that in Python 3, BTW?), the use of len() does give you some
> information about the interface, which sometimes makes it easier to
> change the function.

Er, yes? But in any realistic example (your trivial function xyzzyx below
is not very realistic) you'll almost certainly get additional hints in
the function body. If you have your stereotypical badly-documented
function that does this:

def spam(x):
if x:
print("no")
# ...
x.append(42)
# ...

that's a hint that x is actually meant to be a list. If instead it says

x += 42

that's a good hint that x should not be a list. In either case, changing
the test from "if x" to "if x == []" or "if len(x) == 0" or "if x == 0"
doesn't gain you anything except a slightly longer average line length.
If you're being paid by the character, that's an advantage, but
otherwise, why bother?

True, if the function is sufficiently trivial, as in your xyzzyx example,
then there won't be any such hints as to what sort of input the function
expects. If that's the case, then chances are that the function accepts
*any* object:

> def xyzzy(x):
> if x:
> print "yes"

and changing its semantics to only accept (say) lists, as in your
example, is a risky thing to do.

It is *much* safer to leave that function untouched, create a new one:

def my_xyzzy(alist):
if alist:
print "probably"
if len(alist) == 1:
print "definitely"

and then change the calls to xyzzyx into my_xyzzyx when and as you
determine that it is safe to do so. That will ensure that if you miss a
call of xyzzyx(42) somewhere deep in the library, the code will continue
to run. If not, you'll have a dead function. You can always take it out
later, once you are confident that it is indeed dead code.


[...]
> If it's written this way, it's clear that it can't be None:
>
> def xyzzy(x):
> if len(x) != 0:
> print "yes"


But you're assuming that the function actually is intended to accept only
objects with a __len__ method. If that is the author's intention, there
are better ways of signaling that fact.

I'm not entirely sure what your point is... is it to encourage lazy
programmers to write "len(x)==0" instead of documentation and meaningful
names, or are you just pointing out the occasional silver-lining to a
practice which is generally and usually unnecessary?



--
Steven
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

May 21, 2011, 7:56 PM

Post #155 of 161 (1534 views)
Permalink
Re: checking if a list is empty [In reply to]

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

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

Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list


rustompmody at gmail

May 21, 2011, 8:02 PM

Post #156 of 161 (1541 views)
Permalink
Re: checking if a list is empty [In reply to]

On May 22, 1:11 am, Terry Reedy <tjre...@udel.edu> wrote:

> I agree that the domain of a function should be defined from the start
> (and only expanded in the future).

I dont understand...
I dont always write correct code -- otherwise called 'a bug' -- though
I never let the damn bug lose intentionally.
And when I see 'the bug' scampering around to my distress the only way
of catching it sometimes is to strengthen an (perhaps earlier
unthought, unspecified) invariant or precondition.
Which amounts to contracting the domain.

> This is a somewhat crazy thing to do and if Python developers
> did something like that in the stdlib, I would expect multiple protest
> posting ;-).

That such protests happen is evidence (I dont say proof) that such
contractions are sometimes necessary. In fact when I pick up some
code marked as 'alpha' I understand it as saying:
Please try this and send us (the developers) bug reports. But in no
case are we committed to the current API.
[.Sometimes this is explicitly said. It is always implied by the
'alpha']

When I see 'Beta' I understand: We think this works and we will not
make gratuitous changes but no guarantees.

When I see 'Stable' I understand: The API is fixed (ie we will not
change it) and we accept the inevitable consequence [Seventh Lehman-
Belady law:
http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution ]

Why is the C library in linux called libc6 and not just libc?
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

May 21, 2011, 8:52 PM

Post #157 of 161 (1529 views)
Permalink
Re: checking if a list is empty [In reply to]

On Sun, May 22, 2011 at 1:02 PM, rusi <rustompmody [at] gmail> wrote:
> Why is the C library in linux called libc6 and not just libc?

I assume you mean this? http://www.linux-m68k.org/faq/glibcinfo.html

When you dynamically link against a shared object, you save on
executable size, but you have to have that shared object on the target
system. That's completely different from API changes. I could compile
my code using half a dozen different compilers, and use dynamic
linking each time, and then those six binaries would expect six
implementations of libc on the target computer. They're incompatible
with each other. But they will all have a size_t strlen(const char *)
that tells me how long my string is.

Everyone has a different way of handling incompatible API changes. The
most common is to simply deprecate the old function and create a new
one. It's simple and effective. With your original xyzzy function,
create a my_xyzzy as per Steven's suggestion; job done. (I'd assume
that a function called "my_xyzzy" is a local override, in the same way
that I might write a "my_malloc" that does some statisticking and then
returns malloc(sz), but that's one of the consequences of trivia - you
can't really name it descriptively.)

Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list


rustompmody at gmail

May 21, 2011, 9:32 PM

Post #158 of 161 (1532 views)
Permalink
Re: checking if a list is empty [In reply to]

On May 22, 8:52 am, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, May 22, 2011 at 1:02 PM, rusi <rustompm...@gmail.com> wrote:
> > Why is the C library in linux called libc6 and not just libc?
>
> I assume you mean this?http://www.linux-m68k.org/faq/glibcinfo.html

Ha Ha! Thanks for that link! I quote:

> You should not be using libc4 for anything any more. If you do use it, we will hunt you
> down and execute you as an example to others. (Not really, but you get the point...)

Recently on the emacs list there was a big flame-fest because the
behavior (aka interface) of return/newline changed.
The argument for change: Can we have emacs behave a little more like a
21st century application?
Against: Somebody's scripting code broke badly.

You may take any side you like.
--
http://mail.python.org/mailman/listinfo/python-list


rosuav at gmail

May 21, 2011, 10:16 PM

Post #159 of 161 (1530 views)
Permalink
Re: checking if a list is empty [In reply to]

On Sun, May 22, 2011 at 2:32 PM, rusi <rustompmody [at] gmail> wrote:
> Recently on the emacs list there was a big flame-fest because the
> behavior (aka interface) of return/newline changed.
> The argument for change: Can we have emacs behave a little more like a
> 21st century application?
> Against: Somebody's scripting code broke badly.
>
> You may take any side you like.

The side I take is: If you want emacs, use emacs. If you want SciTE,
use SciTE. If you want nano, use nano. And sometimes, you might have
special circumstances that demand a different choice (can't use SciTE
over ssh, afaik), so it's worth learning more than one.

Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list


hobson42 at gmail

May 22, 2011, 2:20 AM

Post #160 of 161 (1527 views)
Permalink
Re: checking if a list is empty [In reply to]

On 12/05/2011 04:51, Chris Angelico wrote:
> On Thu, May 12, 2011 at 7:02 AM, Ian<hobson42 [at] gmail> wrote:
>> 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
He He.

I didn't claim an empty list was not useful! If you maintain it
between trips, then
yes, you arrive back with an empty list.

Ian



--
http://mail.python.org/mailman/listinfo/python-list


nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915 at spa

May 22, 2011, 1:41 PM

Post #161 of 161 (1530 views)
Permalink
Re: checking if a list is empty [In reply to]

Am 11.05.2011 23:02 schrieb Ian:

> On 11/05/2011 20:13, Hans Georg Schaathun wrote:
>> Lists do not have truth values in the
>> application domain, and therefore truth values in the
>> implementation domain is complicated.
>>
> Exactly. Its just a convention. If it exists, its true, if if doesn't
> its false.

Right. And not only that: Python objects resp. classes not claiming to
have a truth value (__nonzero__), but a length (__len__) are judged by
that concerning their truth value: iff the length is 0, their truth
value is False.


Thomas
--
http://mail.python.org/mailman/listinfo/python-list

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.