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

#342: Try to recover as intelligently as possible if user calls magic(). #352

Closed
wants to merge 3 commits into from
Closed

#342: Try to recover as intelligently as possible if user calls magic(). #352

wants to merge 3 commits into from

Conversation

dwf
Copy link
Contributor

@dwf dwf commented Apr 10, 2011

This was annoying me from the perspective of force-of-habit typing quit() (system install at the lab of IPython 0.8.3 (!!!!!) requires it) but in general, people typing some_magic() with automagic on and expecting results might be awfully surprised by the NameError that results.

This attempts to address the problem in the following way:

  • Check if whatever precedes the first paren in line_info.ifun is a magic, and of course is not shadowed by something in the user namespace
  • Throw out everything after the first paren, as well as the contents of line_info.the_rest (trying to sensibly convert function call syntax to magic-calling syntax in a general way doesn't seem prudent or possible)
  • Visually rewrite as ----> %some_magic so that the user has some clue that what he typed was interpreted as a magic but that the subsequent parenthesized arguments were ignored.

The result looks something like this:

In [6]: quit(5, 4, 3)
------> %quit
dwf@strafe:~$ 

Ideally then, individual magics, if they require arguments, will complain about not receiving them, and in the process demonstrate their usage with the correct %foo bar baz way of calling them.

This pull request replaces #345.

@fperez
Copy link
Member

fperez commented Apr 10, 2011

How is this pull related to #345?

@dwf
Copy link
Contributor Author

dwf commented Apr 10, 2011

How is this pull related to #345?

It replaces it and solves the problem more generally. I meant to close the old pull request and in fact clicked the button to do so but was apparently the victim of a network hiccup. The Canadian inter-tubes are still thawing out from the winter, I guess...

@fperez
Copy link
Member

fperez commented Apr 10, 2011

OK, looking at the code I think I understand better. But I'm not convinced we should add more input handling logic of this kind. Basically, I think if someone types foo(), then they mean a python call, not a magic. Granted, it may take a little bit to realize that ipython offers two overlapping systems, one for "commands" (magics) and one for pure python code, but anyone using a tool like ipython should figure that out pretty quickly.

Now, as for #342, I think we can address that one slightly differently, but I need to play with some ideas.

But I'm reluctant to add even more text input special-casing, as much of our code on that front is already fairly brittle. What do you think?

@fperez
Copy link
Member

fperez commented Apr 10, 2011

BTW, I'm on IRC (freenode, #ipython) if you want to chat live on these two for a moment... That may be more efficient.

@dwf
Copy link
Contributor Author

dwf commented Apr 10, 2011

I'm not entirely sure, either. @tk suggested that magic() ought to map to %magic for more than just %quit and %exit, and I went further with magic(...) mapping to %magic, but that last step might be too far.

I'll hop on IRC, just need to download a client on this machine. :)

@dwf
Copy link
Contributor Author

dwf commented Apr 10, 2011

After discussing it with Fernando it was decided this was overkill, and #352 will be reopened.

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

Successfully merging this pull request may close these issues.

None yet

2 participants