[Python-Dev] PEP 492: No new syntax is required (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Mon Apr 27 02:39:55 CEST 2015

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

More information about the Python-Dev mailing list