After much consideration, and playing with PEP380, I've changed my
stance on this. Full blown coroutines are the proper way forward.
greenlet doesn't cut it because the Python interpreter isn't aware of
the context switches. Profiling, debugging and tracebacks are
completely broken by this.
Glyph wrote:
Yes, but you /can/ look at a 'yield' and conclude that you /might/ need
a lock, and that you have to think about it.
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over whether a lock is needed every time
you see one, they will cause you a lot more anxiety than they
alleviate.
Not necessarily. The
Glyph wrote:
[Guido] mentions the point that coroutines that can implicitly switch out from
under you have the same non-deterministic property as threads: you don't
know where you're going to need a lock or lock-like construct to update
any variables, so you need to think about concurrency
On Fri, Jan 20, 2012 at 8:41 AM, Greg greg.ew...@canterbury.ac.nz wrote:
Glyph wrote:
[Guido] mentions the point that coroutines that can implicitly switch out
from under you have the same non-deterministic property as threads: you
don't know where you're going to need a lock or lock-like
On Jan 19, 2012, at 4:41 PM, Greg wrote:
Glyph wrote:
[Guido] mentions the point that coroutines that can implicitly switch out
from under you have the same non-deterministic property as threads: you
don't know where you're going to need a lock or lock-like construct to
update any
Matt Joiner wrote:
Just to clarify, this differs in functionality from enhanced generators
by allowing you to yield from an arbitrary call depth rather than having
to yield from through a chain of calling generators? Furthermore
there's no syntactical change except to the bottommost frame
Glyph wrote:
On Jan 17, 2012, at 5:03 PM, Mark Shannon wrote:
Lets start controversially: I don't like PEP 380, I think it's a kludge.
Too late; it's already accepted. There's not much point in making
controversial statements about it now.
Why is it too late? Presenting this as a fait
On Jan 18, 2012, at 4:23 AM, Mark Shannon wrote:
Glyph wrote:
On Jan 17, 2012, at 5:03 PM, Mark Shannon wrote:
Lets start controversially: I don't like PEP 380, I think it's a kludge.
Too late; it's already accepted. There's not much point in making
controversial statements about it now.
PEP380 and Mark's coroutines could coexist, so I really don't it's
too late matters. Furthermore, PEP380 has utility in its own right
without considering its use for explicit coroutines.
I would like to see these coroutines considered, but as someone else
mentioned, coroutines via PEP380 enhanced
Hi all.
Lets start controversially: I don't like PEP 380, I think it's a kludge.
I think that CPython should have proper coroutines, rather than add more
bits and pieces to generators in an attempt to make them more like
coroutines.
I have mentioned this before, but this time I have done
Just to clarify, this differs in functionality from enhanced generators by
allowing you to yield from an arbitrary call depth rather than having to
yield from through a chain of calling generators? Furthermore there's no
syntactical change except to the bottommost frame doing a co_yield? Does
this
Mark Shannon wrote:
I think that CPython should have proper coroutines, rather than add more
bits and pieces to generators in an attempt to make them more like
coroutines.
I have mentioned this before, but this time I have done something about
it :)
I have a working, portable, (asymmetric)
On Jan 17, 2012, at 5:03 PM, Mark Shannon wrote:
Lets start controversially: I don't like PEP 380, I think it's a kludge.
Too late; it's already accepted. There's not much point in making
controversial statements about it now.
I think that CPython should have proper coroutines, rather than
14 matches
Mail list logo
