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

[Yury Selivanov]

Paul,

On 2015-04-26 8:17 PM, Paul Sokolovsky wrote:
> 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.

Well, backwards compatibility is something that better
be preserved.  Especially with things like context
managers.  Things with __aiter__/__iter__ are also
different.  It's easier for everyone to just clearly
separate the protocols to avoid all kind of risks.

>
>> 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.

It is.

>
> 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.

OT: MicroPython is an amazing project. Kudos for doing it.

I really hope that addition of few new magic methods won't
make it too hard for you guys to implement PEP 492 in
MicroPython one day.


Thanks!
Yury