Allowed to request processing of all possible values in Set #547

KOLANICH · 2021-04-22T14:32:07Z

No description provided.

coveralls · 2021-04-22T14:39:13Z

Coverage remained the same at 83.638% when pulling d6c005a on KOLANICH-libs:all_set into 0c574a9 on tomerfiliba:master.

henryiii · 2021-04-22T19:19:56Z

Needs tests, Python 2 supers (for now). Also * seems problematic (shells are likely to expand it, requiring '*' to pass it in), but that's probably okay. Does this customize the help output at all? Also, why is CSV on by default? Seems like an odd departure from Set. Maybe AllCSV should be an instance of AllSet? In fact, why not use the same method used by CSV to make these, and build it in as an option to the main Set (initially empty). Then AllSet = Set(all={"all", "*"}) and it's also easy to customize by a user.

KOLANICH · 2021-04-22T21:37:38Z

Also, why is CSV on by default? Seems like an odd departure from Set.

By definition all means all the values within a set. This implies that multiple values are expected to be passed into a single argument. But just Set with csv=False accepts only a single value. Do I understand right how an ordinary Set is meant to work?

In fact, why not use the same method used by CSV to make these, and build it in as an option to the main Set (initially empty). Then AllSet = Set(all={"all", "*"}) and it's also easy to customize by a user.

I have considered that, but it can either break existing apps (if we ship all prepopulated by default) or can cause "a zoo" (if we don't, then each dev would invent an own value for all, which would be a usability issue). Both cases are undesireable. So it is proposed for the ones needing multiple values in a set explicitly opt-in into AllSet, if they need its functionality (if they allow multiple values in it, then they almost always need it).

KOLANICH · 2021-06-21T15:57:20Z

Integrated the functionality into Set, added tests and did a bit of refactoring

henryiii · 2021-07-23T21:21:16Z

plumbum/cli/switches.py

                a list. Accepts ``True``, ``False``, or a string for the separator
-    """
+    :param all_markers: when a user inputs any value from this set, it is considered that
+                        he requested iteration over all values. By default `all_markers`


Suggested change

he requested iteration over all values. By default `all_markers`

they requested iteration over all values. By default `all_markers`

https://stallman.org/articles/genderless-pronouns.html

So, in order to have they (if one strictly wants to avoid possibility of stirring up SJ-hornets' nests), when a user inputs should become when users input.

Suggested change

he requested iteration over all values. By default `all_markers`

to be a request for iteration over all values. By default `all_markers`

(and also remove "that" from the line above)

henryiii · 2021-07-23T21:23:38Z

plumbum/cli/switches.py

        self.case_sensitive = kwargs.pop("case_sensitive", False)
+        all_markers = kwargs.pop("all_markers", None)
+        if all_markers is None:
+            all_markers = {"*", "all"} - set(values)


Suggested change

all_markers = {"*", "all"} - set(values)

all_markers = {"*"} - set(values)

Adding the English string "all" by default seems a little likely to be suprising, and possibly conflicting with potential entries. I think it would be better to default to "*" then provide an example for how to set {"*", "all"}.

For "*", as you have noticed, one has to type quotes. It is not very convenient (it is the same amount of characters, but to type a " one has to press shift, it is also a "mode switch "from letters to punctuation"), so I usually use "all".

Adding the English string "all" by default seems a little likely to be suprising

I don't think so: if one wants a string "all" in an arg of type "Set", it explicitly says that he wants all the values.

If you mean that the problem is that the string is English that "discriminates" against other languages, I think that having the universal same string for all the languages that doesn't depend on a locale outweights the possibility of mismatch between languages of other enum values and outweights the variant not having it at all. Making a language-dependent marker will cause only issues and increase cognitive load in using it. Not having a default one will cause users to invent own ones, which again will increase cognitive load of using it.

, and possibly conflicting with potential entries.

Introducing any default string can be conflicting. That's why the line to which you have left this comment exists - to avoid the conflicts automatically. If user-provided Set doesn't have all and *, then they will be used as markers for all the values. If user explicitly has opted in, then he fully controls that field and it is he is responsible for solving for possible conflicts.

henryiii · 2021-07-23T21:24:31Z

plumbum/cli/switches.py

-    """
+    :param all_markers: when a user inputs any value from this set, it is considered that
+                        he requested iteration over all values. By default `all_markers`
+                        are {"*", "all"}."""


Suggested change

are {"*", "all"}."""

are {"*"}; you can set it to {"all", "*"}, for example."""

Why do you suggest it be changed, if we resolve conflicts automatically?

Plumbum comes with built-in translations for German, French, Dutch, and Russian. Either this string needs to support translations, or it should be language agnostic. A local dependent default is poor (as you noted), so why not just use the symbol? Also, if the user uses all-caps for their options, then this will be lower case, which is weird. Why not just use "*" as the default string (exactly the same number of characters as all) and let the user decide if they like "all" or something else?

Also there's the issue of being misleading. "all" is much more likely to look like a normal option that "*" is; and it's not a normal option, it just selects all the others.

I don't think anyone else has an "all/*" like option. Does anyone else? I checked Click, doesn't seem to have this sort of select-all feature.

Does this show up in the help anywhere?

If you really want to make "all" part of the default, I'd take a tie breaker opinion. @tomerfiliba perhaps? Or any other person who has committed anything.

…ible values in a `Set`.

KOLANICH force-pushed the all_set branch from 1eb529f to 9771cca Compare June 21, 2021 15:47

KOLANICH changed the title ~~Added AllSet.~~ Allowed to request processing of all possible values in Set Jun 21, 2021

KOLANICH force-pushed the all_set branch from 9771cca to d032afa Compare June 21, 2021 15:59

henryiii reviewed Jul 23, 2021

View reviewed changes

KOLANICH force-pushed the all_set branch from d032afa to 54c8ef5 Compare August 25, 2021 16:44

KOLANICH force-pushed the all_set branch from 54c8ef5 to 799a55c Compare November 10, 2021 11:17

KOLANICH force-pushed the all_set branch from 799a55c to e946d37 Compare December 23, 2021 11:00

KOLANICH force-pushed the all_set branch from e946d37 to d6c005a Compare January 2, 2022 11:16

Added functionality to allow a user to request processing of all poss…

7a53dc3

…ible values in a `Set`.

KOLANICH force-pushed the all_set branch from d6c005a to 7a53dc3 Compare February 22, 2022 18:28

henryiii mentioned this pull request Oct 5, 2022

feat: add all_markers to Set #619

Merged

henryiii closed this in #619 Oct 5, 2022

	he requested iteration over all values. By default `all_markers`
	they requested iteration over all values. By default `all_markers`

	he requested iteration over all values. By default `all_markers`
	to be a request for iteration over all values. By default `all_markers`

	all_markers = {"*", "all"} - set(values)
	all_markers = {"*"} - set(values)

	are {"*", "all"}."""
	are {""}; you can set it to {"all", ""}, for example."""

Allowed to request processing of all possible values in Set #547

Allowed to request processing of all possible values in Set #547

Uh oh!

Conversation

KOLANICH commented Apr 22, 2021

Uh oh!

coveralls commented Apr 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

henryiii commented Apr 22, 2021

Uh oh!

KOLANICH commented Apr 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KOLANICH commented Jun 21, 2021

Uh oh!

henryiii Jul 23, 2021

Choose a reason for hiding this comment

Uh oh!

KOLANICH Jul 24, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

henryiii Nov 22, 2021

Choose a reason for hiding this comment

Uh oh!

henryiii Nov 23, 2021

Choose a reason for hiding this comment

Uh oh!

henryiii Jul 23, 2021

Choose a reason for hiding this comment

Uh oh!

KOLANICH Jul 24, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

henryiii Jul 23, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KOLANICH Nov 23, 2021

Choose a reason for hiding this comment

Uh oh!

henryiii Nov 23, 2021

Choose a reason for hiding this comment

Uh oh!

henryiii Nov 23, 2021

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

coveralls commented Apr 22, 2021 •

edited

Loading

KOLANICH commented Apr 22, 2021 •

edited

Loading

KOLANICH Jul 24, 2021 •

edited

Loading

KOLANICH Jul 24, 2021 •

edited

Loading

henryiii Jul 23, 2021 •

edited

Loading