On 09.08.2016 05:23, Nick Coghlan wrote:
On 9 August 2016 at 08:37, Sven R. Kunze <[email protected]
<mailto:[email protected]>> wrote:
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.
It's a known problem that applies to programming language design in
general rather than being Python specific:
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
If it's a such well-known **problem**, why does it even exist in Python
in the first place? ;-)
I don't buy that one couldn't have avoided it.
Lately, I talked to friend of mine about async and his initial reaction
was like "hmm that reminds me of early programming days, where you have
to explicitly tell the scheduler to get control back". He's much older
than me, so I think it was interesting for him to see that history is
repeating again.
The async/await model used in C# and Python 3.5+ aims to at least make
it clear whether you're dealing with "red" (asynchronous) or "blue"
(synchronous) code, but some use cases will still benefit from using
something like gevent to bridge between the synchronous world and the
asynchronous one:
http://python-notes.curiousefficiency.org/en/latest/pep_ideas/async_programming.html#gevent-and-pep-3156
In cases where blocking for IO is acceptable, the
"run_until_complete()" method on event loop implementations can be
used in order to invoke asynchronous code synchronously:
http://www.curiousefficiency.org/posts/2015/07/asyncio-background-calls.html
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. :)
One of the big mindset shifts it encourages is to design as many
support libraries as possible as computational pipelines and
message-drive state machines, rather than coupling them directly to IO
operations (which is the way many of them work today). Brett Cannon
started the Sans IO information project to discuss this concept at
http://sans-io.readthedocs.io/
Interesting shift indeed and I like small Lego bricks I can use to build
a big house.
However, couldn't this be achieved without splitting the community?
Sven
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
