On 09.05.20 22:16, Andrew Barnert wrote:
On May 9, 2020, at 02:58, Dominik Vilsmeier <dominik.vilsme...@gmx.de> wrote:
Initially I assumed that the reason for this new functionality was
concerned with cases where the types of two objects are not precisely
known and hence instead of converting them to a common type such as
list, a direct elementwise comparison is preferable (that's probably
uncommon though). Instead in the case where two objects are known to
have different types but nevertheless need to be compared
element-by-element, the performance argument makes sense of course.
So as a practical step forward, what about providing a wrapper type
which performs all operations elementwise on the operands. So for example:
if all(elementwise(chars) == string):
...
Here the `elementwise(chars) == string` part returns a generator which
performs the `==` comparison element-by-element.
This doesn't perform any length checks yet, so as a bonus one could add
an `all` property:
if elementwise(chars).all == string:
...
There’s an obvious use for the .all, but do you ever have a use for the
elementwise itself? When do you need to iterate all the individual comparisons?
(In numpy, an array of bools has all kinds of uses, starting with indexing or
selecting with it, but I don’t think any of them are doable here.)
I probably took too much inspiration from Numpy :-) Also I thought it
would nicely fit with the builtin `all` and `any`, but you are right,
there's probably not much use for the elementwise iterator itself. So
one could use `elementwise` as a namespace for `elementwise.all(chars)
== string` and `elementwise.any(chars) == string` which automatically
reduce the elementwise comparisons and the former also performs a length
check prior to that. This would still leave the option of having
`elementwise(x) == y` return an iterator without reducing (if desired).
And obviously this would be a lot simpler if it was just the all object rather
than the elementwise object—and even a little simpler to use:
element_compare(chars) == string
(In fact, I think someone submitted effectively that under a different name for
more-itertools and it was rejected because it seemed really useful but
more-itertools didn’t seem like the right place for it. I have a similar
“lexicompare” in my toolbox, but it has extra options that YAGNI. Anyway, even
if I’m remembering right, you probably don’t need to dig up the more-itertools
PR because it’s easy enough to redo from scratch.)
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2FSDNFSNBPKP6Y67CRU7W46JO3TUNS74/
Code of Conduct: http://python.org/psf/codeofconduct/
