
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.
As another argument to use “compress” was similar case I found on stackoverflow for numpy: https://stackoverflow.com/questions/5927180/how-do-i-remove-all-zero-element... So extending “compress” would be useful for math cases as well. 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 is also a good chance to work with optimized “compress” one day. #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. Paul confirmed my worries about “jin”, so it seems that it is not an option either. 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. Thanks! Stepan Dyatkovskiy.
On Sep 14, 2021, at 2:18 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Sep 14, 2021 at 11:31:43AM +0400, ml@dyatkovskiy.com wrote:
Thus I have collection of options and some of them are empty or None. In order to get rendered command line options string I use “compress” in conjunction with “join":
opts = " ".join(compress(flags, flags))
Why do you (ab)use compress for that?
I understand that `compress(flags, flags)` has the effect of filtering for non-empty flags. But that's an obfuscated way to write it. Either of these would be more understandable:
* `filter(None, flags)` # could also use bool instead of None
* `(flag for flag in flags if flag)`
especially the last, although heavy users of functional languages may prefer filter. But using compress with the same argument twice is just weird.
And also fragile. You can't use an iterator for the flags.
jin(iter(['a', 'b', '', 'c', 'd', 'e', 'f', '', 'g'])) 'a d'
I usually introduce alias for this:
def jin(a: str, sep=“ “): return sep.join(compress(a, a))
And I found that I use it quite frequently.
The signature is wrong. `flags` is a list of string options. If you pass an actual string, you expand it with spaces:
jin('abc def') 'a b c d e f'
-- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/RPY7HJ... Code of Conduct: http://python.org/psf/codeofconduct/