Re: [python-tulip] asyncio.wait(FIRST_COMPLETED) returns more than one completions - 3.4rc2

A typical scenario... Stateful resources recycled among multiple consumers. Shortcut above seems nice on screen. Imran

[python-tulip] TLS/SSL Wrapping

Hi, Normal sockets can be created, used for some communications and then they may be wrapped with a SSLContext to proceed in encrypted mode. How can such a sequence be executed using asynio? Mode of communication is determined at creation time (ie. when calling 'open_connection'). Is there any

Re: [python-tulip] TLS/SSL Wrapping

Thanks for the quidance. selector_events.py : _SelectorSslTransport : __init__ wraps the socket and postpones handshake. There is not much asyncio terms here.. Then it delegates to '_on_handshake' which has much of the asyncio stuff.. However, 'Under the hood' modification you've pointed is

[python-tulip] TLS handshake exception. Bug/Comments/HeartBleed?

This code snippet throws exception below: ctx = create_default_context() co = open_connection(ip, port, family = AF_INET, ssl = ctx, server_hostname = host) yield from co Throws: - ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:598) - Or sometimes Unknown CA

Re: [python-tulip] TLS handshake exception. Bug/Comments/HeartBleed?

Honestly, I do expect some misconfiguration on my side but I couldn't track it down to the source. So I want to make sure I'm the only one with such a problem. The machine is an up to date Debian Sid with all fresh updates. sources.list: deb http://ftp.debian.org/debian unstable main contrib

Re: [python-tulip] TLS handshake exception. Bug/Comments/HeartBleed?

Thank you. Results for echo | openssl s_client -CApath /etc/ssl/certs/ -connect static.licdn.com:443 | grep 'Verify return code': www.linkedin.com:443 OK static.licdn.com:443: Verify return code: 20 (unable to get local issuer certificate)! That's parallel to what asyncio also says.

[python-tulip] SSL HandShake / Dynamic Certificates

One can start a SSL server with a static certificate like this: ctx = create_default_context(Purpose.CLIENT_AUTH) ctx.load_cert_chain('pem.crt') async(start_server(handle, host, port, family=AF_INET, limit=8192, ssl=ctx)) However, if you need to use dynamic certificates, you must have access to

Re: [python-tulip] SSL HandShake / Dynamic Certificates

What is a dynamic certificate? Victor Certificates are not Dynamic after all. It is providing different certificates to different accepted clients by SSL server. Pre-Asyncio era code is here: ctx = create_default_context(Purpose.CLIENT_AUTH) ctx.load_cert_chain(pem1.crt') # or pem99.crt s =

Re: [python-tulip] Is async object creation supported?

So asynchronous object creation should be done by a factory coroutine, and not by calling the standard constructor machinery. It may be done by a factory or a second async helper function method or by any other creative method. However, they all make the the code more bureaucratic. Elegance of

[python-tulip] Is async object creation supported?

Or am I doing something wrong? X does not run. Y runs. Thanks for comments.. x = yield from X() # Does not work y = Y() # Works.. yield from y.init() class X: def __init__(): yield from some async code class Y: def __init__(): some sync code def

Re: [python-tulip] Re: Cost of async call

rde...@gmail.com> wrote: > > On Thursday, November 12, 2015 at 5:16:22 PM UTC, Imran Geriskovan wrote: >> >> What is the cost/overhead difference >> between these calls? >> >> await foo1() >> foo2() >> >> async def foo1(): >>

Re: [python-tulip] Asynchronous console and interfaces

>> Regarding the "stream style", I can share some of my >> experience: >> >> For code below, other than some limited portion >> and awaits, can you see any line specific to asyncio? No? >> >> Well that's the point. With some little search replace, >> and tweaks it can easily be transformed into >>

Re: [python-tulip] Add Timeout class to asyncio

Async/Sync Context Managers are especially neat for Stream Style development. They make such organization possible and comprehensible. i.e: async with resp.send(): with Page(resp, title): with Form(resp, postpath): self.menu(resp) await nav(resp, dpath, fname)

[python-tulip] Async Process

Below you can find async SubProcess class which derives from Stream Class send previously. Features: 1) Process Pipes (See Example) 2) ContextManager style usage (See Example) I would like to hear your experiences regarding SubProcess usage patterns. I'll be glad if a similar approach is

[python-tulip] Async Constructor (__ainit__)

Currently class instances can not directly be created asyncronously. Yes, there are other means for async creation. (As we have discussed before, factories, __new__ is a coroutine, etc) However, having all creation logic, under the class definition and similar to __init__ is more elegant.

Re: [python-tulip] Async Constructor (__ainit__)

Did you mean this? : aresult = await someafunc() # Good aobject = await AClass() # Bad!! bobject = await somefuncreturningBOjbect() # Good??? Interesting. What is the difference? Is it python's duty to make Bad! style, anti-patterns impossible? I think there is no relation between

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

On 4/25/16, cr0hn cr0hn wrote: > I uploaded as GIST my PoC code, if anyone would like to see the code or > send any improvement: > https://gist.github.com/cr0hn/e88dfb1fe8ed0fbddf49185f419db4d8 > Regards, Thanks for the work. >> 2) You cant use any blocking call anywhere in

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

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 switching is an interesting topic. Do you have any

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

>>> 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 switching is an interesting topic. >> Do you have any data for comparison? > My 2cts: > OS native

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

> This is a very simple example, but it illustrates some of the problems with > threading vs coroutines: >1. With threads you need more locks, and the more locks you have: a) the > lower the performance, and b) the greater the risk of introducing > deadlocks; > So please keep in mind that

Re: [python-tulip] Curio

>> I'd be happy to see Curio in std library.. > Dave has repeatedly stated that he's not interested in maintaining > Curio long term or keeping the API stable. That means it's not going > to happen. It might make more sense to propose carefully designed > additions to asyncio that aim to fill in

[python-tulip] Curio

As I noted in my previous posts in this group, I mostly try keeping async code with parity of blocking code. (Reasons: Ease of streams based development, Easy migration to compiled langs, threads, etc, etc..) For couple of months I've been playing with Curio, to which now I'm a total convert.

Re: [python-tulip] Curio

>> As I noted in my previous posts in this group, >> I mostly try keeping async code with parity of >> blocking code. (Reasons: Ease of streams based >> development, Easy migration to compiled langs, >> threads, etc, etc..) >> >> For an async code based on Curio, you can almost >> drop all