typos

IPython/core/inputtransformer2.py

@@ -1,638 +1,637 b''
 """Input transformer machinery to support IPython special syntax.
 
 This includes the machinery to recognise and transform ``%magic`` commands,
 ``!system`` commands, ``help?`` querying, prompt stripping, and so forth.
 
 Added: IPython 7.0. Replaces inputsplitter and inputtransformer which were
 deprecated in 7.0.
 """
 
 # Copyright (c) IPython Development Team.
 # Distributed under the terms of the Modified BSD License.
 
 from codeop import compile_command
 import re
 import tokenize
 from typing import List, Tuple
 import warnings
 
 _indent_re = re.compile(r'^[ \t]+')
 
 def leading_indent(lines):
     """Remove leading indentation.
     
     If the first line starts with a spaces or tabs, the same whitespace will be
     removed from each following line in the cell.
     """
     m = _indent_re.match(lines[0])
     if not m:
         return lines
     space = m.group(0)
     n = len(space)
     return [l[n:] if l.startswith(space) else l
             for l in lines]
 
 class PromptStripper:
     """Remove matching input prompts from a block of input.
     
     Parameters
     ----------
     prompt_re : regular expression
         A regular expression matching any input prompt (including continuation,
         e.g. ``...``)
     initial_re : regular expression, optional
         A regular expression matching only the initial prompt, but not continuation.
         If no initial expression is given, prompt_re will be used everywhere.
         Used mainly for plain Python prompts (``>>>``), where the continuation prompt
         ``...`` is a valid Python expression in Python 3, so shouldn't be stripped.
     
     If initial_re and prompt_re differ,
     only initial_re will be tested against the first line.
     If any prompt is found on the first two lines,
     prompts will be stripped from the rest of the block.
     """
     def __init__(self, prompt_re, initial_re=None):
         self.prompt_re = prompt_re
         self.initial_re = initial_re or prompt_re
 
     def _strip(self, lines):
         return [self.prompt_re.sub('', l, count=1) for l in lines]
 
     def __call__(self, lines):
         if self.initial_re.match(lines[0]) or \
                 (len(lines) > 1 and self.prompt_re.match(lines[1])):
             return self._strip(lines)
         return lines
 
 classic_prompt = PromptStripper(
     prompt_re=re.compile(r'^(>>>|\.\.\.)( |$)'),
     initial_re=re.compile(r'^>>>( |$)')
 )
 
 ipython_prompt = PromptStripper(re.compile(r'^(In \[\d+\]: |\s*\.{3,}: ?)'))
 
 def cell_magic(lines):
     if not lines[0].startswith('%%'):
         return lines
     if re.match('%%\w+\?', lines[0]):
         # This case will be handled by help_end
         return lines
     magic_name, _, first_line = lines[0][2:-1].partition(' ')
     body = ''.join(lines[1:])
     return ['get_ipython().run_cell_magic(%r, %r, %r)\n'
             % (magic_name, first_line, body)]
 
 
 def _find_assign_op(token_line):
     """Get the index of the first assignment in the line ('=' not inside brackets)
 
     Note: We don't try to support multiple special assignment (a = b = %foo)
     """
     paren_level = 0
     for i, ti in enumerate(token_line):
         s = ti.string
         if s == '=' and paren_level == 0:
             return i 
         if s in '([{':
             paren_level += 1
         elif s in ')]}':
             if paren_level > 0:
                 paren_level -= 1
 
 def find_end_of_continued_line(lines, start_line: int):
     """Find the last line of a line explicitly extended using backslashes.
 
     Uses 0-indexed line numbers.
     """
     end_line = start_line
     while lines[end_line].endswith('\\\n'):
         end_line += 1
         if end_line >= len(lines):
             break
     return end_line
 
 def assemble_continued_line(lines, start: Tuple[int, int], end_line: int):
     """Assemble a single line from multiple continued line pieces 
 
     Continued lines are lines ending in ``\``, and the line following the last
     ``\`` in the block.
 
     For example, this code continues over multiple lines::
 
         if (assign_ix is not None) \
              and (len(line) >= assign_ix + 2) \
              and (line[assign_ix+1].string == '%') \
              and (line[assign_ix+2].type == tokenize.NAME):
 
     This statement contains four continued line pieces.
     Assembling these pieces into a single line would give::
 
         if (assign_ix is not None) and (len(line) >= assign_ix + 2) and (line[...
 
     This uses 0-indexed line numbers. *start* is (lineno, colno).
 
     Used to allow ``%magic`` and ``!system`` commands to be continued over
     multiple lines.
     """
     parts = [lines[start[0]][start[1]:]] + lines[start[0]+1:end_line+1]
     return ' '.join([p[:-2] for p in parts[:-1]]  # Strip backslash+newline
                     + [parts[-1][:-1]])         # Strip newline from last line
 
 class TokenTransformBase:
     """Base class for transformations which examine tokens.
 
     Special syntax should not be transformed when it occurs inside strings or
     comments. This is hard to reliably avoid with regexes. The solution is to
     tokenise the code as Python, and recognise the special syntax in the tokens.
 
     IPython's special syntax is not valid Python syntax, so tokenising may go
     wrong after the special syntax starts. These classes therefore find and
     transform *one* instance of special syntax at a time into regular Python
     syntax. After each transformation, tokens are regenerated to find the next
     piece of special syntax.
 
     Subclasses need to implement one class method (find)
     and one regular method (transform).
 
     The priority attribute can select which transformation to apply if multiple
     transformers match in the same place. Lower numbers have higher priority.
     This allows "%magic?" to be turned into a help call rather than a magic call.
     """
     # Lower numbers -> higher priority (for matches in the same location)
     priority = 10
 
     def sortby(self):
         return self.start_line, self.start_col, self.priority
 
     def __init__(self, start):
         self.start_line = start[0] - 1   # Shift from 1-index to 0-index
         self.start_col = start[1]
 
     @classmethod
     def find(cls, tokens_by_line):
         """Find one instance of special syntax in the provided tokens.
 
         Tokens are grouped into logical lines for convenience,
         so it is easy to e.g. look at the first token of each line.
         *tokens_by_line* is a list of lists of tokenize.TokenInfo objects.
 
         This should return an instance of its class, pointing to the start
         position it has found, or None if it found no match.
         """
         raise NotImplementedError
 
     def transform(self, lines: List[str]):
         """Transform one instance of special syntax found by ``find()``
 
         Takes a list of strings representing physical lines,
         returns a similar list of transformed lines.
         """
         raise NotImplementedError
 
 class MagicAssign(TokenTransformBase):
     """Transformer for assignments from magics (a = %foo)"""
     @classmethod
     def find(cls, tokens_by_line):
         """Find the first magic assignment (a = %foo) in the cell.
         """
         for line in tokens_by_line:
             assign_ix = _find_assign_op(line)
             if (assign_ix is not None) \
                     and (len(line) >= assign_ix + 2) \
                     and (line[assign_ix+1].string == '%') \
                     and (line[assign_ix+2].type == tokenize.NAME):
                 return cls(line[assign_ix+1].start)
     
     def transform(self, lines: List[str]):
         """Transform a magic assignment found by the ``find()`` classmethod.
         """
         start_line, start_col = self.start_line, self.start_col
         lhs = lines[start_line][:start_col]
         end_line = find_end_of_continued_line(lines, start_line)
         rhs = assemble_continued_line(lines, (start_line, start_col), end_line)
         assert rhs.startswith('%'), rhs
         magic_name, _, args = rhs[1:].partition(' ')
         
         lines_before = lines[:start_line]
         call = "get_ipython().run_line_magic({!r}, {!r})".format(magic_name, args)
         new_line = lhs + call + '\n'
         lines_after = lines[end_line+1:]
         
         return lines_before + [new_line] + lines_after
 
 
 class SystemAssign(TokenTransformBase):
     """Transformer for assignments from system commands (a = !foo)"""
     @classmethod
     def find(cls, tokens_by_line):
         """Find the first system assignment (a = !foo) in the cell.
         """
         for line in tokens_by_line:
             assign_ix = _find_assign_op(line)
             if (assign_ix is not None) \
                     and (len(line) >= assign_ix + 2) \
                     and (line[assign_ix + 1].type == tokenize.ERRORTOKEN):
                 ix = assign_ix + 1
 
                 while ix < len(line) and line[ix].type == tokenize.ERRORTOKEN:
                     if line[ix].string == '!':
                         return cls(line[ix].start)
                     elif not line[ix].string.isspace():
                         break
                     ix += 1
 
     def transform(self, lines: List[str]):
         """Transform a system assignment found by the ``find()`` classmethod.
         """
         start_line, start_col = self.start_line, self.start_col
 
         lhs = lines[start_line][:start_col]
         end_line = find_end_of_continued_line(lines, start_line)
         rhs = assemble_continued_line(lines, (start_line, start_col), end_line)
         assert rhs.startswith('!'), rhs
         cmd = rhs[1:]
 
         lines_before = lines[:start_line]
         call = "get_ipython().getoutput({!r})".format(cmd)
         new_line = lhs + call + '\n'
         lines_after = lines[end_line + 1:]
 
         return lines_before + [new_line] + lines_after
 
 # The escape sequences that define the syntax transformations IPython will
 # apply to user input.  These can NOT be just changed here: many regular
 # expressions and other parts of the code may use their hardcoded values, and
 # for all intents and purposes they constitute the 'IPython syntax', so they
 # should be considered fixed.
 
 ESC_SHELL  = '!'     # Send line to underlying system shell
 ESC_SH_CAP = '!!'    # Send line to system shell and capture output
 ESC_HELP   = '?'     # Find information about object
 ESC_HELP2  = '??'    # Find extra-detailed information about object
 ESC_MAGIC  = '%'     # Call magic function
 ESC_MAGIC2 = '%%'    # Call cell-magic function
 ESC_QUOTE  = ','     # Split args on whitespace, quote each as string and call
 ESC_QUOTE2 = ';'     # Quote all args as a single string, call
 ESC_PAREN  = '/'     # Call first argument with rest of line as arguments
 
 ESCAPE_SINGLES = {'!', '?', '%', ',', ';', '/'}
 ESCAPE_DOUBLES = {'!!', '??'}  # %% (cell magic) is handled separately
 
 def _make_help_call(target, esc, next_input=None):
     """Prepares a pinfo(2)/psearch call from a target name and the escape
     (i.e. ? or ??)"""
     method  = 'pinfo2' if esc == '??' \
                 else 'psearch' if '*' in target \
                 else 'pinfo'
     arg = " ".join([method, target])
     #Prepare arguments for get_ipython().run_line_magic(magic_name, magic_args)
     t_magic_name, _, t_magic_arg_s = arg.partition(' ')
     t_magic_name = t_magic_name.lstrip(ESC_MAGIC)
     if next_input is None:
         return 'get_ipython().run_line_magic(%r, %r)' % (t_magic_name, t_magic_arg_s)
     else:
         return 'get_ipython().set_next_input(%r);get_ipython().run_line_magic(%r, %r)' % \
            (next_input, t_magic_name, t_magic_arg_s)
 
 def _tr_help(content):
     """Translate lines escaped with: ?
 
     A naked help line should fire the intro help screen (shell.show_usage())
     """
     if not content:
         return 'get_ipython().show_usage()'
 
     return _make_help_call(content, '?')
 
 def _tr_help2(content):
     """Translate lines escaped with: ??
 
     A naked help line should fire the intro help screen (shell.show_usage())
     """
     if not content:
         return 'get_ipython().show_usage()'
 
     return _make_help_call(content, '??')
 
 def _tr_magic(content):
     "Translate lines escaped with a percent sign: %"
     name, _, args = content.partition(' ')
     return 'get_ipython().run_line_magic(%r, %r)' % (name, args)
 
 def _tr_quote(content):
     "Translate lines escaped with a comma: ,"
     name, _, args = content.partition(' ')
     return '%s("%s")' % (name, '", "'.join(args.split()) )
 
 def _tr_quote2(content):
     "Translate lines escaped with a semicolon: ;"
     name, _, args = content.partition(' ')
     return '%s("%s")' % (name, args)
 
 def _tr_paren(content):
     "Translate lines escaped with a slash: /"
     name, _, args = content.partition(' ')
     return '%s(%s)' % (name, ", ".join(args.split()))
 
 tr = { ESC_SHELL  : 'get_ipython().system({!r})'.format,
        ESC_SH_CAP : 'get_ipython().getoutput({!r})'.format,
        ESC_HELP   : _tr_help,
        ESC_HELP2  : _tr_help2,
        ESC_MAGIC  : _tr_magic,
        ESC_QUOTE  : _tr_quote,
        ESC_QUOTE2 : _tr_quote2,
        ESC_PAREN  : _tr_paren }
 
 class EscapedCommand(TokenTransformBase):
     """Transformer for escaped commands like %foo, !foo, or /foo"""
     @classmethod
     def find(cls, tokens_by_line):
         """Find the first escaped command (%foo, !foo, etc.) in the cell.
         """
         for line in tokens_by_line:
             ix = 0
             while line[ix].type in {tokenize.INDENT, tokenize.DEDENT}:
                 ix += 1
             if line[ix].string in ESCAPE_SINGLES:
                 return cls(line[ix].start)
 
     def transform(self, lines):
         """Transform an escaped line found by the ``find()`` classmethod.
         """
         start_line, start_col = self.start_line, self.start_col
 
         indent = lines[start_line][:start_col]
         end_line = find_end_of_continued_line(lines, start_line)
         line = assemble_continued_line(lines, (start_line, start_col), end_line)
 
         if line[:2] in ESCAPE_DOUBLES:
             escape, content = line[:2], line[2:]
         else:
             escape, content = line[:1], line[1:]
         call = tr[escape](content)
 
         lines_before = lines[:start_line]
         new_line = indent + call + '\n'
         lines_after = lines[end_line + 1:]
 
         return lines_before + [new_line] + lines_after
 
 _help_end_re = re.compile(r"""(%{0,2}
                               [a-zA-Z_*][\w*]*        # Variable name
                               (\.[a-zA-Z_*][\w*]*)*   # .etc.etc
                               )
                               (\?\??)$                # ? or ??
                               """,
                               re.VERBOSE)
 
 class HelpEnd(TokenTransformBase):
     """Transformer for help syntax: obj? and obj??"""
     # This needs to be higher priority (lower number) than EscapedCommand so
     # that inspecting magics (%foo?) works.
     priority = 5
 
     def __init__(self, start, q_locn):
         super().__init__(start)
         self.q_line = q_locn[0] - 1  # Shift from 1-indexed to 0-indexed
         self.q_col = q_locn[1]
 
     @classmethod
     def find(cls, tokens_by_line):
         """Find the first help command (foo?) in the cell.
         """
         for line in tokens_by_line:
             # Last token is NEWLINE; look at last but one
             if len(line) > 2 and line[-2].string == '?':
                 # Find the first token that's not INDENT/DEDENT
                 ix = 0
                 while line[ix].type in {tokenize.INDENT, tokenize.DEDENT}:
                     ix += 1
                 return cls(line[ix].start, line[-2].start)
 
     def transform(self, lines):
         """Transform a help command found by the ``find()`` classmethod.
         """
         piece = ''.join(lines[self.start_line:self.q_line+1])
         indent, content = piece[:self.start_col], piece[self.start_col:]
         lines_before = lines[:self.start_line]
         lines_after = lines[self.q_line + 1:]
 
         m = _help_end_re.search(content)
         assert m is not None, content
         target = m.group(1)
         esc = m.group(3)
 
         # If we're mid-command, put it back on the next prompt for the user.
         next_input = None
         if (not lines_before) and (not lines_after) \
                 and content.strip() != m.group(0):
             next_input = content.rstrip('?\n')
 
         call = _make_help_call(target, esc, next_input=next_input)
         new_line = indent + call + '\n'
 
         return lines_before + [new_line] + lines_after
 
 def make_tokens_by_line(lines):
     """Tokenize a series of lines and group tokens by line.
 
     The tokens for a multiline Python string or expression are
     grouped as one line.
     """
     # NL tokens are used inside multiline expressions, but also after blank
     # lines or comments. This is intentional - see https://bugs.python.org/issue17061
     # We want to group the former case together but split the latter, so we
     # track parentheses level, similar to the internals of tokenize.
     NEWLINE, NL = tokenize.NEWLINE, tokenize.NL
     tokens_by_line = [[]]
     parenlev = 0
     try:
         for token in tokenize.generate_tokens(iter(lines).__next__):
             tokens_by_line[-1].append(token)
             if (token.type == NEWLINE) \
                     or ((token.type == NL) and (parenlev <= 0)):
                 tokens_by_line.append([])
             elif token.string in {'(', '[', '{'}:
                 parenlev += 1
             elif token.string in {')', ']', '}'}:
                 if parenlev > 0:
                     parenlev -= 1
     except tokenize.TokenError:
         # Input ended in a multiline string or expression. That's OK for us.
         pass
     
     return tokens_by_line
 
 def show_linewise_tokens(s: str):
     """For investigation and debugging"""
     if not s.endswith('\n'):
         s += '\n'
     lines = s.splitlines(keepends=True)
     for line in make_tokens_by_line(lines):
         print("Line -------")
         for tokinfo in line:
             print(" ", tokinfo)
 
 # Arbitrary limit to prevent getting stuck in infinite loops
 TRANSFORM_LOOP_LIMIT = 500
 
 class TransformerManager:
     """Applies various transformations to a cell or code block.
 
     The key methods for external use are ``transform_cell()``
     and ``check_complete()``.
     """
     def __init__(self):
         self.cleanup_transforms = [
             leading_indent,
             classic_prompt,
             ipython_prompt,
         ]
         self.line_transforms = [
             cell_magic,
         ]
         self.token_transformers = [
             MagicAssign,
             SystemAssign,
             EscapedCommand,
             HelpEnd,
         ]
     
     def do_one_token_transform(self, lines):
         """Find and run the transform earliest in the code.
         
         Returns (changed, lines).
         
         This method is called repeatedly until changed is False, indicating
         that all available transformations are complete.
 
         The tokens following IPython special syntax might not be valid, so
         the transformed code is retokenised every time to identify the next
         piece of special syntax. Hopefully long code cells are mostly valid
         Python, not using lots of IPython special syntax, so this shouldn't be
         a performance issue.
         """
         tokens_by_line = make_tokens_by_line(lines)
         candidates = []
         for transformer_cls in self.token_transformers:
             transformer = transformer_cls.find(tokens_by_line)
             if transformer:
                 candidates.append(transformer)
 
         if not candidates:
             # Nothing to transform
             return False, lines
 
         transformer = min(candidates, key=TokenTransformBase.sortby)
         return True, transformer.transform(lines)
 
     def do_token_transforms(self, lines):
         for _ in range(TRANSFORM_LOOP_LIMIT):
             changed, lines = self.do_one_token_transform(lines)
             if not changed:
                 return lines
 
         raise RuntimeError("Input transformation still changing after "
                            "%d iterations. Aborting." % TRANSFORM_LOOP_LIMIT)
 
     def transform_cell(self, cell: str) -> str:
         """Transforms a cell of input code"""
         if not cell.endswith('\n'):
             cell += '\n'  # Ensure the cell has a trailing newline
         lines = cell.splitlines(keepends=True)
         for transform in self.cleanup_transforms + self.line_transforms:
-            #print(transform, lines)
             lines = transform(lines)
 
         lines = self.do_token_transforms(lines)
         return ''.join(lines)
 
     def check_complete(self, cell: str):
         """Return whether a block of code is ready to execute, or should be continued
 
         Parameters
         ----------
         source : string
           Python input code, which can be multiline.
 
         Returns
         -------
         status : str
           One of 'complete', 'incomplete', or 'invalid' if source is not a
           prefix of valid code.
         indent_spaces : int or None
           The number of spaces by which to indent the next line of code. If
           status is not 'incomplete', this is None.
         """
         if not cell.endswith('\n'):
             cell += '\n'  # Ensure the cell has a trailing newline
         lines = cell.splitlines(keepends=True)
         if lines[-1][:-1].endswith('\\'):
             # Explicit backslash continuation
             return 'incomplete', find_last_indent(lines)
 
         try:
             for transform in self.cleanup_transforms:
                 lines = transform(lines)
         except SyntaxError:
             return 'invalid', None
 
         if lines[0].startswith('%%'):
             # Special case for cell magics - completion marked by blank line
             if lines[-1].strip():
                 return 'incomplete', find_last_indent(lines)
             else:
                 return 'complete', None
 
         try:
             for transform in self.line_transforms:
                 lines = transform(lines)
             lines = self.do_token_transforms(lines)
         except SyntaxError:
             return 'invalid', None
 
         tokens_by_line = make_tokens_by_line(lines)
         if tokens_by_line[-1][-1].type != tokenize.ENDMARKER:
             # We're in a multiline string or expression
             return 'incomplete', find_last_indent(lines)
 
         # Find the last token on the previous line that's not NEWLINE or COMMENT
         toks_last_line = tokens_by_line[-2]
         ix = len(toks_last_line) - 1
         while ix >= 0 and toks_last_line[ix].type in {tokenize.NEWLINE,
                                                       tokenize.COMMENT}:
             ix -= 1
 
         if toks_last_line[ix].string == ':':
             # The last line starts a block (e.g. 'if foo:')
             ix = 0
             while toks_last_line[ix].type in {tokenize.INDENT, tokenize.DEDENT}:
                 ix += 1
             indent = toks_last_line[ix].start[1]
             return 'incomplete', indent + 4
 
         # If there's a blank line at the end, assume we're ready to execute.
         if not lines[-1].strip():
             return 'complete', None
 
         # At this point, our checks think the code is complete (or invalid).
         # We'll use codeop.compile_command to check this with the real parser.
 
         try:
             with warnings.catch_warnings():
                 warnings.simplefilter('error', SyntaxWarning)
                 res = compile_command(''.join(lines), symbol='exec')
         except (SyntaxError, OverflowError, ValueError, TypeError,
                 MemoryError, SyntaxWarning):
             return 'invalid', None
         else:
             if res is None:
                 return 'incomplete', find_last_indent(lines)
         return 'complete', None
 
 
 def find_last_indent(lines):
     m = _indent_re.match(lines[-1])
     if not m:
         return 0
     return len(m.group(0).replace('\t', ' '*4))

docs/source/interactive/autoawait.rst

@@ -1,222 +1,222 b''
 .. _autoawait:
 
 Asynchronous in REPL: Autoawait
 ===============================
 
 .. note::
 
-   This feature is experimental and behavior can change betwen python and
+   This feature is experimental and behavior can change between python and
    IPython version without prior deprecation.
 
 Starting with IPython 7.0, and when user Python 3.6 and above, IPython offer the
 ability to run asynchronous code from the REPL. Constructs which are
 :exc:`SyntaxError` s in the Python REPL can be used seamlessly in IPython.
 
 The example given here are for terminal IPython, running async code in a
 notebook interface or any other frontend using the Jupyter protocol will need to
 use a newer version of IPykernel. The details of how async code runs in
 IPykernel will differ between IPython, IPykernel and their versions.
 
 When a supported library is used, IPython will automatically allow Futures and
 Coroutines in the REPL to be ``await`` ed. This will happen if an :ref:`await
 <await>` (or any other async constructs like async-with, async-for) is use at
 top level scope, or if any structure valid only in `async def
 <https://docs.python.org/3/reference/compound_stmts.html#async-def>`_ function
 context are present. For example, the following being a syntax error in the
 Python REPL::
 
     Python 3.6.0 
     [GCC 4.2.1]
     Type "help", "copyright", "credits" or "license" for more information.
     >>> import aiohttp
     >>> result = aiohttp.get('https://api.github.com')
     >>> response = await result
       File "<stdin>", line 1
         response = await result
                               ^
     SyntaxError: invalid syntax
 
 Should behave as expected in the IPython REPL::
 
     Python 3.6.0
     Type 'copyright', 'credits' or 'license' for more information
     IPython 7.0.0 -- An enhanced Interactive Python. Type '?' for help.
 
     In [1]: import aiohttp
        ...: result = aiohttp.get('https://api.github.com')
 
     In [2]: response = await result
     <pause for a few 100s ms>
 
     In [3]: await response.json()
     Out[3]:
     {'authorizations_url': 'https://api.github.com/authorizations',
      'code_search_url': 'https://api.github.com/search/code?q={query}...',
     ...
     }
 
 
 You can use the ``c.InteractiveShell.autoawait`` configuration option and set it
 to :any:`False` to deactivate automatic wrapping of asynchronous code. You can also
 use the :magic:`%autoawait` magic to toggle the behavior at runtime::
 
     In [1]: %autoawait False
 
     In [2]: %autoawait
     IPython autoawait is `Off`, and set to use `asyncio`
 
 
 
 By default IPython will assume integration with Python's provided
 :mod:`asyncio`, but integration with other libraries is provided. In particular
 we provide experimental integration with the ``curio`` and ``trio`` library.
 
 You can switch current integration by using the
 ``c.InteractiveShell.loop_runner`` option or the ``autoawait <name
 integration>`` magic.
 
 For example::
 
     In [1]: %autoawait trio
 
     In [2]: import trio
 
     In [3]: async def child(i):
        ...:     print("   child %s goes to sleep"%i)
        ...:     await trio.sleep(2)
        ...:     print("   child %s wakes up"%i)
 
     In [4]: print('parent start')
        ...: async with trio.open_nursery() as n:
        ...:     for i in range(5):
        ...:         n.spawn(child, i)
        ...: print('parent end')
     parent start
        child 2 goes to sleep
        child 0 goes to sleep
        child 3 goes to sleep
        child 1 goes to sleep
        child 4 goes to sleep
        <about 2 seconds pause>
        child 2 wakes up
        child 1 wakes up
        child 0 wakes up
        child 3 wakes up
        child 4 wakes up
     parent end
 
 
 In the above example, ``async with`` at top level scope is a syntax error in
 Python.
 
 Using this mode can have unexpected consequences if used in interaction with
 other features of IPython and various registered extensions. In particular if you
 are a direct or indirect user of the AST transformers, these may not apply to
 your code.
 
 When using command line IPython, the default loop (or runner) does not process
 in the background, so top level asynchronous code must finish for the REPL to
 allow you to enter more code. As with usual Python semantic, the awaitables are
 started only when awaited for the first time. That is to say, in first example,
 no network request is done between ``In[1]`` and ``In[2]``.
 
 
 Effects on IPython.embed()
 ==========================
 
 IPython core being asynchronous, the use of ``IPython.embed()`` will now require
 a loop to run. By default IPython will use a fake coroutine runner which should
 allow ``IPython.embed()`` to be nested. Though this will prevent usage of the
 ``autoawait`` feature when using IPython embed. 
 
 You can set explicitly a coroutine runner for ``embed()`` if you desire to run
 asynchronous code, the exact behavior is though undefined.
 
 Effects on Magics
 =================
 
 A couple of magics (``%%timeit``, ``%timeit``, ``%%time``, ``%%prun``) have not
 yet been updated to work with asynchronous code and will raise syntax errors
 when trying to use top-level ``await``. We welcome any contribution to help fix
 those, and extra cases we haven't caught yet. We hope for better support in Cor
 Python for top-level Async code.
 
 Internals
 =========
 
 As running asynchronous code is not supported in interactive REPL (as of Python
 3.7) we have to rely to a number of complex workaround and heuristic to allow
 this to happen. It is interesting to understand how this works in order to
 comprehend potential bugs, or provide a custom runner.
 
 Among the many approaches that are at our disposition, we find only one that
 suited out need. Under the hood we use the code object from a async-def function
 and run it in global namespace after modifying it to not create a new
 ``locals()`` scope::
 
     async def inner_async():
         locals().update(**global_namespace)
         #
         # here is user code
         #
         return last_user_statement
     codeobj = modify(inner_async.__code__)
     coroutine = eval(codeobj, user_ns)
     display(loop_runner(coroutine))
 
 
 
 The first thing you'll notice is that unlike classical ``exec``, there is only
 one namespace. Second, user code runs in a function scope, and not a module
 scope.
 
 On top of the above there are significant modification to the AST of
 ``function``, and ``loop_runner`` can be arbitrary complex. So there is a
 significant overhead to this kind of code.
 
 By default the generated coroutine function will be consumed by Asyncio's
 ``loop_runner = asyncio.get_evenloop().run_until_complete()`` method if
 ``async`` mode is deemed necessary, otherwise the coroutine will just be
 exhausted in a simple runner. It is though possible to change the default
 runner.
 
 A loop runner is a *synchronous*  function responsible from running a coroutine
 object.
 
 The runner is responsible from ensuring that ``coroutine`` run to completion,
 and should return the result of executing the coroutine. Let's write a
 runner for ``trio`` that print a message when used as an exercise, ``trio`` is
 special as it usually prefer to run a function object and make a coroutine by
 itself, we can get around this limitation by wrapping it in an async-def without
 parameters and passing this value to ``trio``::
 
 
     In [1]: import trio
        ...: from types import CoroutineType
        ...:
        ...: def trio_runner(coro:CoroutineType):
        ...:     print('running asynchronous code')
        ...:     async def corowrap(coro):
        ...:         return await coro
        ...:     return trio.run(corowrap, coro)
 
 We can set it up by passing it to ``%autoawait``::
 
     In [2]: %autoawait trio_runner
 
     In [3]: async def async_hello(name):
        ...:     await trio.sleep(1)
        ...:     print(f'Hello {name} world !')
        ...:     await trio.sleep(1)
 
     In [4]: await async_hello('async')
     running asynchronous code
     Hello async world !
 
 
 Asynchronous programming in python (and in particular in the REPL) is still a
 relatively young subject. We expect some code to not behave as you expect, so
 feel free to contribute improvements to this codebase and give us feedback.
 
 We invite you to thoroughly test this feature and report any unexpected behavior
 as well as propose any improvement.

docs/source/whatsnew/index.rst

@@ -1,68 +1,68 b''
 .. Developers should add in this file, during each release cycle, information
 .. about important changes they've made, in a summary format that's meant for
 .. end users.  For each release we normally have three sections: features,  bug
 .. fixes and api breakage.
 .. Please remember to credit the authors of the contributions by name,
 .. especially when they are new users or developers who do not regularly
 .. participate  in IPython's development.
 
 .. _whatsnew_index:
 
 =====================
 What's new in IPython
 =====================
 
 ..
-    this will appear in the docs if we are nto releasing a versin (ie is
-    `_version_extra` in release.py is empty stringA
+    this will appear in the docs if we are not releasing a versin (ie is
+    `_version_extra` in release.py is empty string
 
 .. only:: ipydev
 
-   Developpement version in-progress features:
+   Development version in-progress features:
    
    .. toctree::
 
       development
 
 ..
    this make a hidden toctree that avoid sphinx to complain about documents
    included nowhere when building docs for stable
    
 .. only:: ipystable
 
    .. toctree::
       :hidden:
 
       development
 
 This section documents the changes that have been made in various versions of
 IPython. Users should consult these pages to learn about new features, bug
 fixes and backwards incompatibilities. Developers should summarize the
 development work they do here in a user friendly format.
 
 .. toctree::
    :maxdepth: 1
 
    version7
    version6
    github-stats-6
    version5
    github-stats-5
    version4
    github-stats-4
    version3
    github-stats-3
    version3_widget_migration
    version2.0
    github-stats-2.0
    version1.0
    github-stats-1.0
    version0.13
    github-stats-0.13
    version0.12
    github-stats-0.12
    version0.11
    github-stats-0.11
    version0.10
    version0.9
    version0.8

docs/source/whatsnew/version0.13.rst

@@ -1,670 +1,670 b''
 =============
  0.13 Series
 =============
 
 Release 0.13
 ============
 
 IPython 0.13 contains several major new features, as well as a large amount of
 bug and regression fixes.  The previous version (0.12) was released on December
 19 2011, and in this development cycle we had:
 
 - ~6 months of work.
 - 373 pull requests merged.
 - 742 issues closed (non-pull requests).
 - contributions from 62 authors.
 - 1760 commits.
 - a diff of 114226 lines.
 
 The amount of work included in this release is so large, that we can only cover
 here the main highlights; please see our :ref:`detailed release statistics
 <issues_list_013>` for links to every issue and pull request closed on GitHub
 as well as a full list of individual contributors.
 
 
 Major Notebook improvements: new user interface and more
 --------------------------------------------------------
 
 The IPython Notebook, which has proven since its release to be wildly popular,
 has seen a massive amount of work in this release cycle, leading to a
 significantly improved user experience as well as many new features.
 
 The first user-visible change is a reorganization of the user interface; the
 left panel has been removed and was replaced by a real menu system and a
 toolbar with icons.  Both the toolbar and the header above the menu can be
 collapsed to leave an unobstructed working area:
 
 .. image:: ../_images/ipy_013_notebook_spectrogram.png
     :width: 460px
     :alt: New user interface for Notebook
     :align: center
     :target: ../_images/ipy_013_notebook_spectrogram.png
 
 The notebook handles very long outputs much better than before (this was a
 serious usability issue when running processes that generated massive amounts
 of output).  Now, in the presence of outputs longer than ~100 lines, the
 notebook will automatically collapse to a scrollable area and the entire left
 part of this area controls the display: one click in this area will expand the
 output region completely, and a double-click will hide it completely.  This
 figure shows both the scrolled and hidden modes:
 
 .. image:: ../_images/ipy_013_notebook_long_out.png
     :width: 460px
     :alt: Scrolling and hiding of long output in the notebook.
     :align: center
     :target: ../_images/ipy_013_notebook_long_out.png
 
 .. note::
 
    The auto-folding of long outputs is disabled in Firefox due to bugs in its
    scrolling behavior.  See :ghpull:`2047` for details.
 
 Uploading notebooks to the dashboard is now easier: in addition to drag and
 drop (which can be finicky sometimes), you can now click on the upload text and
 use a regular file dialog box to select notebooks to upload. Furthermore, the
 notebook dashboard now auto-refreshes its contents and offers buttons to shut
 down any running kernels (:ghpull:`1739`):
 
 .. image:: ../_images/ipy_013_dashboard.png
     :width: 460px
     :alt: Improved dashboard
     :align: center
     :target: ../_images/ipy_013_dashboard.png
 
 
 Cluster management
 ~~~~~~~~~~~~~~~~~~
 
 The notebook dashboard can now also start and stop clusters, thanks to a new
 tab in the dashboard user interface:
 
 .. image:: ../_images/ipy_013_dashboard_cluster.png
     :width: 460px
     :alt: Cluster management from the notebook dashboard
     :align: center
     :target: ../_images/ipy_013_dashboard_cluster.png
 
 This interface allows, for each profile you have configured, to start and stop
 a cluster (and optionally override the default number of engines corresponding
 to that configuration).  While this hides all error reporting, once you have a
 configuration that you know works smoothly, it is a very convenient interface
 for controlling your parallel resources.
 
 
 New notebook format
 ~~~~~~~~~~~~~~~~~~~
 
 The notebooks saved now use version 3 of our format, which supports heading
 levels as well as the concept of 'raw' text cells that are not rendered as
 Markdown.  These will be useful with converters_ we are developing, to pass raw
 markup (say LaTeX).  That conversion code is still under heavy development and
 not quite ready for prime time, but we welcome help on this front so that we
 can merge it for full production use as soon as possible.
 
 .. _converters: https://github.com/ipython/nbconvert
 
 .. note::
 
    v3 notebooks can *not* be read by older versions of IPython, but we provide
    a `simple script`_ that you can use in case you need to export a v3
    notebook to share with a v2 user.
 
 .. _simple script: https://gist.github.com/1935808
 
 
 JavaScript refactoring
 ~~~~~~~~~~~~~~~~~~~~~~
   
 All the client-side JavaScript has been decoupled to ease reuse of parts of the
 machinery without having to build a full-blown notebook. This will make it much
 easier to communicate with an IPython kernel from existing web pages and to
 integrate single cells into other sites, without loading the full notebook
 document-like UI. :ghpull:`1711`.
     
 This refactoring also enables the possibility of writing dynamic javascript
 widgets that are returned from Python code and that present an interactive view
 to the user, with callbacks in Javascript executing calls to the Kernel.  This
 will enable many interactive elements to be added by users in notebooks.
 
 An example of this capability has been provided as a proof of concept in
 :file:`examples/widgets` that lets you directly communicate with one or more
 parallel engines, acting as a mini-console for parallel debugging and
 introspection.
 
     
 Improved tooltips
 ~~~~~~~~~~~~~~~~~
 
 The object tooltips have gained some new functionality. By pressing tab several
 times, you can expand them to see more of a docstring, keep them visible as you
 fill in a function's parameters, or transfer the information to the pager at the
 bottom of the screen. For the details, look at the example notebook
 :file:`01_notebook_introduction.ipynb`.
 
 .. figure:: ../_images/ipy_013_notebook_tooltip.png
     :width: 460px
     :alt: Improved tooltips in the notebook.
     :align: center
     :target: ../_images/ipy_013_notebook_tooltip.png
 
     The new notebook tooltips.
 
 Other improvements to the Notebook
 ----------------------------------
 
 These are some other notable small improvements to the notebook, in addition to
 many bug fixes and minor changes to add polish and robustness throughout:
 
-* The notebook pager (the area at the bottom) is now resizeable by dragging its
+* The notebook pager (the area at the bottom) is now Resizable by dragging its
   divider handle, a feature that had been requested many times by just about
   anyone who had used the notebook system.  :ghpull:`1705`.
 
 * It is now possible to open notebooks directly from the command line; for
   example: ``ipython notebook path/`` will automatically set ``path/`` as the
   notebook directory, and ``ipython notebook path/foo.ipynb`` will further
   start with the ``foo.ipynb`` notebook opened.  :ghpull:`1686`.
   
 * If a notebook directory is specified with ``--notebook-dir`` (or with the
   corresponding configuration flag ``NotebookManager.notebook_dir``), all
   kernels start in this directory.
 
 * Fix codemirror clearing of cells with ``Ctrl-Z``; :ghpull:`1965`.
   
 * Text (markdown) cells now line wrap correctly in the notebook, making them
   much easier to edit :ghpull:`1330`.
   
 * PNG and JPEG figures returned from plots can be interactively resized in the
   notebook, by dragging them from their lower left corner. :ghpull:`1832`.
 
 * Clear ``In []`` prompt numbers on "Clear All Output".  For more
   version-control-friendly ``.ipynb`` files, we now strip all prompt numbers
   when doing a "Clear all output".  This reduces the amount of noise in
   commit-to-commit diffs that would otherwise show the (highly variable) prompt
   number changes. :ghpull:`1621`.
 
 * The notebook server now requires *two* consecutive ``Ctrl-C`` within 5
   seconds (or an interactive confirmation) to terminate operation.  This makes
   it less likely that you will accidentally kill a long-running server by
   typing ``Ctrl-C`` in the wrong terminal.  :ghpull:`1609`.
 
 * Using ``Ctrl-S`` (or ``Cmd-S`` on a Mac) actually saves the notebook rather
   than providing the fairly useless browser html save dialog.  :ghpull:`1334`.
   
 * Allow accessing local files from the notebook (in urls), by serving any local
   file as the url ``files/<relativepath>``.  This makes it possible to, for
   example, embed local images in a notebook.  :ghpull:`1211`.
 
       
 Cell magics
 -----------
 
 We have completely refactored the magic system, finally moving the magic
 objects to standalone, independent objects instead of being the mixin class
 we'd had since the beginning of IPython (:ghpull:`1732`).  Now, a separate base
 class is provided in :class:`IPython.core.magic.Magics` that users can subclass
 to create their own magics.  Decorators are also provided to create magics from
 simple functions without the need for object orientation.  Please see the
 :ref:`magic` docs for further details.
 
 All builtin magics now exist in a few subclasses that group together related
 functionality, and the new :mod:`IPython.core.magics` package has been created
 to organize this into smaller files.
     
 This cleanup was the last major piece of deep refactoring needed from the
 original 2001 codebase.
     
 We have also introduced a new type of magic function, prefixed with `%%`
 instead of `%`, which operates at the whole-cell level.  A cell magic receives
 two arguments: the line it is called on (like a line magic) and the body of the
 cell below it.
     
 Cell magics are most natural in the notebook, but they also work in the
 terminal and qt console, with the usual approach of using a blank line to
 signal cell termination.
     
 For example, to time the execution of several statements::
 
     %%timeit x = 0   # setup
     for i in range(100000):
         x += i**2
 
 This is particularly useful to integrate code in another language, and cell
 magics already exist for shell scripts, Cython, R and Octave. Using ``%%script
 /usr/bin/foo``, you can run a cell in any interpreter that accepts code via
 stdin.
 
 Another handy cell magic makes it easy to write short text files: ``%%file
 ~/save/to/here.txt``.
 
 The following cell magics are now included by default; all those that use
 special interpreters (Perl, Ruby, bash, etc.) assume you have the requisite
 interpreter installed:
 
 * ``%%!``: run cell body with the underlying OS shell; this is similar to
   prefixing every line in the cell with ``!``.
   
 * ``%%bash``: run cell body under bash.
   
 * ``%%capture``: capture the output of the code in the cell (and stderr as
   well).  Useful to run codes that produce too much output that you don't even
   want scrolled.
   
 * ``%%file``: save cell body as a file.
   
 * ``%%perl``: run cell body using Perl.
   
 * ``%%prun``: run cell body with profiler (cell extension of ``%prun``).
   
 * ``%%python3``: run cell body using Python 3.
   
 * ``%%ruby``: run cell body using Ruby.
   
 * ``%%script``: run cell body with the script specified in the first line.
   
 * ``%%sh``: run cell body using sh.
   
 * ``%%sx``: run cell with system shell and capture process output (cell
   extension of ``%sx``).
   
 * ``%%system``: run cell with system shell (``%%!`` is an alias to this).
   
 * ``%%timeit``: time the execution of the cell (extension of ``%timeit``).
 
 This is what some of the script-related magics look like in action:
 
 .. image:: ../_images/ipy_013_notebook_script_cells.png
     :width: 460px
     :alt: Cluster management from the notebook dashboard
     :align: center
     :target: ../_images/ipy_013_notebook_script_cells.png
   
 In addition, we have also a number of :ref:`extensions <extensions_overview>`
 that provide specialized magics.  These typically require additional software
 to run and must be manually loaded via ``%load_ext <extension name>``, but are
 extremely useful.  The following extensions are provided:
 
 **Cython magics** (extension ``cythonmagic``)
     This extension provides magics to automatically build and compile Python
     extension modules using the Cython_ language. You must install Cython
     separately, as well as a C compiler, for this to work.  The examples
     directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
 .. image:: ../_images/ipy_013_notebook_cythonmagic.png
     :width: 460px
     :alt: Cython magic
     :align: center
     :target: ../_images/ipy_013_notebook_cythonmagic.png
 
 .. _cython: http://cython.org
 
 **Octave magics** (extension ``octavemagic``)
     This extension provides several magics that support calling code written in
     the Octave_ language for numerical computing.  You can execute single-lines
     or whole blocks of Octave code, capture both output and figures inline
     (just like matplotlib plots), and have variables automatically converted
     between the two languages.  To use this extension, you must have Octave
     installed as well as the oct2py_ package.  The examples
     directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
 .. image:: ../_images/ipy_013_notebook_octavemagic.png
     :width: 460px
     :alt: Octave magic
     :align: center
     :target: ../_images/ipy_013_notebook_octavemagic.png
 
 .. _octave: http://www.gnu.org/software/octave
 .. _oct2py: http://pypi.python.org/pypi/oct2py
 
 **R magics** (extension ``rmagic``)
     This extension provides several magics that support calling code written in
     the R_ language for statistical data analysis.  You can execute
     single-lines or whole blocks of R code, capture both output and figures
     inline (just like matplotlib plots), and have variables automatically
     converted between the two languages.  To use this extension, you must have
     R installed as well as the rpy2_ package that bridges Python and R.  The
     examples directory in the source distribution ships with a full notebook
     demonstrating these capabilities:
 
 .. image:: ../_images/ipy_013_notebook_rmagic.png
     :width: 460px
     :alt: R magic
     :align: center
     :target: ../_images/ipy_013_notebook_rmagic.png
 
 .. _R: http://www.r-project.org
 .. _rpy2: http://rpy.sourceforge.net/rpy2.html
 
 
 Tab completer improvements
 --------------------------
 
 Useful tab-completion based on live inspection of objects is one of the most
 popular features of IPython. To make this process even more user-friendly, the
 completers of both the Qt console and the Notebook have been reworked.
 
 The Qt console comes with a new ncurses-like tab completer, activated by
 default, which lets you cycle through the available completions by pressing tab,
 or select a completion with the arrow keys (:ghpull:`1851`).
 
 .. figure:: ../_images/ipy_013_qtconsole_completer.png
     :width: 460px
     :alt: ncurses-like completer, with highlighted selection.
     :align: center
     :target: ../_images/ipy_013_qtconsole_completer.png
 
     The new improved Qt console's ncurses-like completer allows to easily
     navigate thought long list of completions.
 
 In the notebook, completions are now sourced both from object introspection and
 analysis of surrounding code, so limited completions can be offered for
 variables defined in the current cell, or while the kernel is busy 
 (:ghpull:`1711`).
 
 
 We have implemented a new configurable flag to control tab completion on
 modules that provide the ``__all__`` attribute::
 
   IPCompleter.limit_to__all__= Boolean
 
 This instructs the completer to honor ``__all__`` for the completion.
 Specifically, when completing on ``object.<tab>``, if True: only those names
 in ``obj.__all__`` will be included.  When False [default]: the ``__all__``
 attribute is ignored. :ghpull:`1529`.
 
 
 Improvements to the Qt console
 ------------------------------
 
 The Qt console continues to receive improvements and refinements, despite the
 fact that it is by now a fairly mature and robust component.  Lots of small
 polish has gone into it, here are a few highlights:
 
 * A number of changes were made to the underlying code for easier integration
   into other projects such as Spyder_ (:ghpull:`2007`, :ghpull:`2024`).
 
 * Improved menus with a new Magic menu that is organized by magic groups (this
   was made possible by the reorganization of the magic system
   internals). :ghpull:`1782`.
 
 * Allow for restarting kernels without clearing the qtconsole, while leaving a
   visible indication that the kernel has restarted. :ghpull:`1681`.
   
 * Allow the native display of jpeg images in the qtconsole. :ghpull:`1643`.
 
 .. _spyder: https://code.google.com/p/spyderlib
 
 
   
 Parallel
 --------
 
 The parallel tools have been improved and fine-tuned on multiple fronts.  Now,
 the creation of an :class:`IPython.parallel.Client` object automatically
 activates a line and cell magic function ``px`` that sends its code to all the
 engines. Further magics can be easily created with the :meth:`.Client.activate`
 method, to conveniently execute code on any subset of engines. :ghpull:`1893`.
 
 The ``%%px`` cell magic can also be given an optional targets argument, as well
 as a ``--out`` argument for storing its output.
 
 A new magic has also been added, ``%pxconfig``, that lets you configure various
 defaults of the parallel magics.  As usual, type  ``%pxconfig?`` for details.
 
 The exception reporting in parallel contexts has been improved to be easier to
 read.  Now, IPython directly reports the remote exceptions without showing any
 of the internal execution parts:
 
 .. image::  ../_images/ipy_013_par_tb.png
     :width: 460px
     :alt: Improved parallel exceptions.
     :align: center
     :target: ../_images/ipy_013_par_tb.png
 
 The parallel tools now default to using ``NoDB`` as the storage backend for
 intermediate results.  This means that the default usage case will have a
 significantly reduced memory footprint, though certain advanced features are
 not available with this backend.
 
 The parallel magics now display all output, so you can do parallel plotting or
 other actions with complex display.  The ``px`` magic has now both line and cell
 modes, and in cell mode finer control has been added about how to collate
 output from multiple engines. :ghpull:`1768`.
 
 There have also been incremental improvements to the SSH launchers:
     
 * add to_send/fetch steps for moving connection files around.
   
 * add SSHProxyEngineSetLauncher, for invoking to `ipcluster engines` on a
   remote host. This can be used to start a set of engines via PBS/SGE/MPI
   *remotely*.
     
 This makes the SSHLauncher usable on machines without shared filesystems.
 
 A number of 'sugar' methods/properties were added to AsyncResult that are
 quite useful (:ghpull:`1548`) for everday work:
     
     * ``ar.wall_time`` = received - submitted
     * ``ar.serial_time`` = sum of serial computation time
     * ``ar.elapsed`` = time since submission (wall_time if done)
     * ``ar.progress`` = (int) number of sub-tasks that have completed
     * ``len(ar)`` = # of tasks
     * ``ar.wait_interactive()``: prints progress
     
 Added :meth:`.Client.spin_thread` / :meth:`~.Client.stop_spin_thread` for
 running spin in a background thread, to keep zmq queue clear.  This can be used
 to ensure that timing information is as accurate as possible (at the cost of
 having a background thread active).
 
 Set TaskScheduler.hwm default to 1 instead of 0.  1 has more
 predictable/intuitive behavior, if often slower, and thus a more logical
 default.  Users whose workloads require maximum throughput and are largely
 homogeneous in time per task can make the optimization themselves, but now the
 behavior will be less surprising to new users. :ghpull:`1294`.
 
 
 Kernel/Engine unification
 -------------------------
 
 This is mostly work 'under the hood', but it is actually a *major* achievement
 for the project that has deep implications in the long term: at last, we have
 unified the main object that executes as the user's interactive shell (which we
 refer to as the *IPython kernel*) with the objects that run in all the worker
 nodes of the parallel computing facilities (the *IPython engines*).  Ever since
 the first implementation of IPython's parallel code back in 2006, we had wanted
 to have these two roles be played by the same machinery, but a number of
 technical reasons had prevented that from being true.
 
 In this release we have now merged them, and this has a number of important
 consequences:
 
 * It is now possible to connect any of our clients (qtconsole or terminal
   console) to any individual parallel engine, with the *exact* behavior of
   working at a 'regular' IPython console/qtconsole.  This makes debugging,
   plotting, etc. in parallel scenarios vastly easier.
 
 * Parallel engines can always execute arbitrary 'IPython code', that is, code
   that has magics, shell extensions, etc.  In combination with the ``%%px``
   magics, it is thus extremely natural for example to send to all engines a
   block of Cython or R code to be executed via the new Cython and R magics. For
   example, this snippet would send the R block to all active engines in a
   cluster::
 
     %%px
     %%R
     ... R code goes here
   
 * It is possible to embed not only an interactive shell with the
   :func:`IPython.embed` call as always, but now you can also embed a *kernel*
   with :func:`IPython.embed_kernel()`.  Embedding an IPython kernel in an
   application is useful when you want to use :func:`IPython.embed` but don't
   have a terminal attached on stdin and stdout.
 
 * The new :func:`IPython.parallel.bind_kernel` allows you to promote Engines to
   listening Kernels, and connect QtConsoles to an Engine and debug it
   directly.
 
 In addition, having a single core object through our entire architecture also
 makes the project conceptually cleaner, easier to maintain and more robust.
 This took a lot of work to get in place, but we are thrilled to have this major
 piece of architecture finally where we'd always wanted it to be.
   
 
 Official Public API
 -------------------
 
 We have begun organizing our API for easier public use, with an eye towards an
 official IPython 1.0 release which will firmly maintain this API compatible for
 its entire lifecycle.  There is now an :mod:`IPython.display` module that
 aggregates all display routines, and the :mod:`traitlets.config` namespace has
 all public configuration tools.  We will continue improving our public API
 layout so that users only need to import names one level deeper than the main
 ``IPython`` package to access all public namespaces.
 
 
 IPython notebook file icons
 ---------------------------
 
 The directory ``docs/resources`` in the source distribution contains SVG and
 PNG versions of our file icons, as well as an ``Info.plist.example`` file with
 instructions to install them on Mac OSX.  This is a first draft of our icons,
 and we encourage contributions from users with graphic talent to improve them
 in the future.
 
 	  
 New top-level `locate` command
 ------------------------------
 
 Add `locate` entry points; these would be useful for quickly locating IPython
 directories and profiles from other (non-Python) applications. :ghpull:`1762`.
     
 Examples::
     
     $> ipython locate
     /Users/me/.ipython
   
     $> ipython locate profile foo
     /Users/me/.ipython/profile_foo
   
     $> ipython locate profile
     /Users/me/.ipython/profile_default
   
     $> ipython locate profile dne
     [ProfileLocate] Profile u'dne' not found.
 
 	
 Other new features and improvements
 -----------------------------------
 
 * **%install_ext**: A new magic function to install an IPython extension from
   a URL. E.g. ``%install_ext
   https://bitbucket.org/birkenfeld/ipython-physics/raw/default/physics.py``.
 
 * The ``%loadpy`` magic is no longer restricted to Python files, and has been
   renamed ``%load``. The old name remains as an alias.
 
 * New command line arguments will help external programs find IPython folders:
   ``ipython locate`` finds the user's IPython directory, and ``ipython locate
   profile foo`` finds the folder for the 'foo' profile (if it exists).
 
 * The :envvar:`IPYTHON_DIR` environment variable, introduced in the Great
   Reorganization of 0.11 and existing only in versions 0.11-0.13, has been
   deprecated. As described in :ghpull:`1167`, the complexity and confusion of
   migrating to this variable is not worth the aesthetic improvement. Please use
   the historical :envvar:`IPYTHONDIR` environment variable instead.
 
 * The default value of *interactivity* passed from
   :meth:`~IPython.core.interactiveshell.InteractiveShell.run_cell` to
   :meth:`~IPython.core.interactiveshell.InteractiveShell.run_ast_nodes`
   is now configurable.
 
 * New ``%alias_magic`` function to conveniently create aliases of existing
   magics, if you prefer to have shorter names for personal use.
 
 * We ship unminified versions of the JavaScript libraries we use, to better
   comply with Debian's packaging policies.
 
 * Simplify the information presented by ``obj?/obj??`` to eliminate a few
   redundant fields when possible.  :ghpull:`2038`.
 
 * Improved continuous integration for IPython.  We now have automated test runs
   on `Shining Panda <https://jenkins.shiningpanda.com/ipython>`_ and `Travis-CI
   <http://travis-ci.org/#!/ipython/ipython>`_, as well as `Tox support
   <http://tox.testrun.org>`_.
 
 * The `vim-ipython`_ functionality (externally developed) has been updated to
   the latest version.
 
 .. _vim-ipython: https://github.com/ivanov/vim-ipython
 
 * The ``%save`` magic now has a ``-f`` flag to force overwriting, which makes
   it much more usable in the notebook where it is not possible to reply to
   interactive questions from the kernel. :ghpull:`1937`.
 
 * Use dvipng to format sympy.Matrix, enabling display of matrices in the Qt
   console with the sympy printing extension. :ghpull:`1861`.
 
 * Our messaging protocol now has a reasonable test suite, helping ensure that
   we don't accidentally deviate from the spec and possibly break third-party
   applications that may have been using it.  We encourage users to contribute
   more stringent tests to this part of the test suite.  :ghpull:`1627`.
 
 * Use LaTeX to display, on output, various built-in types with the SymPy
   printing extension. :ghpull:`1399`.
 
 * Add Gtk3 event loop integration and example. :ghpull:`1588`.
 
 * ``clear_output`` improvements, which allow things like progress bars and other
   simple animations to work well in the notebook (:ghpull:`1563`):
     
     * `clear_output()` clears the line, even in terminal IPython, the QtConsole
       and plain Python as well, by printing `\r` to streams.
     
     * `clear_output()` avoids the flicker in the notebook by adding a delay,
       and firing immediately upon the next actual display message.
     
     * `display_javascript` hides its `output_area` element, so using display to
       run a bunch of javascript doesn't result in ever-growing vertical space.
 
 * Add simple support for running inside a virtualenv.  While this doesn't
   supplant proper installation (as users should do), it helps ad-hoc calling of
   IPython from inside a virtualenv. :ghpull:`1388`.
 
   
 Major Bugs fixed
 ----------------
 
 In this cycle, we have :ref:`closed over 740 issues <issues_list_013>`, but a
 few major ones merit special mention:
 
 * The ``%pastebin`` magic has been updated to point to gist.github.com, since
   unfortunately http://paste.pocoo.org has closed down. We also added a -d flag
   for the user to provide a gist description string. :ghpull:`1670`.
 
 * Fix ``%paste`` that would reject certain valid inputs. :ghpull:`1258`.
 
 * Fix sending and receiving of Numpy structured arrays (those with composite
   dtypes, often used as recarrays). :ghpull:`2034`.
 
 * Reconnect when the websocket connection closes unexpectedly. :ghpull:`1577`.
 
 * Fix truncated representation of objects in the debugger by showing at least
   80 characters' worth of information.  :ghpull:`1793`.
 
 * Fix logger to be Unicode-aware: logging could crash ipython if there was
   unicode in the input. :ghpull:`1792`.
 
 * Fix images missing from XML/SVG export in the Qt console. :ghpull:`1449`.
 
 * Fix deepreload on Python 3. :ghpull:`1625`, as well as having a much cleaner
   and more robust implementation of deepreload in general. :ghpull:`1457`.
 
 
 Backwards incompatible changes
 ------------------------------
 
 * The exception :exc:`IPython.core.error.TryNext` previously accepted
   arguments and keyword arguments to be passed to the next implementation
   of the hook. This feature was removed as it made error message propagation
   difficult and violated the principle of loose coupling.

docs/source/whatsnew/version7.rst

@@ -1,215 +1,215 b''
 ============
  7.x Series
 ============
 
 .. _whatsnew700:
 
 IPython 7.0.0
 =============
 
 .. warning::
 
    IPython 7.0 is currently in Beta, Feedback on API/changes and
    addition/updates to this cahngelog are welcomed.
 
 Released .... ...., 2017
 
 IPython 7 include major features improvement as you can read in the following
 changelog. This is also the second major version of IPython to stop support only
 Python 3 – starting at Python 3.4. Python 2 is still still community supported
 on the bugfix only 5.x branch, but we remind you that Python 2 EOL is Jan 1st
 2020.
 
 We were able to backport bug fixes to the 5.x branch thanks to our backport bot which
 backported more than `70 Pull-Requests
 <https://github.com/ipython/ipython/pulls?page=3&q=is%3Apr+sort%3Aupdated-desc+author%3Aapp%2Fmeeseeksdev++5.x&utf8=%E2%9C%93>`_, but there are still many PRs that required manually work, and this is an area of the project were you can easily contribute by looking for `PRs still needed backport <https://github.com/ipython/ipython/issues?q=label%3A%22Still+Needs+Manual+Backport%22+is%3Aclosed+sort%3Aupdated-desc>`_
 
 IPython 6.x branch will likely not see any further release unless we critical
 bugs are found.
 
 Make sure you have pip > 9.0 before upgrading. You should be able to update by simply runngin
 
 .. code::
 
     pip install ipython --upgrade
 
 Or if you have conda installed: 
 
 .. code::
    
    conda install ipython
 
 
 
 Prompt Toolkit 2.0
 ------------------
 
 IPython 7.0+ now use ``prompt_toolkit 2.0``, if you still need to use earlier 
 ``prompt_toolkit`` version you may need to pin IPython to ``<7.0``.
 
 Autowait: Asynchronous REPL
 ---------------------------
 
 Staring with IPython 7.0 and on Python 3.6+, IPython can automatically await
 code at top level, you should not need to access an event loop or runner
 yourself. To know more read the :ref:`autoawait` section of our docs, see
 :ghpull:`11265` or try the following code::
 
     Python 3.6.0
     Type 'copyright', 'credits' or 'license' for more information
     IPython 7.0.0 -- An enhanced Interactive Python. Type '?' for help.
 
     In [1]: import aiohttp
        ...: result = aiohttp.get('https://api.github.com')
 
     In [2]: response = await result
     <pause for a few 100s ms>
 
     In [3]: await response.json()
     Out[3]:
     {'authorizations_url': 'https://api.github.com/authorizations',
      'code_search_url': 'https://api.github.com/search/code?q={query}{&page,per_page,sort,order}',
     ...
     }
 
 .. note::
 
    Async integration is experimental code, behavior may change or be removed
    between Python and IPython versions without warnings.
 
 Integration is by default with `asyncio`, but other libraries can be configured,
 like ``curio`` or ``trio``, to improve concurrency in the REPL::
 
     In [1]: %autoawait trio
 
     In [2]: import trio
 
     In [3]: async def child(i):
        ...:     print("   child %s goes to sleep"%i)
        ...:     await trio.sleep(2)
        ...:     print("   child %s wakes up"%i)
 
     In [4]: print('parent start')
        ...: async with trio.open_nursery() as n:
        ...:     for i in range(3):
        ...:         n.spawn(child, i)
        ...: print('parent end')
     parent start
        child 2 goes to sleep
        child 0 goes to sleep
        child 1 goes to sleep
        <about 2 seconds pause>
        child 2 wakes up
        child 1 wakes up
        child 0 wakes up
     parent end
 
 See :ref:`autoawait` for more information.
 
 
 Asynchronous code in a Notebook interface or any other frontend using the
 Jupyter Protocol will need further updates of the IPykernel package.
 
 Non-Asynchronous code
 ~~~~~~~~~~~~~~~~~~~~~
 
 As the internal API of IPython are now asynchronous, IPython need to run under
 an even loop. In order to allow many workflow, (like using the ``%run`` magic,
 or copy_pasting code that explicitly starts/stop event loop), when top-level code
 is detected as not being asynchronous, IPython code is advanced via a
 pseudo-synchronous runner, and will not may not advance pending tasks.
 
 Change to Nested Embed
 ~~~~~~~~~~~~~~~~~~~~~~
 
 The introduction of the ability to run async code had some effect on the
 ``IPython.embed()`` API. By default embed will not allow you to run asynchronous
 code unless a event loop is specified.
 
 Effects on Magics
 ~~~~~~~~~~~~~~~~~
 
 Some magics will not work with Async, and will need updates. Contribution
 welcome.
 
 Expected Future changes
 ~~~~~~~~~~~~~~~~~~~~~~~
 
 We expect more internal but public IPython function to become ``async``, and
 will likely end up having a persisting event loop while IPython is running.
 
 Thanks
 ~~~~~~
 
 This took more than a year in the making, and the code was rebased a number of
 time leading to commit authorship that may have been lost in the final
 Pull-Request. Huge thanks to many people for contribution, discussion, code,
 documentation, use-case: dalejung, danielballan, ellisonbg, fperez, gnestor,
 minrk, njsmith, pganssle, tacaswell, takluyver , vidartf ... And many other.
 
 
-Autoreload Improvment
----------------------
+Autoreload Improvement
+----------------------
 
 The magic ``%autoreload 2`` now captures new methods added to classes. Earlier, only methods existing as of the initial import were being tracked and updated.  
 
 This new feature helps dual environment development - Jupyter+IDE - where the code gradually moves from notebook cells to package files, as it gets structured.
 
 **Example**: An instance of the class `MyClass` will be able to access the method `cube()` after it is uncommented and the file `file1.py` saved on disk.
 
 
 ..code::
 
    # notebook
 
    from mymodule import MyClass
    first = MyClass(5)
 
 .. code::
 
    # mymodule/file1.py
 
    class MyClass:
 
        def __init__(self, a=10):
            self.a = a
 
        def square(self):
            print('compute square')
            return self.a*self.a
 
        # def cube(self):
        #     print('compute cube')
        #     return self.a*self.a*self.a
 
 
 
 
 Misc
 ----
 
 The autoindent feature that was deprecated in 5.x was re-enabled and
 un-deprecated in :ghpull:`11257`
 
 Make ``%run -n -i ...`` work correctly. Earlier, if ``%run`` was passed both arguments, ``-n`` would be silently ignored. See :ghpull:`10308`
 
 
 
 
 
 Deprecations
 ------------
 
 A couple of unused function and methods have been deprecated and will be removed
 in future versions:
 
   - ``IPython.utils.io.raw_print_err``
   - ``IPython.utils.io.raw_print``
 
   
 Backwards incompatible changes
 ------------------------------
 
 * The API for transforming input before it is parsed as Python code has been
   completely redesigned, and any custom input transformations will need to be
   rewritten. See :doc:`/config/inputtransforms` for details of the new API.