[Python-ideas] An ABC representing "Iterable, Sized, Container"

[Guido van Rossum]

Yeah, I know that you can define something that's Iterable and
Container but not Sized. But has anyone ever done that outside a test
or demonstration? And PEP 484 can't talk about "this type except if
it's that type", so the operational definition "Iterable except
Iterator" can't be expressed as a type.

If PEP 484 had the concept of Intersection type, I'd probably define X
= Intersection[Sized, Iterable, Container]. But even then I'd like a
name that rolls a little easier off the tongue than FiniteContainer.

If it really must be two words, how about SizedIterable? That suggests
it's a subclass of Sized and Iterable, which it is. Container doesn't
need separate mention, it's pretty obvious that any Iterable can
implement __contains__, and more people know that Iterable is an ABC
than Container.

The new ABC could define a default concrete __contains__ implementation:

class SizedIterable(Sized, Iterable, Container):
    def __contains__(self, value):  # Same as Sequence
        for v in self:
            if v == value:
                return True
        return False

TBH if I had known about ABCs and PEP 484 when we defined the
collections ABCs, I probably would have defined it like that on
Iterable as well, and completely done away with Container as a
separate one-trick pony ABC. Set and Mapping would just override the
default implementation. (Hm... not sure how the default
Set.__contains__ would work though. Can you make a concrete method
abstract in a subclass?)

On Thu, Jul 21, 2016 at 7:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 22 July 2016 at 10:29, Guido van Rossum <guido at python.org> wrote:
>> On Thu, Jul 21, 2016 at 5:05 PM, Thomas Nyberg <tomuxiong at gmail.com> wrote:
>>> On 07/21/2016 07:58 PM, Guido van Rossum wrote:
>>>>
>>>> But there's already Container which means "supports __contains__".
>>>>
>>>> Collection might cause confusing with the module name collections.
>>>>
>>>> Otherwise either would be a good candidate...
>
> As far as the original "Sized Iterable Container" question goes, would
> FiniteContainer work?
>
> - it's countable/iterable
> - it has a quantifiable size
> - you can do membership tests on it
>
> Countable & quantifiable = finite, membership testing = container,
> hence FiniteContainer
>
>>> Coming out of lurking...
>>>
>>> StaticIterable? ConstIterable? Something to indicate that if you just
>>> iterate over it you keep getting the same thing?
>>
>> Neither "static" nor "const" convey the right meaning.
>>
>>> Personally I think Reiterable is about as clear as it ever will be...
>>
>> Yeah, I think that's my conclusion as well.
>
> With the semantics being "iter(x) is not x"?
>
> That seems reasonable to me, as I spent some time think about whether
> or not this is a distinct idea from the "Sized Iterable Container"
> question, and it's pretty easy to demonstrate that it is:
>
>     >>> class ReiterableCounter:
>     ...     def __iter__(self):
>     ...         x = 0
>     ...         while True:
>     ...             yield x
>     ...             x += 1
>     ...
>     >>> ctr = ReiterableCounter()
>     >>> for x in ctr:
>     ...     print(x)
>     ...     if x > 1: break
>     ...
>     0
>     1
>     2
>     >>> for x in ctr:
>     ...     print(x)
>     ...     if x > 1: break
>     ...
>     0
>     1
>     2
>
> (The same example works by returning any non-terminating iterator from __iter__)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



-- 
--Guido van Rossum (python.org/~guido)