
On Wed, Sep 15, 2021 at 4:03 AM ml@dyatkovskiy.com <ml@dyatkovskiy.com> wrote:
The signature is wrong. Thanks for remark. Of course proper signature would be:
def jin(a: Iterable[Optional[str]], sep=“ “): # …
Why do you (ab)use compress for that? Well, it seems that it is subjective. To me “[None, x, y, z]” -> “[x, y, z]” looks like “compression”. But if community agrees with your side, then, well, it’s OK.
To me, that looks like filtering. The most common sort of filtering is what the filter() function does - ask a predicate function whether something's good or bad, and keep the good ones. The filtering done by itertools.compress() is slightly different - look it up in a corresponding list of "good" or "bad", and keep the good ones. What you're looking at is asking a question about each element. Specifically, you're asking "is this element truthy or falsy?". That perfectly matches the filter() function.
Alternatively indeed we can use: 2. Use "filter(None, a)” 3. (x for x in a if x)
Why not to use #3?
Only having #2 or #3, I would vote for “filter”. It is a builtin, and used to be implemented as intrinsic. In cpython it has a separate “if” branch for case when first argument is “None” (see “filter_next” function in “bltinmodule.c”)
There's no real difference between #2 and #3. If you feel more comfortable writing comprehensions, write comprehensions. If you feel more comfortable using builtins, use builtins. Either way, you're expressing the concept "keep the ones that are true".
#3 semantically is more complicated and it seems that there are no optimizations at least in cpython (but perhaps I’m wrong?). So, it looks like #3 is slower while parsing and while executing.
#3 is bad choice for code maintenance. It is always better to pass variable once. “(x for x in a if x)” contains micro code dups. Here, you put “x” three times, and then if you decide to use something else you have to edit it in three places. So #3 defeats if you want to reuse or just maintain such code.
Yeah, if that bothers you, use filter. Nothing wrong with either IMO.
And yet, I still have a little hope about original proposal. I proposed to add default value for second argument of “compress”.
So thanks for you attention anyways, and let me know if it is still has a chance to be accepted.
For it to be accepted, you have to convince people - particularly, core devs - that it's of value. At the moment, I'm unconvinced, but on the other hand, all you're proposing is a default value for a currently-mandatory argument, so the bar isn't TOO high (it's not like you're proposing to create a new language keyword or anything!). ChrisA