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

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

Re: checking if a list is empty

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

#6004

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

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

#5166

On Wed, 11 May 2011 20:13:35 +0100, Hans Georg Schaathun wrote:

> 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

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

#5167

On 05/11/2011 02:47 PM, Steven D'Aprano wrote:
> On Wed, 11 May 2011 20:13:35 +0100, Hans Georg Schaathun wrote:
>
>> 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.
>
>
> >>>  a=[]
> >>>  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.

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

#5172

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.

Lists by themselves, empty or not, cannot have a 'truth' in an of 
themselves.


kind regards,
m harris

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

#5176

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

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

#5180

On Wed, 11 May 2011 17:38:58 -0500, harrismh777 wrote:

> 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

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

#5200

On 11 May 2011 21:47:27 GMT, Steven D'Aprano
  <steve+comp.lang.python@pearwood.info> wrote:
:  On Wed, 11 May 2011 20:13:35 +0100, Hans Georg Schaathun wrote:
: > 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.

What application domain has established that terminology?

-- 
:-- Hans Georg

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

#5189

On Thu, May 12, 2011 at 7:02 AM, Ian <hobson42@gmail.com> 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

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

#5237

Chris Angelico wrote:
> On Thu, May 12, 2011 at 7:02 AM, Ian <hobson42@gmail.com> 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).

Um -- you contradicted Ian, then contradicted yourself -- according to 
your scenario your shopping list is *not* empty when you go to the store 
(otherwise known as "going shopping" ;).

~Ethan~

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

#5238

On Fri, May 13, 2011 at 12:02 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
> Chris Angelico wrote:
>>
>> On Thu, May 12, 2011 at 7:02 AM, Ian <hobson42@gmail.com> 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).
>
> Um -- you contradicted Ian, then contradicted yourself -- according to your
> scenario your shopping list is *not* empty when you go to the store
> (otherwise known as "going shopping" ;).

Ehh, mea culpa (I shouldn't post in haste). Replace "Actually, yes you
do" with "Actually, yes they do". Indeed you do not *go shopping* with
a list of zero items; but a shopping list with no items on it DOES
exist (when you come back).

def do_shopping():
  if shopping_list:
    goto shop; # Muahahahahaha.
    for item in shopping_list:
      inventory.append(item)
    return; # Muahahahaha again!

Chris Angelico

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

#5970

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

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

#5175

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.

-- 
Greg

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

#5923

Gregory Ewing <greg.ewing@canterbury.ac.nz> 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

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

#5929

On 5/21/2011 7:46 AM John J Lee said...
> Gregory Ewing<greg.ewing@canterbury.ac.nz>  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

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

#5936

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

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

#5950

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?

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

#5951

On Sun, May 22, 2011 at 1:02 PM, rusi <rustompmody@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

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

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

#5953

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.

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

#5955

On Sun, May 22, 2011 at 2:32 PM, rusi <rustompmody@gmail.com> 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

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

#5945

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

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

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

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

csiph-web