Paul,
On 2015-04-26 8:17 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 19:45:30 -0400
Yury Selivanov <yselivanov...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
