On 08.08.2016 19:06, Yury Selivanov wrote:
You have to be aware of what you're decorating. Always.
You have to be aware of what the decorator does first before you decide
if it's relevant to be aware of what you're decorating.
For instance, here's an example of a buggy code:
@functools.lru_cache()
def foo():
yield 123
I'm really against duck typing here. I see no point in making the API
for async generators to look similar to the API of sync generators.
And so do I to making them "almost similar" by putting an "a" in front
of the well-known generator protocol.
But maybe, because there is not real convincing argument on either side,
it doesn't matter at all.
You have to provide a solid real-world example of where it might help
with asynchronous generators to convince me otherwise ;)
Something, I learned in the past years is to be prepared. So, such solid
real-world examples might emerge when async generators are out in the
wild. Let's hope this does not make it harder for them to start with. :)
There is a separate attribute already -- __class__. Plus a couple of
new functions in inspect module: inspect.isasyncgenfunction and
inspect.isasyncgen. And the new types.AsyncGeneratorType for
isinstance checks.
Got it, thanks.
Just another random thought I want to share:
From what I've heard in the wild, that most if not all pieces of async
are mirroring existing Python features. So, building async basically
builds a parallel structure in Python resembling Python. Async
generators complete the picture. Some people (including me) are
concerned by this because they feel that having two "almost the same
pieces" is not necessarily a good thing to have. And not necessarily bad
but it feels like duplicating code all over the place especially as
existing functions are incompatible with async.
As I understand it, one goal is to be as close to sync code as possible
to make async code easier to understand. So, if dropping 'await's all
over the place is the main difference between current async and sync
code, I get the feeling both styles could be very much unified. (The
examples of the PEP try to do it like this but it wouldn't work as we
already discussed.) Maybe, it's too early for a discussion about this
but I wanted to dump this thought somewhere. :)
Thanks,
Sven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
