Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +collections.abc: Coroutine should be derived from Awaitable
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
,
for example, which would then not fail in Cython. [..]
I think if next(cython_coro) does not fail is acceptable. It's not ideal, but
the purpose of Cython is to make Python code as fast as possible, so I'd try
to avoid having any kind of thin wrappers around Cyhton coroutines.
--
dependencies
Stefan Behnel added the comment:
Thanks Yury, I'll give it a try ASAP.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Roundup Robot added the comment:
New changeset 843fe7e831a8 by Yury Selivanov in branch '3.5':
Issue 24297: Update symbol.py. See also issue 24017.
https://hg.python.org/cpython/rev/843fe7e831a8
New changeset 87509d71653b by Yury Selivanov in branch 'default':
Issue 24297: Update symbol.py. See
Stefan Behnel added the comment:
It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an object
with an __await__ method.
coroutine, yes. But Coroutine? Shouldn't the Coroutine ABC then require
__await__ to be implemented? Maybe even by inheriting from Awaitable?
Just
Nick Coghlan added the comment:
Thanks for highlighting these Stefan - you guessed correctly that I'd missed
them on the review.
For your first question, I agree getawaitablefunc / aiternextfunc /
getaiterfunc should all be dropped and replaced with the existing unaryfunc.
For your second
Nick Coghlan added the comment:
Given that tp_call is just ternaryfunc, my guess would be because when the
iterator protocol was added, someone went with function-pointer-type-per-slot
rather than function-pointer-type-per-call-signature.
We *are* a little inconsistent here (e.g. reprfunc
Yury Selivanov added the comment:
It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an
object with an __await__
method.
coroutine, yes. But Coroutine? Shouldn't the Coroutine ABC then require
__await__ to be implemented? Maybe even by inheriting from Awaitable?
This
Yury Selivanov added the comment:
For your first question, I agree getawaitablefunc / aiternextfunc /
getaiterfunc should all be dropped and replaced with the existing unaryfunc.
I have no problem with that. But why do we have iternextfunc getiterfunc (no
a prefix)?
--
is this actually necessary? I'm aware that it's also mentioned in the PEP,
but is there an actual reason why a coroutine should behave the same as a
generator here? Is it just an implementation detail for legacy reasons because
generators and coroutines happen to share the same type implementation? (I
don't
the same as
a generator here? Is it just an implementation detail for legacy reasons
because generators and coroutines happen to share the same type
implementation? (I don't think they need to, BTW.)
Coroutines are implemented on top of generators. Until we clearly separate
them (in 3.6?) I
Stefan Behnel added the comment:
Another question: is it ok if Cython implements and uses the tp_as_async slot
in all Py3.x versions (3.2+)? It shouldn't hurt, but it would speed up
async/await in Cython at least under Py3.x. Only Py2.6/7 would then have to
resort to calling __await__() etc.
Roundup Robot added the comment:
New changeset ff983ee10b3e by Yury Selivanov in branch 'default':
Issue 24017: Use abc.Coroutine in inspect.iscoroutine() function
https://hg.python.org/cpython/rev/ff983ee10b3e
--
___
Python tracker
Yury Selivanov added the comment:
Closing the issue. I'll open a new one for missing documentation. Thanks!
--
components: +Interpreter Core
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 492: Documentation
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Roundup Robot added the comment:
New changeset 0d80d46adfdb by Yury Selivanov in branch 'default':
Issue 24017: More tests for 'async for' and 'async with'.
https://hg.python.org/cpython/rev/0d80d46adfdb
--
___
Python tracker rep...@bugs.python.org
Guido van Rossum added the comment:
BTW, a shout out to Nick for doing most of the review for this monster patch.
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 492: Add AsyncIterator and AsyncIterable to collections.abc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Nick Coghlan added the comment:
A bit more detail on the patch-as-merged: it has all of Yury's new tests, but
the actual bug turned out to just be a missing INCREF/DECREF pair in
WITH_CLEANUP_START and WITH_CLEANUP_FINISH.
In the success case the reference counting errors cancelled each other
Roundup Robot added the comment:
New changeset 9d2c4d887c19 by Yury Selivanov in branch 'default':
Issue #24017: Unset asyncio event loop after test.
https://hg.python.org/cpython/rev/9d2c4d887c19
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset e39fd5a8501a by Nick Coghlan in branch 'default':
Issue 24017: fix for async with refcounting
https://hg.python.org/cpython/rev/e39fd5a8501a
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Is there are a specific reason this implicit exception handler can't be
decomposed and implemented using the same opcodes as are used to implement
explicit exception handlers?
I don't think it's possible to replace ASYNC_WITH_CLEANUP_EXCEPT opcode with
Nick Coghlan added the comment:
I'm going to dig into this one locally, as it sounds to me like something may
be going wrong with the refcounts in the complex stack manipulation involved in
WITH_CLEANUP. It seems plausible that there's a genuinely missing incref/decref
pair somewhere in the
Yury Selivanov added the comment:
I'd suggest you to look at ceval.c before PEP 492 patch then (where there is
just one WITH_CLEANUP opcode).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Nick Coghlan added the comment:
Avoiding WITH_CLEANUP entirely in the async case also sounds like a plausible
approach. Either way, I'm also on IRC now if you want to thrash this out there.
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
Nick, Guido,
Attached is a patch that fixes a refleak in 'async with' implementation.
The problem is related to WITH_CLEANUP_START/WITH_CLEANUP_FINISH opcodes.
For regular 'with' statements, these opcodes go one after another (essentially,
it was one opcode
Nick Coghlan added the comment:
I'm bothered by the remarkable proliferation of new opcodes for the PEP 492
handling. Is there are a specific reason this implicit exception handler can't
be decomposed and implemented using the same opcodes as are used to implement
explicit exception handlers?
Roundup Robot added the comment:
New changeset 0dc3b61f1dfa by Yury Selivanov in branch 'default':
Issue #24017: Plug ref leak.
https://hg.python.org/cpython/rev/0dc3b61f1dfa
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset ee7d2c9c70ab by Yury Selivanov in branch '3.4':
asyncio: Make sure sys.set_coroutine_wrapper is called *only* when loop is
running.
https://hg.python.org/cpython/rev/ee7d2c9c70ab
New changeset 874edaa34b54 by Yury Selivanov in branch 'default':
Yury Selivanov added the comment:
Nick, Guido,
Updated patch attached.
--
Added file: http://bugs.python.org/file39344/await_06.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Nick Coghlan added the comment:
Guido convinced me that having StopAsyncIteration inherit from Exception was
the right approach, as it means errors are more likely to be of the we caught
it when we shouldn't have variety, rather than the harder to debug an
exception escaped when it shouldn't
Roundup Robot added the comment:
New changeset 3a3cc2b9a1b2 by Yury Selivanov in branch 'default':
Issue 24017: Update NEWS file.
https://hg.python.org/cpython/rev/3a3cc2b9a1b2
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Latest version looks good to me (aside from a quibble about whether
StopAsyncIteration should inherit from BaseException instead of Exception - see
my review for details).
Based on Guido's explanation in the review, I also suggested adding the
following
Roundup Robot added the comment:
New changeset 957478e95b26 by Yury Selivanov in branch '3.4':
asyncio: Support PEP 492. Issue #24017.
https://hg.python.org/cpython/rev/957478e95b26
New changeset 44c1db190525 by Yury Selivanov in branch 'default':
asyncio: Merge 3.4 -- Support PEP 492. Issue
Yury Selivanov added the comment:
Guido, Nick, Victor,
Thanks for your reviews and guidance! The patch has been committed to the
default branch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Roundup Robot added the comment:
New changeset eeeb666a5365 by Yury Selivanov in branch 'default':
PEP 0492 -- Coroutines with async and await syntax. Issue #24017.
https://hg.python.org/cpython/rev/eeeb666a5365
--
___
Python tracker rep
Guido van Rossum added the comment:
Thank you Yury! You are a coding machine.
On Mon, May 11, 2015 at 8:06 PM, Yury Selivanov rep...@bugs.python.org
wrote:
Yury Selivanov added the comment:
Guido, Nick, Victor,
Thanks for your reviews and guidance! The patch has been committed to the
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +add a Generator ABC
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
is assigned to all
'async def' code objects. CO_GENBASED_COROUTINE is assigned to generator-based
coroutines decorated with types.coroutine().
2. tp_await renamed to tp_as_async. (I'm OK to use another name, please see my
older comment first) PyAsyncMethods struct holds three slots: am_await
switching this to instead
use CO_COROUTINE (set for all coroutines, regardless of how they were
defined) and CO_ITERABLE_COROUTINE (set only for those coroutines that also
support iteration), and adjusting the naming of other APIs accordingly.
I agree that CO_COROUTINE is something that we should
me how the objects were defined, rather
than telling me why I should care. Based on what I gleaned of their intended
purpose from reading the implementation, I suggest switching this to instead
use CO_COROUTINE (set for all coroutines, regardless of how they were
defined
, as they only told me how the objects were defined, rather than
telling me why I should care. Based on what I gleaned of their intended purpose
from reading the implementation, I suggest switching this to instead use
CO_COROUTINE (set for all coroutines, regardless of how they were defined
On Fri, May 8, 2015 at 4:36 PM, Rustom Mody rustompm...@gmail.com wrote:
On Friday, May 8, 2015 at 10:39:38 AM UTC+5:30, Chris Angelico wrote:
Why have the concept of a procedure?
On Friday, Chris Angelico ALSO wrote:
With print(), you have a conceptual procedure...
So which do you want to
On Friday, May 8, 2015 at 10:39:38 AM UTC+5:30, Chris Angelico wrote:
Why have the concept of a procedure?
On Friday, Chris Angelico ALSO wrote:
With print(), you have a conceptual procedure...
So which do you want to stand by?
Just to be clear I am not saying python should be any different
Yury Selivanov added the comment:
Another iteration:
- support of new syntax in lib2to3
- collections.abc.Awaitable
--
Added file: http://bugs.python.org/file39325/await_04.patch
___
Python tracker rep...@bugs.python.org
On Fri, May 8, 2015 at 9:53 PM, Dave Angel da...@davea.name wrote:
One thing newbies get tripped up by is having some path through their code
that doesn't explicitly return. And in Python that path therefore returns
None. It's most commonly confusing when there are nested ifs, and one of
the
Stefan Behnel added the comment:
We also need a Coroutine ABC. Both the GeneratorType and CO_COROUTINE
checks are too restrictive. Also see issue 24018, which this one should in fact
depend on.
--
___
Python tracker rep...@bugs.python.org
On 05/08/2015 02:42 AM, Chris Angelico wrote:
On Fri, May 8, 2015 at 4:36 PM, Rustom Mody rustompm...@gmail.com wrote:
On Friday, May 8, 2015 at 10:39:38 AM UTC+5:30, Chris Angelico wrote:
Why have the concept of a procedure?
On Friday, Chris Angelico ALSO wrote:
With print(), you have a
Yury Selivanov added the comment:
Third patch attached. Victor, it would be great if you can review it!
--
Added file: http://bugs.python.org/file39314/await_03.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
On Fri, May 8, 2015 at 2:53 PM, Rustom Mody rustompm...@gmail.com wrote:
Yeah I know
And if python did not try to be so clever, I'd save some time with
student-surprises
In a program, an expression
statement simply discards its result, whether it's None or 42 or
[1,2,3] or anything else.
On Wednesday, May 6, 2015 at 11:19:07 AM UTC+5:30, Steven D'Aprano wrote:
On Wednesday 06 May 2015 14:47, Rustom Mody wrote:
It strikes me that the FP crowd has stretched the notion of function
beyond recognition And the imperative/OO folks have distorted it beyond
redemption.
In what
On Fri, May 8, 2015 at 2:06 PM, Rustom Mody rustompm...@gmail.com wrote:
If the classic Pascal (or Fortran or Basic) sibling balanced abstractions
of function-for-value procedure-for-effect were more in the collective
consciousness rather than C's travesty of function, things might not have
On Friday, May 8, 2015 at 10:24:06 AM UTC+5:30, Rustom Mody wrote:
get is very much a function and the None return is semantically significant.
print is just round peg -- what you call conceptual function -- stuffed into
square hole -- function the only available syntax-category
Sorry
On Wednesday, May 6, 2015 at 6:41:38 PM UTC+5:30, Dennis Lee Bieber wrote:
On Tue, 5 May 2015 21:47:17 -0700 (PDT), Rustom Mody declaimed the following:
If the classic Pascal (or Fortran or Basic) sibling balanced abstractions of
function-for-value
procedure-for-effect were more in the
On Friday, May 8, 2015 at 10:04:02 AM UTC+5:30, Chris Angelico wrote:
On Fri, May 8, 2015 at 2:06 PM, Rustom Mody wrote:
If the classic Pascal (or Fortran or Basic) sibling balanced abstractions
of function-for-value procedure-for-effect were more in the collective
consciousness rather
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +Missing *-unpacking generalizations
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
I'll upload the most recent patch soon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
On Tuesday, May 5, 2015 at 11:15:42 PM UTC+5:30, Marko Rauhamaa wrote:
Personally, I have never found futures a very useful idiom in any
language (Scheme, Java, Python). Or more to the point, concurrency and
the notion of a function don't gel well in my mind.
Interesting comment.
It strikes
On Wednesday 06 May 2015 14:47, Rustom Mody wrote:
It strikes me that the FP crowd has stretched the notion of function
beyond recognition And the imperative/OO folks have distorted it beyond
redemption.
In what way?
And the middle road shown by Pascal has been overgrown with weeds for
I'm working my way through the asyncio documentation. I have got to the Tasks
and coroutines section, but I'm frankly confused as to the difference between
the various things described in that section: coroutines, tasks, and futures.
I think can understand a coroutine. Correct me if I'm wrong
On 5/5/2015 1:46 PM, Ian Kelly wrote:
On Tue, May 5, 2015 at 9:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
I'm working my way through the asyncio documentation. I have got to the Tasks and
coroutines section, but I'm frankly confused as to the difference between the
various things described
On Tue, May 5, 2015 at 9:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
I'm working my way through the asyncio documentation. I have got to the
Tasks and coroutines section, but I'm frankly confused as to the difference
between the various things described in that section: coroutines, tasks
. There seems to be two distinct strands within
the asyncio world, the callback model and the task/coroutine model. AIUI,
coroutines/tasks are supposed to let you avoid callbacks.
So I guess in that model, a Future isn't something you should use directly in
task-based code, because it works via
On Tue, May 5, 2015 at 10:22 AM, Paul Moore p.f.mo...@gmail.com wrote:
I'm working my way through the asyncio documentation. I have got to the
Tasks and coroutines section, but I'm frankly confused as to the difference
between the various things described in that section: coroutines, tasks
On 5/5/2015 11:22 AM, Paul Moore wrote:
I'm working my way through the asyncio documentation. I have got to
the Tasks and coroutines section, but I'm frankly confused as to
the difference between the various things described in that section:
coroutines, tasks, and futures.
I think can
Paul Moore p.f.mo...@gmail.com:
But I don't understand what a Future is.
A future stands for a function that is scheduled to execute in the
background.
Personally, I have never found futures a very useful idiom in any
language (Scheme, Java, Python). Or more to the point, concurrency and
the
On Tuesday, 5 May 2015 17:11:39 UTC+1, Zachary Ware wrote:
On Tue, May 5, 2015 at 10:22 AM, Paul Moore wrote:
I'm working my way through the asyncio documentation. I have got to the
Tasks and coroutines section, but I'm frankly confused as to the
difference between the various things
Paul ... I'm frankly confused ...
You and me both. I'm pretty sure I understand what a Future is, and
until the long discussion about PEP 492 (?) started up, I thought I
understood what a coroutine was from my days in school many years ago.
Now I'm not so sure.
Calling Dave Beazley... Calling
Guido van Rossum added the comment:
I think we can continue this discussion *after* the PEP's been accepted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Stefan Behnel added the comment:
I don't think it's necessary to have slots for __aiter__, __anext__,
__aenter__ and __aexit__. Async iteration will never be as fast as regular
iteration, and there is plenty overhead in it.
You seem to be assuming that the outer loop is the asyncio I/O
Changes by Guido van Rossum gu...@python.org:
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
Stefan Behnel added the comment:
Could we have type slots for the new special methods? Otherwise, implementing
the protocol in C would be fairly inefficient, especially for async iteration.
I'm asking because Cython's generator type is not Python's generator type, but
implementing the rest of
Yury Selivanov added the comment:
In fact I will likely add tp_await in the next PEP iteration. I need it to
implement another feature.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Yury Selivanov added the comment:
Could we have type slots for the new special methods? Otherwise, implementing
the protocol in C would be fairly inefficient, especially for async iteration.
I don't think it's necessary to have slots for __aiter__, __anext__, __aenter__
and __aexit__.
Changes by Yury Selivanov yseliva...@gmail.com:
--
dependencies: +PEP 479: Change StopIteration handling inside generators
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
STINNER Victor added the comment:
Does the implementation depends on the implementation of the PEP 479? (issue
#22906)
Attaching a patch generated with mercurial
Next time, if possible, try to skip generated files. Maybe write a script for
that, but sorry I don't know how :-(
--
Changes by Yury Selivanov yseliva...@gmail.com:
--
assignee: - yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Yury Selivanov added the comment:
Attaching a revised patch (all Victor's comments but asyncio changes)
--
Added file: http://bugs.python.org/file39155/await_02.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Stefan Behnel sco...@users.sourceforge.net:
--
nosy: +scoder
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
hgrepos: -306
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
New submission from Yury Selivanov:
Here's the first patch (git diff master..await). Should be easier to review and
work from there.
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file39147/async_01.patch
___
Python
Yury Selivanov added the comment:
Attaching a patch generated with mercurial
--
Added file: http://bugs.python.org/file39148/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39149/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: haypo
priority: normal
severity: normal
status: open
title: Implemenation of the PEP 492 - Coroutines with async and await syntax
versions: Python 3.5
___
Python tracker rep
Changes by STINNER Victor victor.stin...@gmail.com:
--
hgrepos: +306
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Python-bugs-list
Changes by Yury Selivanov yseliva...@gmail.com:
--
nosy: +asvetlov, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Changes by Yury Selivanov yseliva...@gmail.com:
Removed file: http://bugs.python.org/file39147/async_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Changes by Yury Selivanov yseliva...@gmail.com:
Removed file: http://bugs.python.org/file39149/await_01.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
Marko Rauhamaa ma...@pacujo.net:
The asyncio module comes with coroutine support. Investigating the
topic on the net reveals that FSM's are for old people and the brave
new world uses coroutines. Unfortunately, all examples I could find
seem to be overly simplistic, and I'm left thinking
The asyncio module comes with coroutine support. Investigating the topic
on the net reveals that FSM's are for old people and the brave new world
uses coroutines. Unfortunately, all examples I could find seem to be
overly simplistic, and I'm left thinking coroutines have few practical
uses
On Mon, Jan 06, 2014 at 06:56:00PM -0600, Skip Montanaro wrote:
So, I'm looking for a little guidance. It seems to me that futures,
coroutines, and/or the new Tulip/asyncio package might be my salvation, but
I'm having a bit of trouble seeing exactly how that would work. Let me
outline
On Mon, Jan 06, 2014 at 09:15:56PM -0600, Skip Montanaro wrote:
From the couple responses I've seen, I must have not made myself
clear. Let's skip specific hypothetical tasks. Using coroutines,
futures, or other programming paradigms that have been introduced in
recent versions of Python 3.x
, and
thus having my algorithm scattered all over the place.
So, I'm looking for a little guidance. It seems to me that futures,
coroutines, and/or the new Tulip/asyncio package might be my salvation, but
I'm having a bit of trouble seeing exactly how that would work. Let me
outline a simple hypothetical
up my
calculations into various pieces, and thus having my algorithm scattered
all over the place.
So, I'm looking for a little guidance. It seems to me that futures,
coroutines, and/or the new Tulip/asyncio package might be my salvation,
but I'm having a bit of trouble seeing exactly how
On 06Jan2014 18:56, Skip Montanaro skip.montan...@gmail.com wrote:
[...]
Let's say I have a dead simple GUI with two buttons labeled, Do A and Do
B. Each corresponds to executing a particular activity, A or B, which take
some non-zero amount of time to complete (as perceived by the user) or
On 07Jan2014 13:29, I wrote:
def do_A():
with lock_B():
with lock_A():
_do_A()
Um, of course there would be a cancel_B() up front above, like this:
def do_A():
cancel_B()
with lock_B():
with lock_A():
_do_A()
I'm with MRAB: you don't really need
From the couple responses I've seen, I must have not made myself
clear. Let's skip specific hypothetical tasks. Using coroutines,
futures, or other programming paradigms that have been introduced in
recent versions of Python 3.x, can traditionally event-driven code be
written in a more linear
On 2014-01-07 02:29, Cameron Simpson wrote:
On 06Jan2014 18:56, Skip Montanaro skip.montan...@gmail.com wrote:
[...]
Let's say I have a dead simple GUI with two buttons labeled, Do A and Do
B. Each corresponds to executing a particular activity, A or B, which take
some non-zero amount of time
in question are
created in separate coroutines and stored on separate stacks, so there
is no inner and outer context in the thread that you posted. I
don't believe that they are guaranteed to be called in any particular
order in this case, nor do I think they should be.
First, Python 2 and Python 3
201 - 300 of 334 matches
Mail list logo
