FYI, itertools.compress() is very useful in conjunction with
itertools.cycle() to pick out elements following a periodic pattern of
indices. For example,
# Elements at even indices.
>>> list(compress(range(20), cycle([1, 0])))
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
# Or at odd ones.
>>>
I've never used compress() either. But I probably HAVE selected only the
"truthy" elements of an iterable. The obvious way to do that is:
it = (x for x in it if x)
It feels like changing compress() would just be more obscure, but not add
to clarity.
On Mon, Sep 13, 2021, 5:07 PM Rob Cliffe via
My 2c:
I don't remember ever seeing itertools.compress (although I've
occasionally browsed through itertools), and I've certainly never used
it. However, having worked out what it does, my first reaction was that
this would be a harmless and mildly convenient change. But might it not
lead
You can already do this using filter(None, a)
>>> list(filter(None, [None, "", "-filove-python", "CFLAGS=-O3"]))
['-filove-python', 'CFLAGS=-O3']
There's arguably a minor readability improvement (compress(a) suggests
"remove the unneeded elements") but I'm not sure that's enough to
Hi!
I propose to enhance "itertools.compress" in such a way so if you don't provide
selectors, then "data" itself is used as a selectors.
So "compress(a)" would be equivalent to "compress(a, a)"
For example:
>>> from itertools import compress
>>> [*compress([0, 1, 2, 3]))]
[1, 2, 3]
>>>
>
> What about asserts that are not used for testing, but as classic “unless
> there’s a bug, this should hold”?
To me this relates to the thread about having a structured *assert* that
doesn't go away with *-O*.
My purpose when addressing *assert* was precisely the *“unless there’s a
bug, this
