ef6298da9af6%40Canary
> <https://groups.google.com/d/msgid/python-tulip/0526dc8b-9a5b-4d2e-b5d2-ef6298da9af6%40Canary?utm_medium=email&utm_source=footer>
> .
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/
On Wed, Apr 4, 2018 at 9:07 AM, Andrew Svetlov
wrote:
> aiofiles already exist
>
> On Wed, Apr 4, 2018 at 6:05 PM Guido van Rossum
> wrote:
>
>> There's code in trio for treating the filesystem as async, and massive
>> docs about when to use and when not. (Thanks N
There's code in trio for treating the filesystem as async, and massive docs
about when to use and when not. (Thanks Nathaniel!) We should consider
adding that to asyncio, perhaps as a 3rd party package.
On Wed, Apr 4, 2018, 01:22 INADA Naoki wrote:
> You're right. logging.FileHandler **may** bl
ssoren
wrote:
> Hi,
>
> Is there documentation on how to implement new eventloops for asyncio? In
> particular, I intend to write an eventloop implementation for a GUI library
> (PyObjC).
>
> Ronald
--
--Guido van Rossum (python.org/~guido)
day, February 19, 2014 at 4:55:03 PM UTC+1, Guido van Rossum
> wrote:
>>
>> Because that would require duplicating the logic in
>> create_datagram_endpoint(), which is totally separate (all the way down to
>> the I/O callbacks).
>>
>> Feel free to add a feature
syncio/
> base_events.py:176]>
>
> What's going on here? It's still right to expect the same result from the
> three calls or something has changed?
> The documentation for the Task.current_task() function seems unchanged
> between the two version.
>
> My python3.
apped the call in async with
> an asyncio.Lock.
>
> I'm not sure the AssertionError is more help than harm, as protocols such
> as this one where several tasks may operate on the same protocol just need
> to work around it, and protocols that don't support interleaving of writes
> probably run into bugs anyway.
>
> --
> Mathias
>
--
--Guido van Rossum (python.org/~guido)
her() implementation in curio does this the other way
around: curio.gather() is a coroutine, but its argument must be a list of
tasks, not coroutines.
--
--Guido van Rossum (python.org/~guido)
On Tue, Nov 8, 2016 at 12:43 PM, Yury Selivanov
wrote:
>
>
> On 2016-11-08 3:29 PM, Guido van Rossum wrote:
>
>> I think the problem is that it's hard to tell the difference between these
>> two:
>>
>> async def sleep1():
>> await asyncio.s
;
> I re-read this email a few times, but I still don’t fully understand the
> problem you’re trying to describe. Maybe you can describe it in more
> detail?
>
> Yury
>
>
--
--Guido van Rossum (python.org/~guido)
want to make several loop collaborate (= schedule things from one
> loop to be run on another),
> - the feature can be deprecated, as there is no reason for someone to
> still force explicit loop passing.
>
> The question can also be: what is now the recommended usage of
> asyncio.get_event_loop() for asyncio library authors?
>
> Thanks for your input!
>
--
--Guido van Rossum (python.org/~guido)
On Mon, Oct 31, 2016 at 1:30 PM, Yury Selivanov
wrote:
> Guido,
>
> I’m with Andrew on this one.
>
And the reason is the misbehavior of get_event_loop(), right? (See below.)
> > On Oct 31, 2016, at 10:27 AM, Guido van Rossum wrote:
> >
> > I would suggest diff
o could introduce `asyncio.get_current_loop()` function which will
> raise exception if implicit loop exists but there is no running task. After
> that third-party libraries may switch to this function in any case where the
> loop is required. asyncio itself could do the same.
>
> At
ial. Honestly I'd just call
os._exit(0) when you are ready to exit, to avoid all the silly
cleanup-related errors that are trying to warn you against advanced
mistakes.
On Sun, Oct 30, 2016 at 3:00 PM, Donald Stufft wrote:
>
> On Oct 30, 2016, at 5:36 PM, Guido van Rossum wrote:
>
&
package!
--Guido
> Cheers,
>
> Luciano
>
>
> On Sun, Oct 30, 2016 at 5:02 PM, Yury Selivanov wrote:
>>
>>> On Oct 30, 2016, at 2:42 PM, Guido van Rossum wrote:
>>>
>>> On Sun, Oct 30, 2016 at 11:27 AM, Yury Selivanov
>>> wrote:
>>
On Sun, Oct 30, 2016 at 11:27 AM, Yury Selivanov wrote:
>
>> On Oct 30, 2016, at 1:58 PM, Guido van Rossum wrote:
>>
>> Regarding the documentation, I doubt we can get it in shape just by
>> filing issues. We should really just have a tutorial written by
>> som
gt; The blog: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
>
--
--Guido van Rossum (python.org/~guido)
sympathize with many of the
> arguments and have been a very happy user of modern python and asyncio for
> quite a while.
>
> The blog: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/
--
--Guido van Rossum (python.org/~guido)
gned
> patch can solve it.
>
> I've ended up with this:
> Async programming is good, as long as it is the mirror
> image of blocking one.
>
> Inverting the control and then trying to get it back is not
> a good design. As I've tried it once..
--
--Guido van Rossum (python.org/~guido)
might make more sense to propose carefully designed
additions to asyncio that aim to fill in the gaps you've found by
using curio. This should focus on API functionality; the performance
is being worked on separately, and there's also uvloop.
--
--Guido van Rossum (python.org/~guido)
>> to pause the _accept_connection handler that monitors the listening socket
>> for read events.
>>
>> I'd be happy to implement my own logic for the back pressure using a public
>> `pause_serving()`/`resume_serving()` API but a simple `max_connections`
>> param to the create_server would suffice too.
>>
>> Cheers,
>> JM
>
--
--Guido van Rossum (python.org/~guido)
Yes, asynczip() sounds like a nice abstraction if you already have two
async-iterable streams.
Perhaps it makes sense to add it to aiohttp, or to release it as a separate
PyPI package first.
On Tue, Apr 19, 2016 at 8:53 AM, Julien Palard wrote:
> o/
>
> On 04/18/2016 05:31 PM, Guido v
tiplexing/context switching of
> "Python Threads"?)
>
Sorry, you are wrong. Python threads map 1:1 to OS threads. They are as
real as threads come (the GIL notwithstanding).
--
--Guido van Rossum (python.org/~guido)
t;SOON"
> flag, and `wait` flag "ALL_COMPLETED" being my "PAIRED" flag (should I
> rename mines ?) Question is: Am I walking the wrong way and is there a
> simple way to do it I completly missed ? Or is my tool really usefull and
> should be shared ? I'm too young in asyncio to juge that, so I'll listen to
> you ! Bests,
>
> --
> Julien Palard
>
--
--Guido van Rossum (python.org/~guido)
as an old copy, release.py, which
> doesn't support Git.
>
> Victor
--
--Guido van Rossum (python.org/~guido)
xt accept().
>
> --
> Sergey Shepelev
> Skype: sergey.shepelev
> +79996126031
> http://temoto.ru/
>
> ___
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/eventletdev
--
--Guido van Rossum (python.org/~guido)
concern here? Are you worried
> my new _ipaddr_info() function might return an incorrect tuple that differs
> from a real getaddrinfo() return value?
>
> On Tue, Feb 23, 2016 at 12:24 PM, Guido van Rossum wrote:
>>
>> W00t! Hopefully when you connect a socket it actu
W00t! Hopefully when you connect a socket it actually believes the
pre-parsed address.
--Guido (mobile)
a problem
> that's going away.
Humm... Do you for sure that getaddrinfo() can parse numeric IP
addresses (of all flavors) faster than the Python code you wrote,
barring the lock? If that's so I agree.
--
--Guido van Rossum (python.org/~guido)
as the old stop() behaviour.
>
> https://pypi.python.org/pypi/asyncio/ looks quite old: last release
> almost one year ago.
>
> Questions / TODO:
>
> * kill Trollius :-)
> * new asyncio release to PyPI?
> * new aiotest release supporting the new stop behaviour (I
es made in asyncio, so it became
> harder for me to update Trollius.
>
> Trollius is a fork of the asyncio git repository. To update Trollius
> to retrieve latest asyncio changes, you have to fix a lot of subtle
> issues for Python 2 (Python 3 language is simpler!).
>
> Victor
--
--Guido van Rossum (python.org/~guido)
__/__aexit__ required) and
> works even with Python 3.3
>
> I'll be happy to make a Pull Request after getting general agreement.
>
--
--Guido van Rossum (python.org/~guido)
from a coroutine as follows:
>
> @asyncio.coroutine
> def create_periodic_reports(loop):
> clock = Clock(period=300, loop=loop)
> for future_trigger in clock.trigger_events:
> tardiness = yield from future_trigger
> # DO SOMETHING HERE
>
>
> Before I did it this way, I had a pretty convoluted class with a method
> that got called on a power state change event that then had to examine
> state stored in the class manipulated by other methods. Moving the logic
> into a single coroutine seemed to make things simpler to me.
>
> I have just noticed that I have classes each with two methods, one of
> which is __init__. So I could turn them into plain coroutines now, which
> is nice. I refactored extensively to get to where I am now so that's how
> I ended up here. I won't try and do it while drafting this email though
> as I don't have an easy way to test it will work.
>
> Thank you for reading this far! So what do you think? Am I insane, or is
> this a sensible way to arrange things?
>
--
--Guido van Rossum (python.org/~guido)
PS. Can you turn your "swag" into a Pull Request? I'd like to comment on
parts of it. (
https://github.com/python/asyncio/compare/master...mayfield:master won't
let me comment).
--
--Guido van Rossum (python.org/~guido)
I just
> want to suggest that in light of potential changes to exception handling it
> may be worth discussion from stakeholders that know way more about it than
> I do.
>
> Cheers,
> JM
>
> PS: I'm a bit busy this week so I may not be able to look at this again
> till
t; On Wednesday, December 9, 2015 at 6:05:46 PM UTC-5, A. Jesse Jiryu Davis
> wrote:
>>
>> Done:
>>
>> https://github.com/python/asyncio/pull/302
>>
>> On Wednesday, December 9, 2015 at 2:58:07 PM UTC-5, Guido van Rossum
>> wrote:
>>>
>
sk._wakeup` to be
> scheduled in a different loop that `Task._loop`.
> >
> > /Vincent
>
> Here’s a PR to fix this: https://github.com/python/asyncio/pull/303
>
> Thanks,
> Yury
--
--Guido van Rossum (python.org/~guido)
dification
> proposed above, this example would raise the following exception instead:
>
> RuntimeError: a future using a different loop has been yielded
>
> Part of the problem is also that one might expect the current loop to be
> used, while it actually defaults to the result of `asyncio.get_event_loop`.
>
> Has this issue been discussed already?
>
> Thanks.
>
>
>
>
--
--Guido van Rossum (python.org/~guido)
at least to prevent a slow
> getaddrinfo from appearing to be a connection timeout. I haven't decided
> which is the best approach, but #4 allows me flexibility. Would you like me
> to write the patch or will you?
>
> I'm curious about #5 too, but I think that's a longer
BSD to change configuration for the whole
> event loop just so Motor's specific create_connection calls behave
> correctly.
>
> 3. Back to the original proposal: add a connection timeout parameter to
> create_connection. =)
>
> On Tuesday, December 8, 2015 at 4:30:04 PM
afe". Has this belief ever been confirmed?
>
> https://hg.python.org/cpython/file/d2b8354e87f5/Modules/socketmodule.c#l185
>
I don't know -- the list of ifdefs seems to indicate this is a generic BSD
issue, which is OS X's heritage. Maybe someone can do an experiment, or
review the source code used by Apple (if it's still open source)? While I
agree that if this really isn't an issue we shouldn't bother with the lock,
I'd also much rather be safe than sorry when it comes to races in core
Python.
--
--Guido van Rossum (python.org/~guido)
seems to more obvious and more compatible with common
> save/restore patterns.
>
> JM
>
> On Friday, December 4, 2015 at 9:51:07 PM UTC-7, Guido van Rossum wrote:
>>
>> On Fri, Dec 4, 2015 at 11:39 AM, Justin Mayfield
>> wrote:
>>
>>> Hi Guido,
>&
r than in a general
mailing list. In this case I recommend using asyncio's own tracker (
https://github.com/python/asyncio) so we can refine the approach without
bothering the other CPython developers.
Thanks again for volunteering to look into this!
--Guido
> JM
>
> On Fri, Dec 4, 2015 at
ot;,
> line 566, in close
>
> self._loop.call_soon(self._call_connection_lost, None)
>
> File
> "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py",
> line 453, in call_soon
>
> handle = self._call_soon(callback, args)
>
> File
> "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py",
> line 462, in _call_soon
>
> self._check_closed()
>
> File
> "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py",
> line 289, in _check_closed
>
> raise RuntimeError('Event loop is closed')
>
>
--
--Guido van Rossum (python.org/~guido)
the picture. If things fail, it will be simpler to pinpoint
>> where, and if things work, then it points to something in my code.
>>
>> Hopefully I will be able to get it this week and will report back with
>> any findings.
>>
>>
>>
>> On Sunday, Novem
answer Question 1), but it
> doesn't seem right (since my program should be listening to incoming
> connections, even before the client becomes a seeder.)
>
> After the client is a seeder, the program can start the server and the
> handle_leecher coroutine handles incoming connections and handshakes.
> Then the server runs forever and uploads pieces to the remote peers.
>
> Thanks.
> Leslie
>
>
>
>
>
>
--
--Guido van Rossum (python.org/~guido)
gt; exhibited there either.
>
> I can't guarantee that the problem is not internal to pymata-aio, so I
> will try to come up with an example independent of pymata-aio that
> reproduces the problem.
>
> Again thanks.
>
> On Saturday, November 28, 2015 at 5:15:24 PM UTC-
to address the issue.
>
> Thanks.
>
> Alan Yorinks
>
> On Friday, November 27, 2015 at 3:25:49 PM UTC-5, Guido van Rossum wrote:
>>
>> From the looks of it this doesn't have anything to do with asyncio. It
>> seems to be about the default buffering of sys
e OS's event loop
>> implementations is at the root of the problem.
>>
>> The code may be viewed here:
>> https://gist.github.com/MrYsLab/c3a69625cf844cbeb9e0.
>>
>> Any thoughts if this is a bug or not?
>>
>>
>>
>>
>>
>>
>>
--
--Guido van Rossum (python.org/~guido)
gets pushed from
the asyncio repo to CPython.
On Fri, Nov 20, 2015 at 6:08 AM, Andrew Svetlov
wrote:
> The patch breaks Python 3.3 test by using not existing yet
> TestCase.subTest() call.
>
> On Thursday, November 19, 2015 at 11:40:55 PM UTC+2, Guido van Rossum wrote:
>>
>> T
n Thu, Nov 19, 2015 at 10:06 PM, Guido van Rossum wrote:
>> Thanks!! Try the new patch.
>>
>> I'm not keen on doing the warning any more given how simple it is to
>> just make both idioms work.
>>
>> On Thu, Nov 19, 2015 at 11:28 AM, Andrew Svetlov
&g
ctivity but loop._stopped == True
> I suggest using zero timeout if loop._stopped is set.
>
> I agree that using loop.call_soon(loop.stop) is better but we already
> have loop.stop() usage.
> Removing the later sounds good but requires deprecation period IMHO
> (with raising a warning as
;
>> seems much easier to understand and more logical than:
>>
>> loop.stop()
>> loop.run_forever()
>
>
> I agree.
>
> I think we’re trying too hard to save a broken behaviour. "loop.stop();
> loop.run_forever()” is completely non-obvious, it’s a bad practice to use
> stop/run_forever like this.
>
> Yury
--
--Guido van Rossum (python.org/~guido)
OK, I have uploaded a new patch to http://bugs.python.org/issue25593
that addresses this issue. Please test and let me know!
On Thu, Nov 19, 2015 at 8:44 AM, Guido van Rossum wrote:
> Hm, I wonder if this idiom can actually be saved, as follows:
>
> - When a loop is created its _sto
ckward compatibility break and people will complain
> that asyncio starts hanging in new release but worked perfectly before
> 3.5.1
>
> Personally I can live with that if there is no way to keep current
> loop.stop() approach.
> Maybe we can make `loop.stop()` as shortcut for actual
icating this result, all you need is to
> checkout the websockets repository and run "make test".
>
> Best regards,
>
> --
> Aymeric.
>
>
>
>> On 18 nov. 2015, at 01:35, Guido van Rossum wrote:
>>
>> In this issue: http://bugs.python.org/issue25593 t
freedom an implementation has is
how much of the "ready queue" (callbacks already scheduled with
``call_soon()``) it processes before stopping.
I would love to hear from people who have tried this patch on various platforms.
On Tue, Nov 17, 2015 at 4:35 PM, Guido van Rossum wrote:
Thoughts?
--
--Guido van Rossum (python.org/~guido)
?
> I would like to check if the transport is closed/closing what is the best
> way to do this for both python 3.4 and 3.5?
>
> Regards
>
--
--Guido van Rossum (python.org/~guido)
Vladimir, I would appreciate it if you filed a 3.4 bug -- if you have
a patch that would be even better! Thanks for reporting this.
On Thu, Nov 12, 2015 at 2:01 AM, Vladimir Rutsky
wrote:
> On Mon, Nov 9, 2015 at 11:14 PM, Guido van Rossum wrote:
>> The intention of this code is t
turn_coroutine_object"
>
> When debugging is enabled same code will not work on Python 3.4,
> because result of "g()" is not a generator or Future --- it's debugging
> CoroWrapper.
> Outer asyncio.coroutine will not yield from CoroWrapper and will return
> inner "g()" CoroWrapper.
>
> I made complete example demonstrating this issue:
> <https://gist.github.com/rutsky/c72be2edeb1c8256d680>
>
> This issue is not reproduced in Python 3.5, since CoroWrapper is
> awaitable in Python 3.5,
> but still I can't find is this is a desired behaviour and why?
>
>
> Regards,
>
> Vladimir Rutsky
>
>
--
--Guido van Rossum (python.org/~guido)
; FIFO, random, ...?
>
> Regards,
> Imran
>
--
--Guido van Rossum (python.org/~guido)
ync/await" syntax, "yield" is not even allowed.
> > What is the best way of giving such breaks with new syntax?
> >
> > Regards,
> > Imran
>
>
>
> --
> Thanks,
> Andrew Svetlov
>
--
--Guido van Rossum (python.org/~guido)
we iterate over it?
> that is "natural exception" and it could not exit it properly and created
> another.
>
Yeah, the StopIteration is just the end of the coroutine. It is implicated
because the failing set_result() call occurred in the except clause (in
_step()) that handled that
gt; Thanks!
>
>
> On Wednesday, September 30, 2015 at 11:05:14 PM UTC-4, Guido van Rossum
> wrote:
>>
>> You shouldn't do that. What's happening is that when task() returns the
>> Task class wrapping it tries to set the Task object's result, but since
>
or('{}: {!r}'.format(self._state, self))
>> asyncio.futures.InvalidStateError: FINISHED: > done, defined at test_aio_exception.py:4> exception=RuntimeError('something
>> bad',)>
>>
>
>
> i am sorry in advance if it is just something i don't understand at very
> basic level about asyncio.
>
>
> Regards,
>
> Oleg.
>
>
--
--Guido van Rossum (python.org/~guido)
s of weird network
> issues. )
>
>
>
> On Saturday, September 19, 2015 at 11:39:43 PM UTC-4, Guido van Rossum
> wrote:
>>
>> You should try to figure out first why the connection is lost. Perhaps an
>> error message is being logged somewhere? A possible cause could be tha
t; self._transport.
>
> and whole proto just thinks it finished a handshake but same time it lost
> the transport.
>
>
>
>
> Regards,
> Oleg.
>
--
--Guido van Rossum (python.org/~guido)
d a recvall() method to socket.socket:
> http://bugs.python.org/issue1103213
>
> Victor
>
--
--Guido van Rossum (python.org/~guido)
sult = yield from loop.run_in_executor(None, async('attr1', 'attr2'))
>> return result
>>
>> I am getting the following error : TypeError: 'Task' object is not
>> callable.
>>
>> How can i run a coroutine in a non blocking mode with asyncio ?
>>
>> Thanks.
>>
>
--
--Guido van Rossum (python.org/~guido)
On Mon, Aug 10, 2015 at 7:23 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello Guido,
>
> On 10 août 2015, at 15:32, Guido van Rossum wrote:
>
> Folks, can we stop the testy interaction?
>
>
> Oops — sorry about that.
>
> I'm perso
other server, to try
> to be the most invisible at end user level.
>
>
> In other words you’ve implemented a custom application-level closing
> message because the library you’re using doesn’t implement the
> protocol-level closing handshake. Truth be said, neither did mine until a
> few days ago ;-)
>
> --
> Aymeric.
>
>
>
--
--Guido van Rossum (python.org/~guido)
loop().run_until_complete(sleepWithMainLoopAndNewLoop())
> asyncio.get_event_loop().close()
>
> if __name__ == "__main__":
> main()
>
> -
>
>
> Thanks,
> Chetan
>
>
> On Monday, August 10, 2015 at 5:52:39 AM UTC-4, Victor Stinner
te_subprocess_shell isn't always
> supported, I was wondering if it's possible to check and raise an
> exception in subprocess.Process.wait instead of just hanging forever.
>
> Thanks,
> Chetan
>
>
--
--Guido van Rossum (python.org/~guido)
But the docs could link to the wiki page.
On Aug 8, 2015 1:45 AM, "Victor Stinner" wrote:
> Le 7 août 2015 19:03, "Giampaolo Rodola'" a écrit :
> > I think this should be referenced in the official asyncio doc.
>
> I disagree. This list is moving fast whereas Python doc is moving slowly.
> Some
d then send the heartbeats at the set intervals (resetting the
> interval when a different method is called.)
>
> With coroutines I was able to run them with loop.run_until_complete and
> then return the response messages to the synchronous code. With tasks
> though there doesn&#x
the task though?
>
> On Wednesday, August 5, 2015 at 4:02:24 AM UTC-6, Guido van Rossum wrote:
>>
>> To start a coroutine from a callback, you wrap the coroutine in a Task.
>> That's all. E.g. (untested)
>>
>> from asyncio import coroutine, get_event_loop
>&g
ad
> my client called the loop.stop() method before the interval and closed its
> connection early.
>
--
--Guido van Rossum (python.org/~guido)
exactly(N) help me?
>
> On Friday, July 31, 2015 at 10:12:29 AM UTC-6, Guido van Rossum wrote:
>>
>> Perhaps better to use readexactly(N), which raises EOF instead of
>> returning fewer than N bytes if it hits EOF early.
>>
>> On Fri, Jul 31, 2015 at 5:02 PM, Vict
s to read data
> > that is not line-oriented and is not the whole transmission either.
> > You must use .read(N), where N is a number of bytes. Then you parse
> > what you get and decide on a suitable value of N for the next read.
> > Rinse and repeat.
>
> Exactly.
>
&
from waiter
> +with (yield from self._drain_lock):
> +if not self._paused:
> +return
> +waiter = futures.Future(loop=self._loop)
> +self._drain_waiter = waiter
> +yield from waiter
>
>
> class StreamReaderProtocol(FlowControlMixin, protocols.Protocol):
>
>
I still think that this is a relatively rare case and I don't want to
encourage sharing streams between coroutines. Maybe you can submit a patch
to turn the assert into a RuntimeError?
--
--Guido van Rossum (python.org/~guido)
, a simple solution for ensuring only one coroutine calls
drain() at a time would be to associate an asyncio.Lock with the stream --
then you can do
with (yield from lock):
yield from writer.drain()
--
--Guido van Rossum (python.org/~guido)
an control the buffering in your own OS, you
can't control the buffering in the rest of the network or the receiving
host -- so we don't provide a direct interface to it).
--
--Guido van Rossum (python.org/~guido)
are mixing questions about callbacks and coroutines. Maybe you
are not entirely sure about the difference between the two? They are meant
to be used at quite different levels (in fact, coroutines make progress
mostly when the event loop calls some callback that causes a Task or Future
to become done).
--
--Guido van Rossum (python.org/~guido)
t is pending!" warning on exit.
>
> My understanding is that this should avoid any BaseException handling
> issues since it just stops the event loop and doesn't interfere with
> any running tasks. Is this correct?
>
>
>
> On Tue, May 5, 2015 at 2:57 PM, Guido van Ross
Server.wait_closed is "A coroutine
> that blocks until the service is closed and all accepted requests have
> been handled", so I'm surprised that wait_closed doesn't block until
> the connection is closed. Additionally there doesn't seem to be any
> way of forcing all connections to close (short of adding this logic to
> the coroutine).
>
> Should Server.wait_closed block if there are remaining connections? Is
> it possible to force these connections closed?
>
> Cheers,
> David
>
--
--Guido van Rossum (python.org/~guido)
The wiki pages are preserved in the wiki branch of the repo. If you want to
help putting them back in the github wiki slot I can give you repo access.
On Apr 11, 2015 9:58 AM, "Ludovic Gasc" wrote:
> Hi,
>
> At least to me, the most important wiki page of Tulip project was:
> http://code.google.c
PS. Anyone who was a committer on the google code repo please drop me a
note with your github username so I can add you.
On Fri, Apr 10, 2015 at 4:15 PM, Guido van Rossum wrote:
> OK, the repo is now https://github.com/python/tulip !
>
>
>
> On Fri, Apr 10, 2015 at 11:54 AM, Ludo
> http://www.gmludo.eu/
> On 10 Apr 2015 14:50, "Donald Stufft" wrote:
>
>> I just noticed this, would it make sense to put it under
>> github.com/python ?
>>
>>
>> On Apr 10, 2015, at 2:49 PM, Guido van Rossum wrote:
>>
>> The migr
grate issues:
> https://github.com/arthur-debert/google-code-issues-migrator
>
> Yury
>
> > On Apr 8, 2015, at 3:04 PM, Guido van Rossum wrote:
> >
> > The Google code migration tool claims to migrate issues. You can see how
> far it got in this example repo:: https://git
gt;
>
> On Wednesday, April 8, 2015 at 1:32:40 PM UTC-4, Guido van Rossum wrote:
>>
>> Because Google code is shutting down, I'm about to migrate the Tulip repo
>> to GitHub. I'll post here again once the migration is done.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
--
--Guido van Rossum (python.org/~guido)
lov
wrote:
> Would you migrate wiki pages also?
> Or, please, just enable it for github project -- I'll transfer those
> pages manually.
>
> On Wed, Apr 8, 2015 at 2:47 PM, Guido van Rossum wrote:
> > FWIW, I'm running into issues with the migration. It seems the code
FWIW, I'm running into issues with the migration. It seems the code gets
migrated fine but the issues are migrated incompletely (failing at a
different place each time). I'm giving up for now.
On Wed, Apr 8, 2015 at 10:32 AM, Guido van Rossum wrote:
> Because Google code is shutt
Because Google code is shutting down, I'm about to migrate the Tulip repo
to GitHub. I'll post here again once the migration is done.
--
--Guido van Rossum (python.org/~guido)
On Tue, Mar 24, 2015 at 4:10 AM, Victor Stinner
wrote:
> 2015-03-24 2:44 GMT+01:00 Guido van Rossum :
> > For seekable() I couldn't find any dynamic implemetations,
>
> The first call to io.FileIO.seekable() calls lseek(0, SEEK_CUR).
>
Oops. :(
> It's safer to
> users should just be instructed to use a while loop and readline() until an
> empty result comes back. I'd appreciate comments to my conclusions, from
> the experts. :)
>
Sounds like a plan. This is where I left it with the asyncio.streams API as
well.
> I will say one thing, I've learned a lot about Python 3's file IO stack :)
>
You're welcome!
--
--Guido van Rossum (python.org/~guido)
ly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> | Professor em: http://python.pro.br
> | Twitter: @ramalhoorg
>
--
--Guido van Rossum (python.org/~guido)
r uses yield [from], the consumer will never run. So you must not
be describing the full story.
FWIW I'm fine with the proposal "from queue import Full as QueueFull, Empty
as QueueEmpty". We do a similar thing for the exceptions raised by futures
(CancelledError and TimeoutError ar
. Their main website is
http://aosabook.org/en/index.html, but it looks like 500 lines or less
hasn't made it there yet.
On Wed, Mar 18, 2015 at 11:03 AM, Luciano Ramalho
wrote:
> On Wed, Mar 18, 2015 at 2:39 PM, Guido van Rossum
> wrote:
> > I don't know. We're probably g
ill have to maintain old code,
> and I guess I'm not the only one out there, it would be just one
> error less that might happen.
>
> Greetings
>
> Martin
>
--
--Guido van Rossum (python.org/~guido)
1 - 100 of 433 matches
Mail list logo
