Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

It seems to pass the Travis CI on all the python 3 versions tested, but not python 2. But in my own testing it works fine on python 2, and I haven't figured out where it's going wrong in fire.fire_import_test.FireImportTest with

AttributeError: 'module' object has no attribute 'Fire'

Hints welcome :)

CLAs look good, thanks!

Thanks for starting this.

Travis
The immediate problem is that you've added a file named fire.py, so the test that tries to "import fire" ends up importing your file as the fire module, rather than the actual fire module. Using a different file name will get around this issue.

Development workflow
Like you say, there's other work to do before merging this to master (tests, documentation, etc). I'd be open to creating a feature branch for this if you prefer to work on this over multiple separate pull requests.

Code review
From a quick glance at the script, one issue I notice is that we shouldn't be modifying sys.argv. Instead, we'll want to modify the Fire function to accept a list for argv (currently it only accepts a string for the argument 'command', not a list).
I'll also try to get a pylintrc into the repo / checked by travis to make staying stylistically consistent easier.

Thanks, @dberlin . That was my hunch for the import issue, but it makes me yet more curious about why it works in python 3.
A feature branch sounds helpful.

I changed the base to 'issue29-fire-without-edits'.

Another thing that's missing here is the ability to resolve to classes or functions within a module (tho I guess that's really just quibbling over addition or removal of an extra space)

Classes or functions within a module (tho I guess that's really just quibbling over addition or removal of an extra space).

If they're within a module (e.g. PIL.Image) then it's just a matter of using a space instead of a dot.

If we want to support builtin classes/functions (e.g. raw_input, type, etc), then we need more than just find_module.

@dbieber is the PR done or something still remains?

I am OK w/ merging this to the issue29-fire-without-edits branch. Apologies for not merging sooner.

Some things that remain before merging to master:

• Integration into setup.py
• Documentation
• Removing requirement of -f/-m flag.
• lint compliance

Thanks.

Also needed: tests! Input on good testing approaches and frameworks for command-line functionality
would be welcomed.

@nealmcb I would love to work on tests as I have recently studied them, might require some help , can I take this up?