[Python-ideas] __len__() for map()

David Mertz mertz at gnosis.cx
Sat Dec 1 14:26:41 EST 2018


To illustrate the distinction that someone (I think Steven D'Aprano) makes,
I think these two (modestly tested, but could have flaws) implementations
are both sensible for some purposes. Both are equally "obvious," yet they
are different:

>>> import sys
>>> from itertools import count
>>> class map1(object):
...     def __init__(self, fn, *seqs):
...         try:     # See if there is a length
...             self._len = min(map(len, seqs))
...         except:  # Fallback isn't in any sense accurate, just "large"
...             self._len = sys.maxsize
...         self._fn = fn
...         self._seqs = seqs
...         self._iters = [iter(seq) for seq in seqs]
...     def __iter__(self):
...         return self
...     def __next__(self):
...         args = [next(it) for it in self._iters]
...         return self._fn(*args)
...     def __len__(self):
...         return self._len
...
>>> class map2(map1):
...     def __init__(self, fn, *seqs):
...         super().__init__(fn, *seqs)
...     def __next__(self):
...         self._len -= 1
...         return super().__next__()
...
>>> m1 = map1(add, [1,2,3,4], (5,6,7))
>>> len(m1)
3
>>> next(m1)
6
>>> len(m1)
3
>>> m2 = map2(add, [1,2,3,4], (5,6,7))
>>> len(m2)
3
>>> next(m2)
6
>>> len(m2)
2
>>> m1_inf = map1(lambda x: x, count())
>>> len(m1_inf)
9223372036854775807
>>> next(m1_inf)
0
>>> next(m1_inf)
1

I wasn't sure what to set self._len to where it doesn't make sense.  I
thought of None which makes len(mo) raise one exception, or -1 which makes
len(mo) raise a different exception.  I just choose an arbitrary "big"
value in the above implementation. mo.__length_hint__() is a possibility,
but that is specialized, not a way of providing a response to len(mo).

I don't have to, but I do keep around mo._seqs as a handle to the
underlying sequences.  In concept those could be re-inspected for other
properties as the user of the classes desired.


On Sat, Dec 1, 2018 at 12:28 PM David Mertz <mertz at gnosis.cx> wrote:

> Other than being able to ask len(), are there any advantages to a slightly
> less opaque map()? Getting the actual result of applying the function to
> the element is necessarily either eager or lazy, you can't have both.
>
> On Sat, Dec 1, 2018, 12:24 PM Steven D'Aprano <steve at pearwood.info wrote:
>
>> On Sat, Dec 01, 2018 at 12:06:23PM -0500, David Mertz wrote:
>>
>> > Given that the anti-fix is just as simple and currently available, I
>> don't
>> > see why we'd want a change:
>> >
>> > # map->sequence
>> > mo = list(mo)
>> >
>> > FWIW, I actually do write exactly that code fairly often, it's not hard.
>>
>> Sure, but that makes a copy of the original data and means you lose the
>> benefit of map being lazy.
>>
>> Naturally we will always have the ability to call list and eagerly
>> convert to a sequence, but these proposals are for a way of getting the
>> advantages of sequence-like behaviour while still keeping the advantages
>> of laziness.
>>
>> With iterators, the only way to get that advantage of laziness is
>> to give up the ability to query length, random access to items, etc even
>> when the underlying data is a sequence and that information would have
>> been readily available. We can, at least sometimes, have the best of
>> both worlds. Maybe.
>>
>>
>> --
>> Steve
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181201/52d7ffc3/attachment.html>


More information about the Python-ideas mailing list