Responded to inline comments on patch set 1.
https://codereview.appspot.com/67400043/diff/1/asyncio/base_events.py
File asyncio/base_events.py (right):
https://codereview.appspot.com/67400043/diff/1/asyncio/base_events.py#newcode266
asyncio/base_events.py:266: def call_soon(self, callback, *args,
_check_thread=True):
On 2014/02/24 02:05:20, yselivanov wrote:
'__check_thread' to make it harder to use this API from the outside
of asyncio?
Making it __check_thread creates strange errors:
Traceback (most recent call last):
File
"/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/concurrent/futures/_base.py",
line 297, in _invoke_callbacks
callback(self)
File "/Users/davidf/Projects/tulip/asyncio/futures.py", line 370, in
<lambda>
new_future._copy_state, fut))
File "/Users/davidf/Projects/tulip/asyncio/base_events.py", line 297,
in call_soon_threadsafe
handle = self.call_soon(callback, *args, __check_loop=False)
TypeError: call_soon() got an unexpected keyword argument '__check_loop'
Despite the error message, call_soon() definitely has a keyword argument
'__check_loop'. I suspect some form of name mangling but I don't know
how such mangling with work with keyword arguments.
https://codereview.appspot.com/67400043/diff/1/asyncio/base_events.py#newcode278
asyncio/base_events.py:278: if _check_thread and self.get_debug() and \
On 2014/02/24 02:05:20, yselivanov wrote:
You should use '_debug' here.
Why prefer a private field over a public method?
https://codereview.appspot.com/67400043/diff/1/asyncio/base_events.py#newcode279
asyncio/base_events.py:279: events.get_event_loop() != self:
On 2014/02/24 02:05:20, yselivanov wrote:
I think it's better to memorize the 'thread.ident' in loop's
constructor
and check it here. Otherwise, if a user has a custom event loop
policy,
you theoretically can create a new event loop in another thread
by calling 'get_event_loop'.
Couldn't an event loop be run on different threads at different times?
For example thread alpha calls loop.run_until_complete() and later
thread beta calls loop.run_forever(). In that case it would not be safe
to memorize the initial thread as a proxy for identifying the current
event loop.
It's a shame that get_event_loop() cannot be used to safely detect the
absence of a current loop.
https://codereview.appspot.com/67400043/diff/1/asyncio/base_events.py#newcode281
asyncio/base_events.py:281: "call_soon() invoked on event loop other
than current one")
On 2014/02/24 02:05:20, yselivanov wrote:
On 2014/02/23 23:38:25, GvR wrote:
> On 2014/02/23 06:28:21, davidfstr wrote:
> > I would prefer to use a more specific exception such as an
equivalent to
> Java's
> > IllegalStateException, but I am not aware of any such exception
for Python.
>
> I'd use RuntimeError.
+1
Done. A more specific subclass may be used in the future.
https://codereview.appspot.com/67400043/
