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
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
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
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
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
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?
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
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
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
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
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
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
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,
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
14 matches
Mail list logo