>>> class A: pass
    ... 
    >>> with A(): pass
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: __enter__

I expected `AttributeError: __exit__`, since PEP 343 states (https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement):

> The details of the above translation are intended to prescribe the exact semantics. If either of the relevant methods are not found as expected, the interpreter will raise AttributeError, in the order that they are tried (__exit__, __enter__).

and the language documentation states (https://docs.python.org/3/reference/compound_stmts.html#the-with-statement):

> The execution of the with statement with one “item” proceeds as follows:
> 1. The context expression (the expression given in the with_item) is evaluated to obtain a context manager.
> 2. The context manager’s __exit__() is loaded for later use.
> 3. The context manager’s __enter__() method is invoked.

See issue 27100, which led to a deliberate change in behaviour to look up __enter__ before __exit__. It looks like the documentation (not the PEP text, which shouldn't be considered normative; just the reference manual) needs to be adjusted to match the new behaviour.

Thanks @mark.dickinson for the link. Can I open a documentation PR for this?

@Gery please do open a documentation PR! :)

Done @brett.cannon, would you like to review it? https://github.com/python/cpython/pull/17608

@gvanrossum

By the way, is there any particular reason why the ``try`` statement implementation equivalent to the ``with`` statement given in PEP 343 puts the finally clause in an outer ``try`` statement instead of in the inner ``try`` statement? (cf. https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement)

In other words, couldn't we simplify this:

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value  # Only if "as VAR" is present
        BLOCK
    except:
        # The exceptional case is handled here
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
        # The exception is swallowed if exit() returns true
finally:
    # The normal and non-local-goto cases are handled here
    if exc:
        exit(mgr, None, None, None)
```

into that?

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    VAR = value  # Only if "as VAR" is present
    BLOCK
except:
    # The exceptional case is handled here
    exc = False
    if not exit(mgr, *sys.exc_info()):
        raise
    # The exception is swallowed if exit() returns true
finally:
    # The normal and non-local-goto cases are handled here
    if exc:
        exit(mgr, None, None, None)
```

It's a matter of historical timing: PEP 343 was written before try/except/finally was allowed, when try/finally and try/except were still distinct statements.

However, PEP 341 was *also* accepted and implemented for Python 2.5, allowing for the modern try/except/finally form: https://docs.python.org/dev/whatsnew/2.5.html#pep-341-unified-try-except-finally

Thanks @ncoghlan, it perfectly answered my question on Stack Overflow: https://stackoverflow.com/questions/59322585/what-is-the-exact-try-statement-equivalent-of-the-with-statement-in-python

New changeset 226e6e7d4326cf91ef37e13528eb1f62de1bb832 by Nick Coghlan (Géry Ogam) in branch 'master':
bpo-39037: Fix lookup order of magic methods in with statement documentation (GH-17608)
https://github.com/python/cpython/commit/226e6e7d4326cf91ef37e13528eb1f62de1bb832

New changeset cbfafa3e3625dae96ce392c88c793f8af55167bf by Miss Islington (bot) in branch '3.8':
bpo-39037: Fix lookup order of magic methods in with statement documentation (GH-17608)
https://github.com/python/cpython/commit/cbfafa3e3625dae96ce392c88c793f8af55167bf