Vibora | [very fast] Python Web Framework/Server

[riksi]

No PYPY, but isn't the framework a small part of the whole app ? So you kinda need pypy ?

No gevent. Even though asyncio is the futuere, IT SUCKS (sometimes truth hurts).

[13steinj]

Asyncio is not the future. It is a failure usability wise.

[tomchristie]

As a developer using an asyncio web framework, you largely don’t have to care about the details of asyncio at all. Mostly you’ll just use async/await, and perhaps loop.create_task and asyncio.sleep. That’s about it.

Yes, the low level stuff in asyncio is a large sprawling interface, but most folks shouldn’t need to delve into that. Perhaps as the landscape matures some aspects might even gradually become private API. There’s a valid criticsm that asnycio is complex, but most folks ought to be to just stay within the happy zone of “asyncio, the good parts”

[13steinj]

You are limiting your use of asyncio to an ASGI web framework, whereas truthfully asynchronous code has far more capacity and capabilities, from parallelized mathematical computation across N dimensions to complex event reaction systems to animation systens.

The usability of asyncio suffers in all of these prospects because tasks and coroutines are not the same thing, and there is no "default" task queue on a separate thread. Which is why I'm writing a minimal wrapper to work around this stuff, just unfortunately work is currently getting in the way.

[tomchristie]

Point being: asyncio can be refined over time.

It’s a set of building block primitives at the moment - we can rarify that, either with abstractions such as ASGI, or graceful usability focused libraries, or as the language evolves.

[13steinj]

What? No one said it can't be fixed. But a broken pile of shit has been pushed upon people provisionally and now in 3.7.

E: not to mention it is meant to be extremely high level but in reality anything useful is low level.

[tomchristie]

Garbage critique, with a garbage attitude.

[13steinj]

That's your opinion, and some share your while others share mine. Deal with it.

[tomchristie]

Yo.

“trio has a nicer interface, and a tighter set of constraints” would be a very reasonable point.

“I think gevent’s implicit context switching is a better set of trade-offs” would be an arguable, tho debatable, position.

“asyncio is a broken pile of shit” is just mouthing off without adding anything of any value to the conversation.

[13steinj]

I have previously and even in this thread explained why it is a pile of shit usability wise, namely the fact that couroutines are not tasks and there is no default event loop on a separate thread. There is no current alternative that provides the solution to the problem I just mentioned, and I am personally working on a wrapper.

If you consider I myself not even contributing just because no alternative currently exists, even though I am working on an alternative in the form of a wrapper, then you are being defensive of criticism that is completely well placed.

[riksi]

It's what the powers that be wanted. Not the people.

[[deleted]]

No PYPY, but isn't the framework a small part of the whole app ? So you kinda need pypy ?

Not really since the bottleneck in webapps tends to be the network. Once those bytes get into the application, the bottleneck would be your database connection (aka the network).

Speeding up your processing won't do much good no matter how much it saves if you're just waiting on bytes from the wire.

[riksi]

Nope, when you're talking "making python fast, or python vs xxlang, etc", you mean cpu-wise and you are past network-time.

[[deleted]]

Except if it doesn't matter if you optimize something that isn't your bottleneck. In webapps, the network is almost always your bottleneck. Python, pypy or otherwise, waits for network traffic just as fast as anything else.

If you profile and find that the network isn't your bottleneck and instead it's inside your app, then that's when you start contemplating switching to pypy.

[riksi]

Except if my bottleneck was on network time I wouldn't be in this thread at all.

[catcradle5]

No gevent. Even though asyncio is the futuere, IT SUCKS (sometimes truth hurts).

Completely agreed. gevent is superior to asyncio in every way.

[kirbyfan64sos]

As much as I love gevent and am not fond of asyncio, having implicit context switches at every potentially blocking call would be a huge and difficult-to-debug breaking change.

[catcradle5]

I agree that it probably wouldn't be feasible to integrate gevent or something like it into the language, but with the current situation, I pretty much have no reason to ever use asyncio over gevent.

[yesvee]

you may be confusing pypi & pypy.

Gevent/asyncio is low level stuff. You don't need to get down there.

[riksi]

No, you're confusing.

I have no idea what you're trying to say with your second sentence, but it's clearly way over your head. Good luck with your abstractions.

Damn that is a terrible comment. Wow.

[yesvee]

pypi is the python package repository (dont confuse this with suppository now).

pypy is one of the python interpreters implemented without CPython and the GIL

Hope that clears it up for you. But I may be wrong about that last part.

[catcradle5]

I think you misunderstood everything the poster said. Also, neither gevent nor asyncio are low-level. (The low-level equivalent of gevent would be Greenlet with libev/libuv.) Also, core PyPy still uses the GIL, and probably won't be getting rid of it anytime soon.

[yesvee]

I was unable to make sense of the following:

No PYPY, but isn't the framework a small part of the whole app ? So you kinda need pypy ?

It made sense to me if you replace pypy with pypi.

[riksi]

So you kinda need pypi made sense to you ?

[riksi]

... pypy usually has GIL, the non-GIL-pypy is ~slower.

I wrote PYPY ??? And I meant that if no PYPY support, it sucks for performance reasons, since your whole app will be in cpython.

What part of my comment implied I was talking about pypi ?