On 12/1/2018 2:08 PM, Steven D'Aprano wrote:
This proof of concept wrapper class could have been written any time
since Python 1.5 or earlier:
class lazymap:
def __init__(self, function, sequence):
One could now add at the top of the file
from collections.abc import Sequence
and
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
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
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
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
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 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
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
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 =
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
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
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
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
On Thu, Nov 29, 2018 at 08:13:12PM -0500, Paul Svensson wrote:
> Excellent proposal, followed by a flood of confused replies,
> which I will mostly disregard, since all miss the obvious.
When everyone around you is making technical responses which you think
are "confused", it is wise to
On Fri, Nov 30, 2018 at 10:32:31AM +0100, E. Madison Bray wrote:
> I think it goes without saying that
> map() is special in a way: It's one of the most basic extensions to
> function application and is a fundamental construct in functional
> programming and from a category-theortical
On Thu, Nov 29, 2018 at 9:36 PM Terry Reedy wrote:
> >> https://docs.python.org/3/library/functions.html#map says
> >> "map(function, iterable, ...)
> >> Return an iterator [...]"
> >>
> >> The wording is intentional. The fact that map is a class and the
> >> iterator an instance of the
On Thu, Nov 29, 2018 at 7:16 PM Jonathan Fine wrote:
>
> On Thu, Nov 29, 2018 at 2:44 PM Steven D'Aprano wrote:
>
> > You might say that your users are not so advanced, or that they're naive
> > enough not to even know they could do that, but that's a pretty unsafe
> > assumption as well as
That would be great especially if it returned objects of a subclass of map
so that it didn't break any code that checks isinstance, however; I think
this goes a little beyond map. I've run into cases using itertools where I
wished the iterators could support len. I suppose you could turn those all
On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
I just ran into the following behavior, and found it surprising:
len(map(float, [1,2,3]))
TypeError: object of type 'map' has no len()
I understand that map() could be given an infinite sequence and therefore might
not always have a
[David Mertz]
> Do you anticipate that the `len()` function will be able to solve the
> Halting Problem?
>
It is simply not possible to know whether a given iterator will produce
> finitely many or infinitely many elements. Even those that will produce
> finitely many do not, in general, have
On 11/29/2018 8:16 AM, E. Madison Bray wrote:
Okay, let's keep it simple:
m = map(str, [1, 2, 3])
len_of_m = None
if len(m.iters) == 1 and isinstance(m.iters[0], Sized):
len_of_m = len(m.iters[0])
As I have noted before, the existing sized collection __length_hint__
methods (properly)
On 11/29/2018 6:13 AM, E. Madison Bray wrote:
On Wed, Nov 28, 2018 at 8:54 PM Terry Reedy wrote:
The CPython map() implementation already carries this data on it as
"func" and "iters" members in its struct. It's trivial to expose
those to Python as ".funcs" and ".iters" attributes. Nothing
On Thu, Nov 29, 2018 at 2:44 PM Steven D'Aprano wrote:
> You might say that your users are not so advanced, or that they're naive
> enough not to even know they could do that, but that's a pretty unsafe
> assumption as well as being rather insulting to your own users, some of
> whom are surely
Alright, I didn’t see those problem. Though I was suggesting that for
functions like map, we just let the used iterator answer, this is
interesting. Thanks for this
On Thu 29 Nov 2018 at 17:40, David Mertz wrote:
> On Thu, Nov 29, 2018 at 2:29 AM Adrien Ricocotam
> wrote:
>
>> Some suggested
On Thu, Nov 29, 2018 at 2:29 AM Adrien Ricocotam
wrote:
> Some suggested above to change the definition of len in the long term.
> Then I think it could be interesting to define len such as :
>
> - If has a finite length : return that length (the way it works now)
> - If has a length that is
On Thu, Nov 29, 2018 at 3:43 PM Steven D'Aprano wrote:
>
> On Thu, Nov 29, 2018 at 02:16:48PM +0100, E. Madison Bray wrote:
>
> > Okay, let's keep it simple:
> >
> > m = map(str, [1, 2, 3])
> > len_of_m = None
> > if len(m.iters) == 1 and isinstance(m.iters[0], Sized):
> > len_of_m =
On Thu, Nov 29, 2018 at 02:16:48PM +0100, E. Madison Bray wrote:
> Okay, let's keep it simple:
>
> m = map(str, [1, 2, 3])
> len_of_m = None
> if len(m.iters) == 1 and isinstance(m.iters[0], Sized):
> len_of_m = len(m.iters[0])
>
> You can give me pathological cases where that isn't true,
On Thu, Nov 29, 2018 at 2:05 PM E. Madison Bray wrote:
> The users--often scientists--of SageMath and many other scientific
> Python packages* are not "Python programmers" as such**. My job as a
> software engineer is to make the lower-level libraries they use for
> their day-to-day research
On Thu, Nov 29, 2018 at 2:22 PM Chris Angelico wrote:
>
> On Fri, Nov 30, 2018 at 12:18 AM Steven D'Aprano wrote:
> > Sage wraps a number of Python libraries, such as numpy, sympy and
> > others, and itself can run under iPython which for all we know may
> > already have monkeypatched the
On Fri, Nov 30, 2018 at 12:18 AM Steven D'Aprano wrote:
> Sage wraps a number of Python libraries, such as numpy, sympy and
> others, and itself can run under iPython which for all we know may
> already have monkeypatched the builtins for its own ~~nefarious~~ useful
> purposes. Are you really
On Thu, Nov 29, 2018 at 10:21:15PM +1100, Chris Angelico wrote:
> On Thu, Nov 29, 2018 at 10:18 PM E. Madison Bray
> wrote:
> >
> > On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray
> > > wrote:
[...]
> > > If that's the case,
On Thu, Nov 29, 2018 at 1:38 PM Steven D'Aprano wrote:
>
> On Thu, Nov 29, 2018 at 12:16:37PM +0100, E. Madison Bray wrote:
> > On Wed, Nov 28, 2018 at 11:27 PM Steven D'Aprano
> > wrote:
>
> ["it" below being the length of an arbitrary iterator]
>
> > > If we could solve it, that would be
On Thu, Nov 29, 2018 at 12:21 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 10:18 PM E. Madison Bray
> wrote:
> >
> > On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray
> > > wrote:
> > > > P.S.
> > > >
> > > > > > This
On Thu, Nov 29, 2018 at 12:16:37PM +0100, E. Madison Bray wrote:
> On Wed, Nov 28, 2018 at 11:27 PM Steven D'Aprano wrote:
["it" below being the length of an arbitrary iterator]
> > If we could solve it, that would be great -- but I'm not convinced that
> > it is solvable, since the solution
On Thu, Nov 29, 2018 at 10:18 PM E. Madison Bray wrote:
>
> On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico wrote:
> >
> > On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray
> > wrote:
> > > P.S.
> > >
> > > > > This is necessary because if I have a function that used to take, say,
> > > > > a
On Thu, Nov 29, 2018 at 12:16 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray
> wrote:
> > P.S.
> >
> > > > This is necessary because if I have a function that used to take, say,
> > > > a list as an argument, and it receives a `map` object, I now have to
> > > >
On Wed, Nov 28, 2018 at 11:27 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 02:53:50PM -0500, Terry Reedy wrote:
> > What makes the map class special among all built-in iterator classes?
> > It appears not to be a property of the class itself, as an iterator
> > class, but of its name.
On Thu, Nov 29, 2018 at 10:14 PM E. Madison Bray wrote:
> P.S.
>
> > > This is necessary because if I have a function that used to take, say,
> > > a list as an argument, and it receives a `map` object, I now have to
> > > be able to deal with map()s,
> >
> > If a function is documented as
On Wed, Nov 28, 2018 at 8:54 PM Terry Reedy wrote:
>
> On 11/28/2018 9:27 AM, E. Madison Bray wrote:
> > On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
> >>
> >> I just ran into the following behavior, and found it surprising:
> >>
> > len(map(float, [1,2,3]))
> >> TypeError: object of
On Wed, Nov 28, 2018 at 11:04 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 05:37:39PM +0100, Anders Hovmöller wrote:
> >
> >
> > > I just mentioned that porting effort for background. I still believe
> > > that the actual proposal of making the arguments to a map(...) call
> > >
On Wed, Nov 28, 2018 at 11:59 PM Greg Ewing wrote:
>
> E. Madison Bray wrote:
> > So I might want to check:
> >
> > finite_definite = True
> > for it in my_map.iters:
> > try:
> > len(it)
> > except TypeError:
> > finite_definite = False
> >
> > if finite_definite:
> >
On 11/28/2018 5:27 PM, Steven D'Aprano wrote:
On Wed, Nov 28, 2018 at 02:53:50PM -0500, Terry Reedy wrote:
One of the guidelines in the Zen of Python is
"Special cases aren't special enough to break the rules."
This proposal claims that the Python 3 built-in iterator class 'map' is
so special
Hi everyone, first participation in Python’s mailing list, don’t be too hard on
me
Some suggested above to change the definition of len in the long term. Then I
think it could be interesting to define len such as :
- If has a finite length : return that length (the way it works now)
- If has a
>> +1. Throwing away information is almost always a bad idea.
>
> "Almost always"? Let's take this seriously, and think about the
> consequences if we actually believed that. If I created a series of
> integers:
“Almost". It’s part of my sentence. I have known about addition for many years
I raised a related problem a while back when I found that random.sample can
only take a sequence. The example I gave was randomly sampling points on a
2D grid to initialize a board for Conway's Game of Life:
>>> def random_board(height: int, width: int, ratio: float = 0.5) ->
Set[Tuple[int,
E. Madison Bray wrote:
So I might want to check:
finite_definite = True
for it in my_map.iters:
try:
len(it)
except TypeError:
finite_definite = False
if finite_definite:
my_seq = list(my_map)
else:
# some other algorithm
If map is being passed into your
E. Madison Bray wrote:
I still believe
that the actual proposal of making the arguments to a map(...) call
accessible from Python as attributes of the map object (ditto filter,
zip, etc.) is useful in its own right, rather than just having this
completely opaque iterator.
But it will only help
On Wed, Nov 28, 2018 at 02:53:50PM -0500, Terry Reedy wrote:
> One of the guidelines in the Zen of Python is
> "Special cases aren't special enough to break the rules."
>
> This proposal claims that the Python 3 built-in iterator class 'map' is
> so special that it should break the rule that
On Wed, Nov 28, 2018 at 05:37:39PM +0100, Anders Hovmöller wrote:
>
>
> > I just mentioned that porting effort for background. I still believe
> > that the actual proposal of making the arguments to a map(...) call
> > accessible from Python as attributes of the map object (ditto filter,
> >
E. Madison Bray wrote:
if I have a function that used to take, say,
a list as an argument, and it receives a `map` object, I now have to
be able to deal with map()s, and I may have checks I want to perform
on the underlying iterables before, say, I try to iterate over the
`map`.
This sounds
On 11/28/2018 9:27 AM, E. Madison Bray wrote:
On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
I just ran into the following behavior, and found it surprising:
len(map(float, [1,2,3]))
TypeError: object of type 'map' has no len()
I understand that map() could be given an infinite
> I just mentioned that porting effort for background. I still believe
> that the actual proposal of making the arguments to a map(...) call
> accessible from Python as attributes of the map object (ditto filter,
> zip, etc.) is useful in its own right, rather than just having this
>
Hi Madison
Is there a URL somewhere where I can view code written to port sage to
Python3? I've already found
https://trac.sagemath.org/search?q=python3
And because I'm a bit interested in cluster algebra, I went to
I should add, I know the history here of bitterness surrounding Python 3
complaints and this is not one. I defend most things Python 3 and have
ported many projects (Sage just being the largest by orders of magnitude,
with every Python 3 porting quirk represented and often magnified). I agree
with
Probably the most proliferate reason it made things *worse* is that many
functions that can take collections as arguments--in fact probably
most--were never written to accept arbitrary iterables in the first place.
Perhaps they should have been, but the majority of that was before my time
so I and
One thing I'd like to add real quick to this (I'm on my phone so apologies
for crappy quoting):
Although there are existing cases where there is a loss of efficiency over
Python 2 map() when dealing with the opaque, iterable Python 3 map(), the
latter also presents many opportunities for
On Wed, Nov 28, 2018 at 04:14:24PM +0100, E. Madison Bray wrote:
> For example, some function that used to expect some finite-sized
> sequence such as a list or tuple is now passed a "map", possibly
> wrapping one or more iterable of arbitrary, possibly non-finite size.
> For the purposes of some
On Wed, Nov 28, 2018 at 4:24 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray wrote:
> >
> > On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
> > >
> > > On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> > >
> > > > That effort is already
On Thu, Nov 29, 2018 at 2:19 AM E. Madison Bray wrote:
>
> On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
> >
> > On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> >
> > > That effort is already mostly done and adding a helper function would
> > > not have worked as
On Wed, Nov 28, 2018 at 4:14 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
>
> > That effort is already mostly done and adding a helper function would
> > not have worked as users *passing* map(...) as an argument to some
> > function just expect
On Wed, Nov 28, 2018 at 4:04 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This
On Wed, Nov 28, 2018 at 04:04:33PM +0100, E. Madison Bray wrote:
> That effort is already mostly done and adding a helper function would
> not have worked as users *passing* map(...) as an argument to some
> function just expect it to work.
Ah, that's what I was missing.
But... surely the
On Wed, Nov 28, 2018 at 4:04 PM Steven D'Aprano wrote:
>
> On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This
On Wed, Nov 28, 2018 at 3:54 PM Chris Angelico wrote:
>
> On Thu, Nov 29, 2018 at 1:46 AM Jonathan Fine wrote:
> >
> > On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray
> > wrote:
> >
> > > I mostly agree with the existing objections, though I have often found
> > > myself wanting this too,
On Wed, Nov 28, 2018 at 03:27:25PM +0100, E. Madison Bray wrote:
> I mostly agree with the existing objections, though I have often found
> myself wanting this too, especially now that `map` does not simply
> return a list. This problem alone (along with the same problem for
> filter) has had a
On Thu, Nov 29, 2018 at 1:46 AM Jonathan Fine wrote:
>
> On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray wrote:
>
> > I mostly agree with the existing objections, though I have often found
> > myself wanting this too, especially now that `map` does not simply
> > return a list. This problem
On Wed, Nov 28, 2018 at 2:28 PM E. Madison Bray wrote:
> I mostly agree with the existing objections, though I have often found
> myself wanting this too, especially now that `map` does not simply
> return a list. This problem alone (along with the same problem for
> filter) has had a
On Mon, Nov 26, 2018 at 10:35 PM Kale Kundert wrote:
>
> I just ran into the following behavior, and found it surprising:
>
> >>> len(map(float, [1,2,3]))
> TypeError: object of type 'map' has no len()
>
> I understand that map() could be given an infinite sequence and therefore
> might not
On 11/26/2018 4:29 PM, Kale Kundert wrote:
I just ran into the following behavior, and found it surprising:
>>> len(map(float, [1,2,3]))
TypeError: object of type 'map' has no len()
I understand that map() could be given an infinite sequence and
therefore might not always have a length.
>
> Equally obvious and valid answer: The length is the smallest length of
> its iterables, ignoring any infinite ones, but if any iterable is
> unsized, the map is unsized.
>
> And both answers will surprise people.
>
> I still think there's room in the world for a "mapped list view" type,
>
On Tue, Nov 27, 2018 at 12:37 PM Kale Kundert wrote:
> I guess I probably would have disagreed with the decision to make map() an
> iterator rather than a wrapper around an iterable. Such a prominent function
> should have an API geared towards usability, not towards implementing a
> low-level
Hi Steven,
Thanks for the good feedback.
> First, the usefulness: we still have to wrap the call to
> len() in a try...except block, even if we know we have a map object,
> because we won't know whether the underlying iterable supports len. So
> it won't reduce the amount of code we have to
On Tue, Nov 27, 2018 at 10:41 AM Steven D'Aprano wrote:
>
> On Tue, Nov 27, 2018 at 09:36:08AM +1100, Chris Angelico wrote:
>
> > Don't forget, too, that map() can take more than one iterable
>
> I forgot about that!
>
> But in this case, I think the answer is obvious: the length of the map
>
On Mon, Nov 26, 2018, 17:38 Steven D'Aprano On Mon, Nov 26, 2018 at 02:06:52PM -0800, Michael Selik wrote:
> > If you know the input is sizeable, why not check its length instead of
> the
> > map's?
>
> The consumer of map may not be the producer of map.
>
> You might know that alist supports
On Tue, Nov 27, 2018 at 09:36:08AM +1100, Chris Angelico wrote:
> Don't forget, too, that map() can take more than one iterable
I forgot about that!
But in this case, I think the answer is obvious: the length of the map
object is the *smallest* length of the iterables, ignoring any unsized
or
On Mon, Nov 26, 2018 at 01:29:21PM -0800, Kale Kundert wrote:
> I just ran into the following behavior, and found it surprising:
>
> >>> len(map(float, [1,2,3]))
> TypeError: object of type 'map' has no len()
>
> I understand that map() could be given an infinite sequence and therefore
> might
>
>
> On Mon, Nov 26, 2018 at 10:14:58PM +, Jonathan Fine wrote:
>
> > Briefly, I don't like your suggestion because many important iterables
> > don't have a length!
>
> But many important iterables do.
>
I agree many important iterables do have.
On Mon, Nov 26, 2018 at 02:06:52PM -0800,
On Mon, Nov 26, 2018 at 10:14:58PM +, Jonathan Fine wrote:
> Briefly, I don't like your suggestion because many important iterables
> don't have a length!
But many important iterables do.
--
Steve
___
Python-ideas mailing list
On Mon, Nov 26, 2018 at 02:06:52PM -0800, Michael Selik wrote:
> If you know the input is sizeable, why not check its length instead of the
> map's?
The consumer of map may not be the producer of map.
You might know that alist supports len(), but by the time I see it, I
only see map(f, alist),
On Tue, Nov 27, 2018 at 9:15 AM Jonathan Fine wrote:
> Briefly, I don't like your suggestion because many important iterables
> don't have a length!
That part's fine. The implication is that mapping over an iterable
with a length would give a map with a known length, and mapping over
something
Hi Kale
Thank you for the sample code. It's most helpful. Please consider
>>> it = iter(range(4))
>>> list(map(float, it))
[0.0, 1.0, 2.0, 3.0]
>>> it = iter(range(4))
>>> list(zip(it, it))
[(0, 1), (2, 3)]
>>> list(zip(range(4), range(4)))
[(0, 0), (1, 1), (2, 2), (3, 3)]
A sequence is
If you know the input is sizeable, why not check its length instead of the
map's?
On Mon, Nov 26, 2018, 1:35 PM Kale Kundert I just ran into the following behavior, and found it surprising:
>
> >>> len(map(float, [1,2,3]))
> TypeError: object of type 'map' has no len()
>
> I understand that
82 matches
Mail list logo
