<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 10, 2018 at 5:23 AM E. Madison Bray <<a href="mailto:erik.m.bray@gmail.com">erik.m.bray@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed; I believe it is very useful to have a map-like object that is<br>
effectively an augmented list/sequence.</blockquote><div><br></div><div>but what IS a "map-like object" -- I'm trying to imagine what that actually means.</div><div><br></div><div>"map" takes a function and maps it onto a interable, returning a new iterable. So a map object is an iterable -- what's under the hood being used to create it is (and should remain) opaque.</div><div><br></div><div>Back in the day, Python was "all about sequences" -- so map() took a sequence and returned a sequence (an actual list, but that's not the point here). And that's pretty classic "map".</div><div><br></div><div>With py3, there was a big shift toward iterables, rather than sequences as the core type to work with. There are a few other benefits, but the main one is that often sequences were made, simply so that they could be immediately iterated over, and that was a waste of resources.</div><div><br></div><div><font face="monospace, monospace">for i, item in enumerate(a_sequence):</font></div><div><font face="monospace, monospace"> ...</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">for x, y in zip(seq1, seq2):</font></div><div><font face="monospace, monospace"> ...</font></div><div><br></div><div>These two are pretty obvious, but the same approach was taken over much of python: dict.keys(), map(), range(), ....</div><div><br></div><div>So now in Python, you need to decide, when writing code, what your API is -- does your function take a sequence? or does it take an iterable?</div><div><br></div><div>Of course, a sequence is an iterable, but a iterable is not (necessarily) a sequence. -- so back in the day, you din't really need to make the decision.</div><div><br></div><div>So in the case of the Sage example -- I wonder what the real problem is -- if you have an API that requires a sequence, on Py2, folks may have well been passing it the result of a map() call. -- note that they weren't passing a "map object" that is now somehow different than it used to be -- they were passing a list plain and simple. And there are all sorts of places, when converting from py2 to py3, where you will now get an iterable that isn't a proper sequence, and if the API you are using requires a sequence, you need to wrap a list() or tuple() or some such around it to make the sequence.</div><div><br></div><div>Note that you can write your code to work under either 2 or 3, but it's really hard to write a library so that your users can run it under either 2 or 3 without any change in their code!</div><div><br></div><div>But note: the fact that it's a map object is just one special case.</div><div><br></div><div>I suppose one could write an API now that actually expects a map object (rather than a generic sequence or iterable) but it was literally impossible in py2 -- there was no such object.</div><div><br></div><div>I'm still confused -- what's so wrong with:</div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">list(map(func, some_iterable))</font></div><div><br></div><div>if you need a sequence?</div><div><br></div><div>You can, of course mike lazy-evaluated sequences (like range), and so you could make a map-like function that required a sequence as input, and would lazy evaluate that sequence. This could be useful if you weren't going to work with the entire collection, but really wanted to only index out a few items, but I'm trying to imagine a use case for that, and I haven't. And I don't think that's the use case that started this thread...</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div></div>