[Python-Dev] PEP 492: No new syntax is required

[Paul Sokolovsky]

Hello,

On Sun, 26 Apr 2015 19:45:30 -0400
Yury Selivanov <yselivanov.ml at gmail.com> wrote:

[]

> > Then, is the only logic for proposing __aenter__ is to reinsure
> > against a situation that someone starts to write async context
> > manager, forgets that they write async context manager, and make an
> > __enter__ method there.
> 
> It's to make sure that it's impossible to accidentally use
> existing regular context manager that returns a future object
> from its __enter__ / __exit__ (nobody prohibits you to return a
> future object from __exit__, although it's pointless) in an
> 'async with' block.

I see, so it's just to close the final loophole, unlikely to be hit in
real life (unless you can say that there're cases of doing just that in
existing asyncio libs). Well, given that Greg Ewing wanted even
stricter error-proofness, and you rejected it as such strict as to
disallow useful behavior, I've just got to trust you that in this
case, you're as strict as needed.

> I really don't understand the desire to reuse existing magic
> methods.  Even if it was decided to reuse them, it wouldn't
> even simplify the implementation in CPython; the code there
> is already DRY (I don't re-implement opcodes for 'with'
> statement; I reuse them).

Well, there're 3 levels of this stuff:

1. How "mere" people write their code - everyone would use async def and
await, this should be bullet- (and fool-) proof.
2. How "library" code is written - async iterators won't be written by
everyone, and only few will write async context managers; it's fair to
expect that people doing these know what they do and don't do stupid
mistakes.
3. How it all is coded in particular Python implementation.

It's clear that __enter__ vs __aenter__ distinction is 1st kind of
issue in your list.

As for 3rd point, I'd like to remind that CPython is only one Python
implementation. And with my MicroPython hat on, I'd like to know if
(some of) these new features are "bloat" or "worthy" for the space
constraints we have.


I appreciate the answers you gave on all accounts!

> 
> Thanks!
> Yury

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com