Support case-insensitive usage of Python Fire CLIs about python-fire HOT 12 OPEN

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.

from python-fire.

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.

from python-fire.

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

from python-fire.

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.

from python-fire.

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

from python-fire.

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

from python-fire.

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?

from python-fire.

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

from python-fire.

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!

from python-fire.

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.

from python-fire.

May I take a shot at this?

from python-fire.

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

from python-fire.