close
The Wayback Machine - https://web.archive.org/web/20200611064837/https://github.com/google/python-fire/issues/238
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First-character argument flag is undocumented and behaves strangely when colliding with default options #238

Open
ntjess opened this issue Apr 1, 2020 · 1 comment

Comments

@ntjess
Copy link

@ntjess ntjess commented Apr 1, 2020

Consider the function signature:

def main(headless=False):
  # Construct GUI
  if not headless:
    widget.show()
    app.exec()

if __name__ == '__main__': fire.Fire(main)

After reading through the user guide for fire, I would expect python myFile -h to produce the help signature for this file. However, it runs the script with headless = True.

While in retrospect I suppose this makes sense, I would like some way of telling fire to disallow shortcut flags if they override user-expected options like --[i]nteractive, --[h]elp, etc. In those cases, the user can be forced to say python myFile --headless for the desired behavior.

Moreover, if my script looked like this:

def main(headless=False, hArg=True):
  # Construct GUI
  if not headless:
    widget.show()
    app.exec()

if __name__ == '__main__': fire.Fire(main)

and I ran the same line of code, fire would appropriately err out. This is also acceptable in my opinion.

More importantly, the first-character flag behavior should at the very least be documented. I read through https://github.com/google/python-fire/blob/master/docs/guide.md and couldn't find it there.

@ntjess
Copy link
Author

@ntjess ntjess commented Apr 1, 2020

This would be easy enough to fix by adding a list of fire arguments here

However, I didn't implement this fix since it would violate single source of truth (list of fire arguments defined in multiple places). If this is acceptable I can submit a pull request.

Without the hard-coded list, the next easiest option I could see is propagating list(vars(parsed_flag_args).keys()) from here through the call stack. However, this was enough of a hassle and required changing so many function signatures that I figured it would be better for a maintainer to make that decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.