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

2018-12-01 Thread Adam Johnson
On Sat, 1 Dec 2018 at 01:17, Steven D'Aprano wrote: > > In principle, we could make this work, by turning the output of map() > into a view like dict.keys() etc, or a lazy sequence type like range(). > wrapping the underlying sequence. That might be worth exploring. I can't > think of any obvious

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

2018-12-01 Thread Greg Ewing
Adam Johnson wrote: def takewhile_lessthan4(x): if x < 4: return x raise StopIteration tuple(map(takewhile_lessthan4, range(9))) # (0, 1, 2, 3) I really don't understand why this is true, under 'normal' usage, map shouldn't have any reason to silently swallow a StopIteration ra

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

2018-12-01 Thread Adam Johnson
On Sat, 1 Dec 2018 at 10:44, Greg Ewing wrote: > It's not -- the StopIteration isn't terminating the map, > it's terminating the iteration being performed by tuple(). That was a poor choice of wording on my part, it's rather that map doesn't do anything special in that regard. To whatever is iter

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

2018-12-01 Thread Paul Svensson
On Sat, 1 Dec 2018, Steven D'Aprano wrote: On Thu, Nov 29, 2018 at 08:13:12PM -0500, Paul Svensson wrote: What's being proposed is simple, either: * len(map(f, x)) == len(x), or * both raise TypeError Simple, obvious, and problematic. Here's a map object I prepared earlier: from itertool

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

2018-12-01 Thread David Mertz
A proposal to make map() not return an iterator seems like a non-starter. Yes, Python 2 worked that way, but that was a long time ago and we know better now. In the simple example it doesn't matter much: mo = map(lambda x: x, "aardvark") But map() is more useful for the non-toy case: mo = m

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

2018-12-01 Thread Steven D'Aprano
On Sat, Dec 01, 2018 at 11:07:53AM -0500, Paul Svensson wrote: [...] > >Here's a map object I prepared earlier: > > > >from itertools import islice > >mo = map(lambda x: x, "aardvark") > >list(islice(mo, 3)) > > > >If I now pass you the map object, mo, what should len(mo) return? Five > >or eight?

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

2018-12-01 Thread David Mertz
On Sat, Dec 1, 2018, 11:54 AM Steven D'Aprano # current behaviour > mo = map(lambda x: x, "aardvark") > list(islice(mo, 3)) # discard the first three items > assert ''.join(mo) == 'dvark' > => passes > > # future behaviour, with your proposal > assert ''.join(mo) == 'dvark' > => fails with Assert

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

2018-12-01 Thread Steven D'Aprano
On Sat, Dec 01, 2018 at 11:27:31AM -0500, David Mertz wrote: > A proposal to make map() not return an iterator seems like a non-starter. > Yes, Python 2 worked that way, but that was a long time ago and we know > better now. Paul is certainly not suggesting reverting the behaviour to the Python2

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

2018-12-01 Thread Steven D'Aprano
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

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

2018-12-01 Thread David Mertz
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 On Sat, Dec 01, 2018 at 12:06:23P

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

2018-12-01 Thread Steven D'Aprano
On Sat, Dec 01, 2018 at 12:28:16PM -0500, David Mertz 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. I don't under

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

2018-12-01 Thread David Mertz
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 ma

[Python-ideas] Suggested MapView object (Re: __len__() for map())

2018-12-01 Thread Greg Ewing
Steven D'Aprano wrote: For backwards compatibilty reasons, we can't just make map() work like this, because that's a change in behaviour. Actually, I think it's possible to get the best of both worlds. Consider this: from operator import itemgetter class MapView: def __init__(self, func,

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

2018-12-01 Thread Chris Angelico
On Sun, Dec 2, 2018 at 12:08 PM Greg Ewing wrote: > class MapView: > def __len__(self): > return min(map(len, self.args)) > > def __iter__(self): > return self > > def __next__(self): > if not self.iterator: > self.iterator = map(self.func, *s