On Wed, Sep 15, 2021 at 4:03 AM m...@dyatkovskiy.com <m...@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 _______________________________________________ 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/ZTAAVYXCM5SPJWOJNV5N6QIJKCBTNQ5F/ Code of Conduct: http://python.org/psf/codeofconduct/
