doc, remove appveyor 3.4

IPython/core/async_helpers.py

@@ -1,95 +1,96 b''
 """
 Async helper function that are invalid syntax on Python 3.5 and below.
 
 Known limitation and possible improvement.
 
 Top level code that contain a return statement (instead of, or in addition to
 await) will be detected as requiring being wrapped in async calls. This should
 be prevented as early return will not work.
 """
 
 
 import ast
 import sys
 import inspect
 from textwrap import dedent, indent
 from types import CodeType
 
 
 def _asyncio_runner(coro):
     """
     Handler for asyncio autoawait
     """
     import asyncio
 
     return asyncio.get_event_loop().run_until_complete(coro)
 
 
 def _curio_runner(coroutine):
     """
     handler for curio autoawait
     """
     import curio
 
     return curio.run(coroutine)
 
 
 if sys.version_info > (3, 5):
     # nose refuses to avoid this file and async def is invalidsyntax
     s = dedent(
         '''
     def _trio_runner(function):
         import trio
         async def loc(coro):
             """
             We need the dummy no-op async def to protect from
             trio's internal. See https://github.com/python-trio/trio/issues/89
             """
             return await coro
         return trio.run(loc, function)
     '''
     )
     exec(s, globals(), locals())
 
 
 def _asyncify(code: str) -> str:
     """wrap code in async def definition.
 
     And setup a bit of context to run it later.
     """
     res = dedent(
         """
         async def __wrapper__():
             try:
                 {usercode}
             finally:
                 locals()
     """
     ).format(usercode=indent(code, " " * 8)[8:])
     return res
 
 
 def _should_be_async(cell: str) -> bool:
     """Detect if a block of code need to be wrapped in an `async def`
 
     Attempt to parse the block of code, it it compile we're fine.
     Otherwise we  wrap if and try to compile.
 
     If it works, assume it should be async. Otherwise Return False.
 
     Not handled yet: If the block of code has a return statement as  the top
     level, it will be seen as async. This is a know limitation.
     """
 
     try:
         # we can't limit ourself to ast.parse, as it __accepts__ to parse on
         # 3.7+, but just does not _compile_
         compile(cell, "<>", "exec")
         return False
     except SyntaxError:
         try:
             ast.parse(_asyncify(cell))
+            # TODO verify ast has not "top level" return or yield.
         except SyntaxError:
             return False
         return True
     return False

appveyor.yml

@@ -1,31 +1,27 b''
 build: false
 matrix:
   fast_finish: true     # immediately finish build once one of the jobs fails.
 
 environment:
   matrix:
    - PYTHON: "C:\\Python36"
      PYTHON_VERSION: "3.6.x"
      PYTHON_ARCH: "32"
 
-   - PYTHON: "C:\\Python34-x64"
-     PYTHON_VERSION: "3.4.x"
-     PYTHON_ARCH: "64"
-
    - PYTHON: "C:\\Python36-x64"
      PYTHON_VERSION: "3.6.x"
      PYTHON_ARCH: "64"
 
 init:
   - "ECHO %PYTHON% %PYTHON_VERSION% %PYTHON_ARCH%"
 
 install:
   - "SET PATH=%PYTHON%;%PYTHON%\\Scripts;%PATH%"
   - "%CMD_IN_ENV%  python -m pip install --upgrade setuptools pip"
   - "%CMD_IN_ENV%  pip install nose coverage"
   - "%CMD_IN_ENV%  pip install .[test]"
   - "%CMD_IN_ENV%  mkdir results"
   - "%CMD_IN_ENV%  cd results"
 test_script:
   - "%CMD_IN_ENV%  iptest --coverage xml"
   

docs/source/interactive/autoawait.rst

@@ -1,185 +1,193 b''
 .. _autoawait:
 
 Asynchronous in REPL: Autoawait
 ===============================
 
-Starting with IPython 6.0, and when user Python 3.6 and above, IPython offer the
-ability to run asynchronous code from the REPL. constructs which are
+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.
 
-When a supported libray is used, IPython will automatically `await` Futures
-and Coroutines in the REPL. This will happen if an :ref:`await <await>` (or `async`) is
+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 `await` Futures
+and Coroutines in the REPL. This will happen if an :ref:`await <await>` 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 6.0.0.dev -- An enhanced Interactive Python. Type '?' for help.
+    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 `IPython.core.interactiveshell._asyncio_runner`
 
 
 
 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.
+we provide experimental integration with the ``curio`` and ``trio`` library, the
+later one being necessary if you require the ability to do nested call of
+IPython's ``embed()`` functionality.
 
 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.
 
-The default loop, or runner does not run 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]``.
+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]``.
 
 
 Internals
 =========
 
-As running asynchronous code is not supported in interactive REPL as of Python
-3.6 we have to rely to a number of complex workaround to allow this to happen.
-It is interesting to understand how this works in order to understand potential
+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 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 :ct the code object from a async-def function
-and run it in global namesapace after modifying the ``__code__`` object.::
+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 name space. 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. It is
 though possible to provide your own.
 
 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. Feel free to contribute improvements to this codebase
-and give us feedback.
+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.

docs/source/whatsnew/development.rst

@@ -1,44 +1,72 b''
 =====================
  Development version
 =====================
 
 This document describes in-flight development work.
 
 .. warning::
 
     Please do not edit this file by hand (doing so will likely cause merge
     conflicts for other Pull Requests). Instead, create a new file in the
     `docs/source/whatsnew/pr` folder
 
 
 Released .... ...., 2017
 
 
 Need to be updated:
 
 .. toctree::
    :maxdepth: 2
    :glob: 
 
    pr/*
 
 IPython 6 feature a major improvement in the completion machinery which is now
 capable of completing non-executed code. It is also the first version of IPython
 to stop compatibility with Python 2, which is still supported on the bugfix only
 5.x branch. Read below to have a non-exhaustive list of new features.
 
 Make sure you have pip > 9.0 before upgrading. 
 You should be able to update by using:
 
 .. code::
 
     pip install ipython --upgrade
 
 
+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 `autoawait`_ section of our docs, or try the
+following code::
+
+   In [6]: from asyncio import sleep
+      ...: print('Going to sleep...')
+      ...: await sleep(3)
+      ...: print('Waking up')
+   Going to sleep...
+   Waking up
+
+Asynchronous code in a Notebook interface or any other frontend using the
+Jupyter Protocol will need further updates of the IPykernel package.
+
+
+Change to Nested Embed
+======================
+
+The introduction of the ability to run async code had ripple effect on the
+ability to use nested IPython. You may need to install the ``trio`` library
+(version 05 at the time of this writing) to
+have this feature working. 
+
+
 .. DO NOT EDIT THIS LINE BEFORE RELEASE. FEATURE INSERTION POINT.
 
 
 Backwards incompatible changes
 ------------------------------
 
 .. DO NOT EDIT THIS LINE BEFORE RELEASE. INCOMPAT INSERTION POINT.