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

Paul Moore p.f.moore at gmail.com
Tue Dec 11 06:13:12 EST 2018

On Tue, 11 Dec 2018 at 10:38, E. Madison Bray <erik.m.bray at gmail.com> wrote:
> I don't understand why this is confusing.
> For something like a fixed sequence a "map" could just as easily be
> defined as a pair (<function>, <sequence>) that applies <function>,
> which I'm claiming is a pure function, to every element returned by
> the <sequence>.  This transformation can be applied lazily on a
> per-element basis whether I'm iterating over it, or performing random
> access (since <sequence> is known for all N).

What's confusing to *me*, at least, is what's actually being suggested
here. There's a lot of theoretical discussion, but I've lost track of
how it's grounded in reality:

1. If we're saying that "it would be nice if there were a function
that acted like map but kept references to its arguments", that's easy
to do as a module on PyPI. Go for it - no-one will have any problem
with that.
2. If we're saying "the builtin map needs to behave like that", then
  2a. *Why*? What is so special about this situation that the builtin
has to be changed?
  2b. Compatibility questions need to be addressed. Is this important
enough to code that "needs" it that such code is OK with being Python
3.8+ only? If not, why aren't the workarounds needed for Python 3.7
good enough? (Long term improvement and simplification of the code
*is* a sufficient reason here, it's just something that should be
explicit, as it means that the benefits are long-term rather than
  2c. Weird corner case questions, while still being rare, *do* need
to be addressed - once a certain behaviour is in the stdlib, changing
it is a major pain, so we have a responsibility to get even the corner
cases right.
  2d. It's not actually clear to me how critical that need actually
is. Nice to have, sure (you only need a couple of people who would use
a feature for it to be "nice to have") but beyond that I haven't seen
a huge number of people offering examples of code that would benefit
(you mentioned Sage, but that example rapidly degenerated into debates
about Sage's design, and while that's a very good reason for not
wanting to continue using that as a use case, it does leave us with
few actual use cases, and none that I'm aware of that are in
production code...)
3. If we're saying something else (your comment "map could just as
easily be defined as..." suggests that you might be) then I'm not
clear what it is. Can you describe your proposal as pseudo-code, or a
Python implementation of the "map" replacement you're proposing?


More information about the Python-ideas mailing list