Re: [Python-Dev] bool(container) [was bool(iter([])) changedbetween 2.3 and 2.4]

[Lisandro Dalcin]

On 9/30/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum]
> > __len__ is for sequences and mappings specifically -- everything that
> > supports __getitem__ should have __len__ and everything that has
> > __len__ should have __getitem__.
>
> That's going a bit far.  Unordered collections (like sets and bags) are
> a good counter-example.
>

I've implemented many extension types in C, always to interface
external libraries (the main examples, MPI and PETSc). In those
libraries, some object are invalid (MPI_COMM_NULL) or can get
deallocated in the C side. I always implement a __nonzero__ method for
testing those situations. It sounds a bit bizarre to me to have to
implement a number method for a object that is far from being a
number, and of course __len__ do not make any sense.

Perhaps Py3k could have a more explicit mechanism for definig the
truth value of an object? Something like __bool__ method to be filled
in type object? Any opinions?


Lisandro Dalcín
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bool(container) [was bool(iter([])) changedbetween 2.3 and 2.4]

[Fredrik Lundh]

Guido van Rossum wrote:

> "Containerish" behavior isn't enough to warrant empty <--> false; in
> some sense every object is a container (at least every object with a
> __dict__ attribute) and you sure don't want to map __len__ to
> self.__dict__.__len__...

the ElementTree experience shows that doing

def __getitem__(self, index):
return self.items[index]
def __len__(self):
return len(self.items)
def __nonzero__(self):
return True

is sometimes a good idea, even for objects that are mostly sequences.

(ET 1.2.X lacks the __nonzero__ method, and accidentally treating
elements with no subelements as if the element itself doesn't exist is by
far the most common gotcha in ET code).

 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bool(container) [was bool(iter([])) changedbetween 2.3 and 2.4]

[Raymond Hettinger]

[Guido van Rossum]
> __len__ is for sequences and mappings specifically -- everything that
> supports __getitem__ should have __len__ and everything that has
> __len__ should have __getitem__.

That's going a bit far.  Unordered collections (like sets and bags) are
a good counter-example.



Raymond

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bool(container) [was bool(iter([])) changedbetween 2.3 and 2.4]

[Michael Chermside]

Jim Jewett writes:
> Python doesn't worry about a precise boolean object, it
> distinguishes between something and nothing.
>
> Is there anything left?" is a pretty good analogy for iterators.
  [...]
> A Queue.Queue is always true.  Should I submit a bug patch

I would have phrased this very differently. I would have said
it as follows:

  All Python objects can be converted to a boolean value. Most
  objects are True, except for False (of course), None, any number
  equal to 0, an empty string (""), and the empty containers
  (), [], and {}. User defined objects can override __len__ or
  __nonzero__ to return False; everything else is True.

I don't believe that there is an overarching rule that all "containers"
must be false when empty. I'm not sure there is even a clear
definition of "container" that would satisfy everyone. It makes
complete sense to me that empty iterators and Queue.Queues are True...
it follows the general rule that everything is true except the above
(short) list of objects and user-defined (or library) classes that
want to mimic the behavior of one of these or have some obvious
meaning for non-true.

-- Michael Chermside

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com