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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
