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

[Steven D'Aprano]

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,
> > zip, etc.) is useful in its own right, rather than just having this
> > completely opaque iterator.
> 
> +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:

a = 23
b = 0x17
c = 0o27
d = 0b10111
e = int('1b', 12)

your assertion would say it is a bad idea to throw away the information 
about how they were created, and hence we ought to treat all five values 
as distinct and distinguishable. So much for the small integer cache...

Perhaps every single object we create ought to hold onto a AST 
representing the literal or expression which was used to create it.

Let's not exaggerate the benefit, and ignore the costs, of "throwing 
away information". Sometimes we absolutely do want to throw away 
information, or at least make it inaccessible to the consumer of our 
data structures.

Sometimes the right thing to do is *not* to open up interfaces unless 
there is a clear need for it to be open. Doing so adds bloat to the 
interface, prevents many changes in implementation including potential 
optimizations, and may carry significant memory burdens.

Bringing this discussion back to the concrete proposal in this thread, 
as I said earlier, I want to agree with this proposal. I too like the 
idea of having map (and filter, and zip...) objects expose their 
arguments, and for the same reason: "it might be useful some day".

But every time we scratch beneath the surface and try to think about how 
and when we would actually use that information, we run into conceptual 
and practical problems which suggests strongly to me that doing this 
will turn it into a serious bug magnet, an anti-feature which sounds 
good but causes more problems than it solves.

I'm really hoping someone can convince me this is a good idea, but so 
far the proposal seems like an attractive nuisance and not a feature.


> We should have information preservation and transparency be general 
> design goals imo. Not because we can see the obvious use now but 
> because it keeps the door open to discover uses later.

While that is a reasonable position to take in some circumstances, 
in others it goes completely against YAGNI.


-- 
Steve