Re: name for a mutually inclusive relationship
On 26/02/2021 04:30, Ethan Furman wrote: >> Do you have a specific problem you're trying to solve? > > No, I just came across the concept in my browsing and > was wondering if there was a name for it. If we stick with boolean values (like radio buttons and checkboxes) then I think the name is "equality" A BResult -- 0 0 1 0 1 0 1 0 0 1 1 1 So you determine "success" by whether all inputs are equal. (Or as somebody else said "not xor") -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
Op 24/02/21 om 17:12 schreef Ethan Furman: I'm looking for a name for a group of options that, when one is specified, all of them must be specified. It seems you are looking at an equivalence. -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On Fri, Feb 26, 2021 at 3:32 PM Ethan Furman wrote: > > On 2/25/21 7:06 PM, Joe Pfeiffer wrote: > > Ethan Furman writes: > > >> Like I said, at this moment I don't have a good example, only an awareness > >> that such a thing could exist and I don't know the name for it (if it has > >> one). > >> > >> So far I have seen that there are even fewer good use-cases than I might > >> have guessed, and that no one seems to have a name for the general idea. > > > > Do you have a specific problem you're trying to solve? > > No, I just came across the concept in my browsing and was wondering if there > was a name for it. I think the most accurate name at this point is probably > "pain in the butt". ;-) > "Design flaw" is a close second. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2/25/21 7:06 PM, Joe Pfeiffer wrote: Ethan Furman writes: Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one). So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea. Do you have a specific problem you're trying to solve? No, I just came across the concept in my browsing and was wondering if there was a name for it. I think the most accurate name at this point is probably "pain in the butt". ;-) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
Ethan Furman writes: > On 2/24/21 1:54 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: >> Ethan Furman wrote: > >>> I didn't say it was a good example. ;-) Hopefully it gets the idea across. >> Ditto. ;-) >> IMO, the whole idea of "my program has two options, and the user has >> to >> specify both or neither," isn't a question of whether or not the >> argument parsing library supports it, but a question of whether or not >> it's a good API. > > Like I said, at this moment I don't have a good example, only an awareness > that such a thing could exist and I don't know the name for it (if it has > one). > > So far I have seen that there are even fewer good use-cases than I might have > guessed, and that no one seems to have a name for the general idea. Do you have a specific problem you're trying to solve? That might help us understand the question better. -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
Ethan Furman writes: > I'm looking for a name for a group of options that, when one is specified, > all of them must be specified. I don't fully understand the question (yes, I read the part I snipped). Why is this not just a single option? Or is it hierarchical or something so option 1 implies options 2 and 3, but option 2 does not imply option 1? -- https://mail.python.org/mailman/listinfo/python-list
RE: name for a mutually inclusive relationship
YAGNI? True, Chris, I never have. And if I ever did, I might not even know someone has implemented similar functionality with 86 optional function arguments that fine-tune what happens in various cases and what error messages to supply, LOL! So, I would end up re-implementing it myself. But isn't this true for so much software we discuss here. The usual mantra is that 80% of features are used maybe 20% of the time and a few are used never except maybe while testing. Realistically, it adds to bloat if a fairly well-defined object is extended to handle every possible feature that is allowed, and then some. We recently discussed the "+=" feature for an object when much of the time, it is pretty much as useful as just using the longer way of adding something to yourself. But loading a longer object description the 99% of the time when it is not used, also costs a bit. My comment was thus mostly academic and suggested realistic scenarios some people use commonly enough that might be possibly to implement to make it easier to deal with such a structure and that arguably such could also handle this edge case. No reason to think this is an important thing to add, just a category that could be doable. -Original Message- From: Python-list On Behalf Of Chris Angelico Sent: Thursday, February 25, 2021 1:14 AM To: Python Subject: Re: name for a mutually inclusive relationship On Thu, Feb 25, 2021 at 4:06 PM Avi Gross via Python-list wrote: > > Is there a more general idea here? How about asking for a control that > internally manages N items and requires exactly M of them before the > entry is accepted when you click? The case being discussed sort of > wants N out of N, or nothing. > YAGNI. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On Thu, Feb 25, 2021 at 4:06 PM Avi Gross via Python-list wrote: > > Is there a more general idea here? How about asking for a control that > internally manages N items and requires exactly M of them before the entry > is accepted when you click? The case being discussed sort of wants N out of > N, or nothing. > YAGNI. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2021-02-24 6:12 PM, Ethan Furman wrote: I'm looking for a name for a group of options that, when one is specified, all of them must be specified. For contrast, - radio buttons: a group of options where only one can be specified (mutually exclusive) - check boxes: a group of options that are independent of each other (any number of them may be specified) - ???: a group of options where, if one is specified, all must be specified (mutually inclusive) So far, I have come up with: - the Three Musketeers - clique - club - best friends - tight knit - group Is there a name out there already to describe that concept? I have something vaguely similar, but my approach is different, so I don't know if this will be helpful or not. Take an example of a hospital admission form. One of the fields is 'Sex'. If the answer is Male, then certain fields are required, if the answer is Female, certain other fields are required. There can be more than one such occurrence on the same form. A field for 'Has Insurance?' could require insurance details if True, or payment method if False. I construct a dialog for each possibility, with all the fields associated with that possibility. Initially the dialogs are hidden. When the selection is made, the appropriate dialog is shown. The controlling field can have multiple options, so rather than a check-box, it is the equivalent of a radio-button. The term I use for this arrangement is 'sub-types'. Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
RE: name for a mutually inclusive relationship
Is there a more general idea here? How about asking for a control that internally manages N items and requires exactly M of them before the entry is accepted when you click? The case being discussed sort of wants N out of N, or nothing. Example, you order a family dinner from a Restaurant and are told that for a fixed price, you must order exactly 4 items from column A and another 5 from column B. Now linking the two is a bit much but if there are ten items in column A, the only valid choices might be to not order at all or pick exactly 4. Picking your first item would be easy and picking your second and third too. Once you have 4, the setup should sort of lock so you cannot add more. But if you unclick one, you should be able to select another. To get out of the setup you either stop at exactly 4 or cancel out. The problem with the N out of N case is that it is all or none. Unclicking anything in this case may not be enough and perhaps the code should clear all other items too. Clicking on any one, should mark all of them. So not really a simple subset of the cases. And what messages does a user get as they use the control? -Original Message- From: Python-list On Behalf Of Ethan Furman Sent: Wednesday, February 24, 2021 5:14 PM To: python-list@python.org Subject: Re: name for a mutually inclusive relationship On 2/24/21 1:54 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: > Ethan Furman wrote: >> I didn't say it was a good example. ;-) Hopefully it gets the idea across. > > Ditto. ;-) > > IMO, the whole idea of "my program has two options, and the user has > to specify both or neither," isn't a question of whether or not the > argument parsing library supports it, but a question of whether or not > it's a good API. Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one). So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2021-02-24 08:12, Ethan Furman wrote: > I'm looking for a name for a group of options that, when one is > specified, all of them must be specified. [snip] > - ???: a group of options where, if one is specified, all must be > specified (mutually inclusive) [snip] > Is there a name out there already to describe that concept? For two items, the XNOR logical operator (effectively a "not (a xor b") has the desired truth-table. https://en.wikipedia.org/wiki/Xnor sometimes called a "logical biconditional" https://en.wikipedia.org/wiki/Logical_biconditional But in more human terms, the common phrase "all or nothing" seems to cover the concept pretty well. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2/24/21 1:54 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: Ethan Furman wrote: I didn't say it was a good example. ;-) Hopefully it gets the idea across. Ditto. ;-) IMO, the whole idea of "my program has two options, and the user has to specify both or neither," isn't a question of whether or not the argument parsing library supports it, but a question of whether or not it's a good API. Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one). So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2021-02-24 at 13:31:42 -0800,
Ethan Furman wrote:
> On 2/24/21 1:23 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
>
> > > entangled (none or all):
> > >
> > > image size override: height width
> >
> > IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In
> > argparse/optparse terms, a required argument with a custom type.
> >
> > (OTOH, in a GUI, it'd be two separate mandatory text fields, both
> > controlled (i.e., enabled or disabled) by one checkbox.)
>
> I didn't say it was a good example. ;-) Hopefully it gets the idea across.
Ditto. ;-)
IMO, the whole idea of "my program has two options, and the user has to
specify both or neither," isn't a question of whether or not the
argument parsing library supports it, but a question of whether or not
it's a good API.
Is the following a good API for a function?
def override_image_size(image, height=0, width=0):
'''specify height and width, or set both to 0'''
if (height == 0 and width != 0) or (height != 0 and width == 0):
raise ArgumentError('both or neither')
if height != 0 and width != 0:
image.height = height
image.width = width
Or would you more likely write something like this:
def override_image_size(image, size):
'''size is a (height, width) tuple'''
image.height, image.width = size
So why is the former a good API for a command line utility?
Or maybe I don't write command line utilitis with sufficiently complex
argument structures.
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2/24/21 1:23 PM, 2qdxy4rzwzuui...@potatochowder.com wrote: entangled (none or all): image size override: height width IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In argparse/optparse terms, a required argument with a custom type. (OTOH, in a GUI, it'd be two separate mandatory text fields, both controlled (i.e., enabled or disabled) by one checkbox.) I didn't say it was a good example. ;-) Hopefully it gets the idea across. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2021-02-24 at 13:05:05 -0800, Ethan Furman wrote: > entangled (none or all): > >image size override: height width IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In argparse/optparse terms, a required argument with a custom type. (OTOH, in a GUI, it'd be two separate mandatory text fields, both controlled (i.e., enabled or disabled) by one checkbox.) -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2/24/21 12:40 PM, Alan Gauld via Python-list wrote: On 24/02/2021 16:12, Ethan Furman wrote: I'm looking for a name for a group of options that, when one is specified, all of them must be specified. For contrast, - radio buttons: a group of options where only one can be specified (mutually exclusive) - check boxes: a group of options that are independent of each other (any number of them may be specified) - ???: a group of options where, if one is specified, all must be specified (mutually inclusive) Given that radio buttons and check boxes are all effectively using boolean states, doesn't this mean none of the group or all of the group? In which case it's a single boolean value - a check box that controls all options. I suspect I'm missing something... radio buttons (none or one): t-shirt size: Small Medium Large check boxes (none or one or several or all): sandwich toppings: lettuce tomato onion cheese entangled (none or all): image size override: height width -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2/24/21 8:28 AM, 2qdxy4rzwzuui...@potatochowder.com wrote: Entangled? Hey, I like that one! ;-) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 24/02/2021 16:12, Ethan Furman wrote: > I'm looking for a name for a group of options that, when one is specified, > all of them must be specified. > > For contrast, > > - radio buttons: a group of options where only one can be specified (mutually > exclusive) > - check boxes: a group of options that are independent of each other (any > number of > them may be specified) > > - ???: a group of options where, if one is specified, all must be specified > (mutually > inclusive) Given that radio buttons and check boxes are all effectively using boolean states, doesn't this mean none of the group or all of the group? In which case it's a single boolean value - a check box that controls all options. I suspect I'm missing something... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
Hi ! In case you didn't though about that, in argparse, MutuallyExclusiveGroup is used for the mutually exclusive logic. You may use the same nomenclature, which happens to be IMHO much clearer than the one you came up with. In GUIs, i guess that such an option would be implemented by a checkbox that, when checked, enables the widgets associated to all the mutually inclusive options. Best regards, --lucas On 24/02/2021 17:12, Ethan Furman wrote: I'm looking for a name for a group of options that, when one is specified, all of them must be specified. For contrast, - radio buttons: a group of options where only one can be specified (mutually exclusive) - check boxes: a group of options that are independent of each other (any number of them may be specified) - ???: a group of options where, if one is specified, all must be specified (mutually inclusive) So far, I have come up with: - the Three Musketeers - clique - club - best friends - tight knit - group Is there a name out there already to describe that concept? -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship
On 2021-02-24 at 08:12:58 -0800, Ethan Furman wrote: > I'm looking for a name for a group of options that, when one is specified, > all of them must be specified. > > For contrast, > > - radio buttons: a group of options where only one can be specified (mutually > exclusive) > - check boxes: a group of options that are independent of each other (any > number of > them may be specified) > > - ???: a group of options where, if one is specified, all must be specified > (mutually >inclusive) I've run across this before, and almost always end up incorporating one option or the other. For example, consider a program's output. By default, it goes to stdout, but the program also supports plain output, logging, and syslog. So instead of mutually inclusive (for lack of a better phrase right now) options: --output-disposition [logging|syslog|flatfile] --output-options [depends on --output-disposition] do this: --output-to-log logging-options --output-to-syslog syslog-options --output-to-plain-file plain-file-options aka three mutually *exclusive* options. > So far, I have come up with: > > - the Three Musketeers > - clique > - club > - best friends > - tight knit > - group > > Is there a name out there already to describe that concept? Codependent? Circularly dependent? Entangled? -- https://mail.python.org/mailman/listinfo/python-list
