Paul,
On 2015-05-05 3:14 PM, Paul Moore wrote:
On 5 May 2015 at 19:25, Yury Selivanov <yselivanov...@gmail.com> wrote:
On 2015-05-05 7:27 AM, Wolfgang wrote:
Even the discussion on python-dev suggests there is some time needed
to finalize all this.
I'd say that:
80% of the recent discussion of the PEP is about terminology.
10% is about whether we should have __future__ import or not.
But the terminology discussion appears to revolve around people
finding the various concepts involved in asyncio (particularly the new
PEP, but also to an extent the existing implementation) confusing. I
can confirm, having tried to work through the asyncio docs, that the
underlying concepts and how they are explained, are confusing to an
outsider.
I agree. We have to improve asyncio docs in this area.
That's not to say that everything needs to be beginner-friendly, but
it *does* mean that it's hard for the wider Python community to
meaningfully comment, or evaluate or sanity-check the design. We're
left with a sense of "trust us, it makes sense if you need it,
everyone else can ignore it".
Personally, I feel as if PEP 492 is looking a little premature - maybe
the focus should be on making asyncio more accessible first, and
*then* adding syntax. You can argue that the syntax is needed to help
make async more accessible - but if that's the case then the
terminology debates and confusion are clear evidence that it's not
succeeding in that goal. Of course, that's based on my perception of
one of the goals of the PEP as being "make coroutines and asyncio more
accessible", If the actual goals are different, my conclusion is
invalid.
Again, PEP 492 is not only for asyncio. *Any* framework can
use it, including Twisted.
As for terminology, I view this discussion differently. It's
not about the technical details (Python has asymmetric
coroutines, that's it), but rather on how to disambiguate
coroutines implemented with generators and yield-from, from
new 'async def' coroutines. I can't see any fundamental
problem with the PEP behind such discussions.
We forget to address the major problems here. How can someone in a
"sync" script use this async stuff easy. How can async and sync stuff
cooperate and we don't need to rewrite the world for async stuff.
How can a normal user access the power of async stuff without rewriting
all his code. So he can use a simple asyc request library in his code.
How can a normal user learn and use all this in an easy way.
asyncio and twisted answered these questions ;) The answer is
that you have to write async implementations.
Well, twisted always had defer_to_thread. Asyncio has run_in_executor,
but that seems to be callback-based rather than coroutine-based?
Many people use requests for their web access. There are good reasons
for this. Are you saying that until someone steps up and writes an
async implementation of requests, I have to make a choice - requests
or asyncio? Unfortunately, I can't see myself choosing asyncio in that
situation. Which again means that asyncio becomes "something that the
average user can't use". Which in turn further entrenches it as a
specialist-only tool.
There is aiohttp library [1], which provides a client API
similar to requests.
And if you want to write high performance networking server
in python3 you *will* choose asyncio (or gevent/twisted
in python2).
And PEP 492 is aimed to make this whole async stuff more
accessible to an average user.
As another example, in Twisted I could use defer_to_thread to
integrate Oracle database access into a twisted application (that's
what the twisted database stuff did under the hood). Can I do that
with asyncio? Will the syntax in the PEP help, hinder or be irrelevant
to that?
You can use 'loop.run_in_executor' in asyncio. It returns a
future that you can await on. You can also provide a nice
facade for your Oracle-database code that provides a nice
API but uses asyncio thread executor behind the scenes.
And for all this we still can't tell them "oh the async stuff solves
the multiprocessing problem of Python learn it and switch to version
3.5". It does not and it is only most useful for networking stuff
nothing more.
"networking stuff", and in particular, web, is a huge
part of current Python usage. Please don't underestimate
that.
Without async versions of requests and similar, how much of a chunk of
the networking/web area will asyncio take? (Genuine question, I have
no idea).
There are some things (like websockets) that are hard
to implement correctly in existing frameworks like django
and flask. And these kind of things are becoming more
and more important. Languages like Go were designed
specifically to allow writing efficient
And how much extra will this PEP add? Those may not be fair
questions (and even if they are fair, the answers are probably
unknowable), but as an outsider, I feel only the costs of the asyncio
implementation (a new library that I don't understand, and now a
relatively large amount of new syntax and special methods I have to
ignore because they don't make sense to me). That's OK, but I think I
am being reasonable to ask for some sense of the level of benefits
others are getting to balance out the costs I incur.
Paul
It's chicken and egg problem. Right now, current coroutines
via generators approach is cumbersome, it's harder to write
async code than it should be. It stops the innovation in
this area. Some languages like Go were specifically designed
to make network programming easier, and they now steal users
from Python.
There is no absence of libraries for Go (and it's a new
language!), btw. Give people the right tools and they will
build what they need.
Yury
[1] https://github.com/KeepSafe/aiohttp
_______________________________________________
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
