Dollar formatter for ! shell calls #1020
Conversation
|
Awesome, great cleanup. Thanks! Merging now. Just a question for future reference: why do those doctests need to be skipped on py3? Eventually we'll be running fully on py3, so I want to make sure we're not setting ourselves up for a restricted test suite there. Anything we can start doing to make the doctests more py3-compatible? |
|
Good question. The The same code is covered by proper functional tests, so I decided to keep it simple and skip the doctests in Python 3. |
Dollar formatter for ! shell calls.
This uses a subclass of `FullEvalFormatter` for filling in variables in shell commands like `!echo $spam`, instead of Itpl.
I've retained the `{foo}` style standard formatting for complex expressions, so it can be picked up by the more powerful built in parser. `$foo` works for names and attribute access.
FullEvalFormatter now always outputs unicode, even if you gave it a bytes string. This avoids problems when you mix 8-bit non-ascii strings and unicode (which e.g. `StringIO.StringIO` suffers from).
Closes #822 (test was added in 31ab23f).
|
Sounds good. Once we're more fully in py3 mode we can revisit this and come up with some best practices moving forward, for now it looks like we're OK. |
Dollar formatter for ! shell calls.
This uses a subclass of `FullEvalFormatter` for filling in variables in shell commands like `!echo $spam`, instead of Itpl.
I've retained the `{foo}` style standard formatting for complex expressions, so it can be picked up by the more powerful built in parser. `$foo` works for names and attribute access.
FullEvalFormatter now always outputs unicode, even if you gave it a bytes string. This avoids problems when you mix 8-bit non-ascii strings and unicode (which e.g. `StringIO.StringIO` suffers from).
Closes ipython#822 (test was added in 31ab23f).
This uses a subclass of
FullEvalFormatterfor filling in variables in shell commands like!echo $spam, instead of Itpl. It seems to fix #822.I've retained the
{foo}style standard formatting for complex expressions, so it can be picked up by the more powerful built in parser.$fooworks for names and attribute access.FullEvalFormatter now always outputs unicode, even if you gave it a bytes string. This avoids problems when you mix 8-bit non-ascii strings and unicode (which e.g.
StringIO.StringIOsuffers from).