Support case-insensitive usage of Python Fire CLIs

[dbieber]

Much like how we allow users to use hyphens - in place of underscores, this Issue is to allow users to use all-lowercase versions of identifiers.

Typical case

import fire
class CaseExample(object):
  def Alpha():
    return 'path 1'
fire.Fire(CaseExample)

$ python example.py Alpha  # This is the current behavior.
path 1
$ python example.py alpha  # This is the new behavior I want to add.
path 1
$ python example.py ALPHA   # Do we want to support other capitalizations? Or just the all lower-case version?
path 1

Corner cases
Unlike with the -/_ support, there can potentially be members with multiple capitalization variants of the name.

E.g.

import fire
class CaseExample(object):
  def alpha():
    return 'path 1'
  def Alpha():
    return 'path 2'

fire.Fire(CaseExample)

If the user provides an exact match, it's clear what we should do. I'm open to discussion about how to handle the ambiguous case.

$ python example.py alpha
path 1
$ python example.py Alpha
path 2
$ python example.py ALPHA
WARNING: Ambiguous member access `ALPHA`; accessing `alpha`.
path 1

Why?
The primary motivation is that command line tools typically use lower case commands, whereas Python classes (and occasionally methods/functions) typically have capital names. By allowing these capital names to be used via their lower-case variant, the CLIs that result from normal python code will feel natural more often.

Possible extension
If we also support dropping/adding -/_s in some situations, then people could use snake-case to refer to CamelCase items... just brainstorming. Thoughts?

[dbieber]

issue courtesy of @zqureshi via https://twitter.com/zeeshanq/status/838604546389733378 :)

[zqureshi]

Depending when fire inspects the objects to construct a lookup table, it could emit a warning as soon as it detects collisions. Always defaulting to lowercase with a warning seems like a reasonable default.

[zqureshi]

You could add a config flag that errors out if collision detected for people who want to be sure.

[dbieber]

I don't think we'll want to add such a flag. In the majority of cases it will be clear what to do, and we'll just want to pick a sensible way to handle the occasional ambiguity.

To be clear, the ambiguous case is only when an object has multiple members that have the same name but different capitalizations, and the end users enters a third capitalization that's different from any of the actual capitalizations. In this case, I'm leaning toward simply showing a warning and exiting rather than trying to guess (e.g. via edit distance) what the user was trying to do.

[merriam]

As a quick drive by comment, this is as much about the functionality of Python as anything else. This is a constant loss of small amounts of programming time. Specifically, that "a_class", "aclass", and "aClass" are each distinct.

I would recommend that the Fire API give a better error message, such as:

'Alpha_Dog' not found.   Did you mean 'alphaDog'?   

Meaning that a valid option matched except for case, underscores, and, possibly, spaces.

[Mark-Jung]

Hey guys, is anyone working on this issue? If not, I wanted to take a stab at it.

[dbieber]

Go for it. :)

I know there was some ambiguity in the original issue description, so here's what I think we should do. I think we should support precisely the exact match case and the all-lowercase case. If the all-lowercase case is ambiguous (and not also an exact match), then we'll show a usage error. How does that sound to you?

[Mark-Jung]

Sounds awesome. It'll be my first open source contribution so I'm a bit nervous but wish me luck! haha

[dbieber]

Welcome to the open source world!

A few notes:

• There's no rush on this, it doesn't have to make it into the next release. This could take some time to get right.
• Please try to over-communicate. Let us know what you're trying, what worked, what didn't work, any questions you have about the codebase, etc. Doing all this in the open is great, but if for some reason you want to say something not for the whole world to see, that's an option too: [email protected]

Good luck!

[Mark-Jung]

Hey, sorry I've been away for some time but I looked at this issue again today and just wanted to check up on my understanding of the code and validity of my approach for this issue.

I assumed the main code base I'll be touching will be in the core.py, specifically inside the_Fire function. The part that interested me were the if statements starting from line 400. They were either calling and adding it to the trace or adding it to the accessed property depending on the type of the component. I'm still not sure where to check for case sensitive calls but my best guess is to

1. Change the GetFileAndLine function in inspectutils.py to find the filename and line number of the component for the component even when the case is off.

2. Change the code inside the last if statement where the component is a dict. I think it should look for the member case insensitively.

I'm going to try these two things later today. I'm still learning about the codebase so if y'all find something glaringly off or think there's some better way to solve this issue, please don't hesitate to mention it! I'm very open to opinions and guidance. Hope y'all have a good day.

[vikramsubramanian]

May I take a shot at this?

[flaviaouyang]

is this issue still relevant? if so, i’d like to work on it.