1st1

32 ms·

361.
by 1st1 10y ago
uvloop is meant to work with asyncio, which requires Python 3. So there is no point in supporting Python 2 (and trollius isn't maintained anymore).
362.
by 1st1 10y ago
Pleased to see a uvloop link here again ;) I'm the author, feel free to ask questions. I also recommend to read our blog posts about uvloop and asyncio on magic.io
363.
Envoy: C++ L7 proxy and communication bus by Lyft(lyft.github.io)
3 points by 1st1 10y ago|0 comments
364.
Python 3.6 beta1 is here(mail.python.org)
2 points by 1st1 10y ago|0 comments
365.
by 1st1 10y ago
Totally :) I'm the author of the PEP, btw. Will be glad to answer questions.
366.
PEP 530: Asynchronous Comprehensions in Python 3.6(python.org)
7 points by 1st1 10y ago|3 comments
367.
by 1st1 10y ago
We'll find a way. Worst case it's possible to rewrite it using cffi.
368.
by 1st1 10y ago
> I think it would be beneficial if you would split your project in 2, separating the IO from the rest (like hyper does https://github.com/Lukasa/hyper ). I'd like to do that, but we don't have resources.
369.
by 1st1 10y ago
I usually debug the generated C code directly (usually it's quite easy to understand the bug once you see where the program crashes.)
370.
by 1st1 10y ago
I use SublimeText with a Cython highlighter; @redcrowbar uses Atom. I started coding uvloop & asyncpg directly in Cython, basically from scratch. Debugging & refactoring are pretty much as easy as for pure Python code (which is a h
371.
by 1st1 10y ago
Should be. AFAIK psycopg2 works with Redshift just fine, so should asyncpg. The only thing I'm not sure about is what kind of authentication mode Redshift is using. asyncpg doesn't support all of them, but that's easy to fi
372.
by 1st1 10y ago
> I think you should open a bounty for it. As questions like "Can I use this with Django/SQLAlchemy/…?" showed, people love drop-in replacements that speed up their code, especially when it is at a low level like this
373.
by 1st1 10y ago
A lot of code in asyncpg is datatypes parsers, buffer abstractions, API facade and other IO independent things. So good news is that it would be possible to reuse a lot of code. Protocol is implemented in two layers -- the base layer is IO
374.
by 1st1 10y ago
> right, so my suggestion is, keep the DB code in a thread pool. So you can use the async for your 1000-client frontend and not force it into the DB layer where it makes things much more complicated (or what I do, just use gevent :) ). L
375.
by 1st1 10y ago
> If you write a program that has thousands of persistent websockets open, you do not want all those thousands of connections to each have their own, persistent, long lived database transaction. [..] Mike, I've never suggested to ha
376.
by 1st1 10y ago
>> If you have to manage 100-1000s of connections > Which I said, usually you are not. Postgresql connections are expensive. You do not want 100s-1000s. I was talking about a micro-service that has to support a lot of connections
377.
by 1st1 10y ago
Yeah, documenting internals sounds like a good idea. At least to make it easier for people to contribute and further improve asyncpg. We'll try to find some time to do that.
378.
by 1st1 10y ago
> The TL;DR; for my blog post you mention is that async itself usually has little to do with speed when talking to a database, because the database is typically on the same network as your application, you're using typically no more
379.
by 1st1 10y ago
Theoretically yes, but it would require is to seriously re-architecture the protocol implementation to support several IO modes.
380.
by 1st1 10y ago
Consider making a PR to https://github.com/MagicStack/pgbench :)
381.
by 1st1 10y ago
asyncpg was designed for asyncio (and async/await). So it can be used in any asyncio, Tornado (and soon Twisted) program. Django doesn't support asyncio, it's built for blocking IO model. So, unfortunately, it's not po
382.
by 1st1 10y ago
We've open sourced asyncpg just a couple of weeks ago, and right now it has a beta status. Not that we're aware of any bugs in it or plan to add a lot of new features. So I guess you should give it a try, carefully ;)
383.
by 1st1 10y ago
We haven't benchmarked this specific use case. However, cursors in asyncpg do data prefetching (the exact number of prefetched rows is configurable), so I expect that asynchronous iteration should be pretty fast (and still faster than
384.
by 1st1 10y ago
Python and nodejs applications are usually deployed in a multiprocess configuration (and Go apps without GOMAXPROCS). So in production, applications in all of those languages use all CPU cores. For benchmarks, we didn't want to compli
385.
by 1st1 10y ago
Yep, it's also much more stable now, 3 months after that article was posted. I plan to make a new blog post about it soon.
386.
by 1st1 10y ago
asyncpg was developed by @redcrowbar and me. Ask us anything ;)
387.
Show HN: 1M rows/s from Postgres to Python(magic.io)
296 points by 1st1 10y ago|89 comments
388.
by 1st1 10y ago
I'm the PEP author. Feel free to ask questions ;)
389.
Python 3.6 proposal, PEP 525: Asynchronous Generators(python.org)
8 points by 1st1 10y ago|1 comments
390.
K Lars Lohn – must watch keynote - PyCon 2016(youtube.com)
3 points by 1st1 10y ago|0 comments

More ›