On Sun, Oct 13, 2019 at 06:41:40PM -0400, David Mertz wrote:
> My real world is looking at some function in an existing codebase that
> handles a nested data structure.
That rules out sets, since sets aren't hashable and cannot be
inserted into a set.
> At some leaf I can tell I'm handling a
> bunch of scalars by looking at the code (i.e. a loop or a reduction).
>
> Somewhere far upstream that data was added to the structure. And somewhere
> downstream we might do something sensitive to the data type. But right
> here, it's just "a bunch of stuff."
Let me see if I understand your workflow:
1. upstream: you build up a nested data structure, adding elements as
needed
2. midstream: you treat the nested data structure as "a bunch of stuff"
3. downstream: you pull the nested data structure apart
In the midstream, what are you doing to this bunch of stuff? That's the
critical point. It seems to me that there's not very much you can do
(apart from printing it) without knowing something about the structure.
The upstream and the downstream will care about the structure, and will
care about the distinction between sets and lists. Upstream needs to
know that adding a set will fail, but appending a set will be fine:
list.append(myset) # fine, sets can go into lists
set.add(myset) # fails, because sets aren't hashable
Giving list-or-set a common "push/add/append" method won't help you
here, you still need to distinguish between pushing to the end of a list
and pushing into an unordered set.
If midstream is adding stuff, then it's not really midstream, its part
of upstream. If midstream *isn't* adding stuff, then this proposed
push/add/append common method is irrelevant to midstream.
> I rarely see the "bunch" being
> genuinely polymorphic, but I also just don't want or need to think about
> which collection it is to edit this code.... Except I do if I want to "just
> add item".
Can you add a set? If you append an element, will you introduce a
duplicate? You surely care about this, which means you're not really
indifferent to whether "bunch-of-stuff" is a list or a set.
I might have misunderstood your use-case, but so far I don't see that
this is a convincing case for a common method.
I will admit that there's a tiny bit of convenience: you can write
"bunch.push()" without thinking about what you are pushing into (is it a
set? a list? nested or flat? a custom class?), and whether it will
succeed and whether it will mess up your data structure. So
"convenience" is a benefit of this common method.
But I think that argument from convenience is a weak argument. And a
convenience function in your own module is probably sufficient, rather
than burdening every Python user with having to learn another
(redundant) method.
> Moreover, it's not uncommon to want to optimize the upstream choice of
> container and need as little refactoring downstream as possible.
There is that, but you have to balance the convenience of not having to
mechanically change method names (don't you have an IDE with a refactor
command for that?^1 ) versus the benefit of having two different
operations (add to a set versus append to a list) having different,
self-explanatory names.
^1 I don't, so I'm not entirely unsympathetic to this argument.
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/H6VDVYPLGO5R5WPJHI6KM6VDPHJIPTUM/
Code of Conduct: http://python.org/psf/codeofconduct/
