Skip to content

[WIP] [1140] use longest option argument again - #1149

Closed
altendky wants to merge 3 commits into
pallets:7.xfrom
altendky:1140-use_longest_option_argument_again
Closed

[WIP] [1140] use longest option argument again#1149
altendky wants to merge 3 commits into
pallets:7.xfrom
altendky:1140-use_longest_option_argument_again

Conversation

@altendky

Copy link
Copy Markdown
Contributor

@altendky

altendky commented Oct 16, 2018

Copy link
Copy Markdown
ContributorAuthor

WIP for:

  • Doc fixes
  • Changes entry
  • Apply to 7.x

Comment threadclick/types.py Outdated
def __init__(self, exists=False, file_okay=True, dir_okay=True,
writable=False, readable=True, resolve_path=False,
allow_dash=False, path_type=None):
allow_dash=False, path_type=None, converter=None):

This comment was marked as off-topic.

@altendky
altendkyforce-pushed the 1140-use_longest_option_argument_again branch from fe85a3a to 8c80220CompareOctober 17, 2018 02:23
@altendky
altendkyforce-pushed the 1140-use_longest_option_argument_again branch from ea3daba to 090f0adCompareOctober 19, 2018 17:04
@altendky
altendky changed the base branch from master to 7.xOctober 19, 2018 17:04
@altendkyaltendky changed the title [WIP] [1140] use longest option argument again[1140] use longest option argument againOct 19, 2018

@amiryalamiryal left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only feedback, other than LGTM 👍, is regarding commit messages. Maybe you could provide more context, i.e. what the change actually does and why, and possibly squash some or all of them together.

@altendkyaltendky changed the title [1140] use longest option argument again[WIP] [1140] use longest option argument againOct 23, 2018
@amiryal

Copy link
Copy Markdown

Just wanted to echo your earlier #1140 (comment) here as well:

It's kind of tempting to deprecate this 'feature' and just say 'if you have multiple of the longest type of parameter, specify the name'. Or maybe provide a marker so you don't have to repeat. Maybe '+--the-default' or somesuch? I dunno, explicit over implicit and all. This just seems like a bit of a fiddly mess with little benefit.
Sorry, make it backwards compatible but fix the situation by deprecating the implicit order-based selection.

👍
I fully agree, Zen of Python and all.

@sirosensirosen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@altendky, is this still a work in progress?

Since this is the course of action which you and @davidism agreed on, and the changes appear to be complete to me, I'd like to merge.

I agree that your commit messages are a bit minimal -- personally, I'd prefer them either squashed or fleshed out with explanation -- but all of the important discussion is in GitHub anyway.

Comment threadtests/test_options.py
(['--aggressive', '--all', '-a'], 'aggressive'),
(['--first', '--second', '--third', '-a', '-b', '-c'], 'first'),
(['--apple', '--banana', '--cantaloupe', '-a', '-b', '-c'], 'apple'),
(['--first', '--second', '--third', '-a', '-b', '-c'], 'second'),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me so dizzy to read. 😂

I understand that we're going back to documented behavior, but this is pretty much the perfect example of why I think this comment of yours is spot on. We should really just tell people to write down what they mean...

@altendky

Copy link
Copy Markdown
ContributorAuthor

After #1140 (comment) and #1140 (comment) I figured we should figure out where we are going since we have no totally obvious thing to revert to. If we want to 'just revert' for now I would think we would want the previous functionality which would be 'last long' not 'longest' like this implements.

@sirosen

Copy link
Copy Markdown
Contributor

Ah, I thought after this comment that we should revert the behavior that this reverts #794.

Reading that PR again, it looks like we switched from "last long opt" to "first long opt" but never updated the docs? I didn't realize we never had the also-documented "longest option" behavior.

Sorry for jumping in on this without properly grasping the situation.

Now that I do, I actually think this PR is probably a bad call -- we should either keep the new behavior in 7.0 and document it, or revert to pre #794 behavior and note it as a bugfix in the 7.1 changelog.

IMO, keeping the new behavior and just updating the docs is the cheapest/easiest solution. If someone showed up as a new user of 7.0, then any behavior change appears to be breaking.

@altendky

Copy link
Copy Markdown
ContributorAuthor

I only left this open to avoid thrash just in case... But yeah, this is likely just totally dead.

@github-actionsgithub-actionsBot locked as resolved and limited conversation to collaborators Nov 13, 2020
@kdeldyckekdeldycke added the parsing Parsing, parameters, commands, chaining, context label Aug 8, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

parsingParsing, parameters, commands, chaining, context

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@altendky@amiryal@sirosen@kdeldycke