Re: [python-tulip] Re: Calling coroutines within asyncio.Protocol.data_received

Hi Antoine, In the meanwhile, I got Autobahn running on Python3/asyncio. Here is a complete example of WebSocket client and server, running on asyncio https://github.com/tavendo/AutobahnPython/tree/master/examples/asyncio/websocket/echo and running on Twisted

Re: [python-tulip] Re: Calling coroutines within asyncio.Protocol.data_received

Why not us an asyncio queue so you can just have a loop in a task instead of a recurring task? Ah, ok. Thanks! I need to read up on asyncio queues. Also: Autobahn now works with above design (and I have 95% shared code between Twisted and asyncio), but is this how you intended asyncio to be

Re: [python-tulip] Calling coroutines within asyncio.Protocol.data_received

What I was thinking of was actually a lower level of the HTTP infrastructure, where you have to write something that parses the HTTP protocol (and things like form input or other common request content types). I'm personally pretty happy with the pull style HTTP parsing I wrote as an example

[python-tulip] AutobahnPython 0.7.0 released: supports Python 3 and asyncio

Hi, I am happy to announce the release of AutobahnPython 0.7.0 https://github.com/tavendo/AutobahnPython https://pypi.python.org/pypi/autobahn This release now fully supports (with all Autobahn features) both Twisted (on Python 2/3) and asyncio (on Python 3.3+). Here is an example that

Re: [python-tulip] Calling coroutines within asyncio.Protocol.data_received

And a transport deriving from asyncio.transport.Transport (a stream) might be in fact unreliable? I don't see any useful semantics for that. It was more an example for why mere API (what functions with what parameters) and implied semantics are somewhat orthogonal. The same API

Re: [python-tulip] Creation of the new Trollius project

Hi Victor, I've added support for Trollius in Autobahn 0.7.3 https://github.com/tavendo/AutobahnPython#python-support pip install autobahn[asyncio] will - as a dependency - install Trollius on Python 2, Tulip on Python 3.3 and nothing on Python 3.4+. Awesome! Cheers, /Tobias

Re: [python-tulip] Creation of the new Trollius project

* Trollius coroutines must use raise Return(value), whereas Tulip simply Could you explain why that particular construct of returning by raising was chosen? It works, but looks strange ..

Re: [python-tulip] Creation of the new Trollius project

Not sure I fully get it: Twisted's `inlineCallback` use regular raise for exceptions, but a special `returnValue` function for returning https://github.com/tavendo/AutobahnPython/blob/master/examples/twisted/websocket/slowsquare/server.py#L36 Is that a third alternative? [not a rhetorical

[python-tulip] RPC + PubSub for asyncio

Hi, I am happy to announce that https://github.com/tavendo/AutobahnPython now fully supports both WebSocket and WAMP on asyncio. WAMP (http://wamp.ws) is an application protocol that provides RPC (remote procedure calls) and PubSub (publish subscribe) messaging patterns. WAMP can run over

[python-tulip] Re: Trollius 0.3 beta: module renamed from asyncio to trollius

Hi, I missed that discussion. IMHO, the renaming further complicates matters, since now selecting networking library must be done consistently in both library and app code. E.g. if we add try: # Use Tulip on Python 3.3, or builtin asyncio on Python 3.4+ import asyncio except

Re: [python-tulip] Release of Trollius 1.0

I'm very happy to announce the release of Trollius 1.0: Oh, great! Congrats on this Victor! /Tobias

Re: [python-tulip] Writing unit tests for user code

So I guess what I am after is six for asyncio/Twisted ;) Isn't six for asyncio/Twisted covered by the fact that you can implement one event loop in terms of another? Idiomatic asyncio code Yep, wrapping a network library for some protocol written for network framework X for users to run

Re: [python-tulip] Re: Writing unit tests for user code

Am 25.07.2014 13:21, schrieb Victor Stinner: 2014-07-25 11:30 GMT+02:00 Luca Sbardella luca.sbarde...@gmail.com: Pulsar has an asynchronous testing framework too http://quantmind.github.io/pulsar/apps/test.html It uses the unittest.TestCase class from the standard library but can handle test

Re: [python-tulip] Writing unit tests for user code

In Twisted, there is Trial, which provides an extended version of unittest.TestCase with this feature: The main unique feature of this testing class is the ability to return a ​Deferred from a test-case method. A test method which returns a snip I strongly recommend you reconsider doing

Re: [python-tulip] Writing unit tests for user code

And: I'm sure Twisted developer's will have reasons for frowning upon tests returning deferreds, but could you recap shortly why? It has the classic problem with bad tests: reliance on global state which is not controlled by the test. Unit tests should be isolated, they should not affect or

[python-tulip] AutobahnPython: deprecate Python 2 / asyncio? Any real-world use?

or later) deprecate supporting that combination as well. If you have an app using the combination, now would be a good time to speak up;) Cheers, /Tobias Am 25.01.2016 um 22:06 schrieb Victor Stinner: Hi, 2016-01-25 21:57 GMT+01:00 Tobias Oberstein <tobias.oberst...@gmail.com>: Au

Re: [python-tulip] Process + Threads + asyncio... has sense?

Am 18.04.2016 um 21:33 schrieb Imran Geriskovan: On 4/18/16, Gustavo Carneiro wrote: I don't think you need the threads. 1. If your tasks are I/O bound, coroutines are a safer way to do things, and probably even have better performance; Thread vs Coroutine context

Re: [python-tulip] Process + Threads + asyncio... has sense?

Sorry, I should have been more explicit: With Python (both CPython and PyPy), the least overhead / best performance (throughput) approach to network servers is: Use a multi-process architecture with shared listening ports (Linux SO_REUSEPORT), with each process running an event loop

Re: [python-tulip] Process + Threads + asyncio... has sense?

Am 19.04.2016 um 23:02 schrieb Imran Geriskovan: A) Python threads are not real threads. It multiplexes "Python Threads" on a single OS thread. (Guido, can you correct me if I'm wrong, and can you provide some info on multiplexing/context switching of "Python Threads"?) Sorry, you are wrong.