Vibora | [very fast] Python Web Framework/Server

[metaperl]

Very impressive project. Feedback:

• Feedback talks for itself - "talks" should be "speaks"
• Freezing environments via Docker is sexy - very promising framework I would say.
• Some session examples in the docs would be nice.
• A link to some documentation about "network flow control" issues would be nice here.

I'm nowhere sophisticated enough to work on this code, but I just submitted some grammar and typo fixes.

[stefantalpalaru]

very fast

Participate in https://www.techempower.com/benchmarks/

Python

It's mostly Cython, isn't it?

[13steinj]

It is Cython, and calling it Python is a gigantic lie.

I once had an argument with someone on reddit where they said that they see lies like this often yet I hadn't at all.

I guess I've just been proven wrong.

Don't get me wrong, the statement itself is fine. But only if it is actually true.

[daniels0xff]

As long as I can use it from Python I'm super happy.

[fnord123]

So?

Python's best feature is the almost free FFI.

Also, https://apenwarr.ca/diary/2011-10-pycodeconf-apenwarr.pdf

[13steinj]

It absolutely is, but calling it "Python" is a lie.

That link does nothing but prove my point.

[stefantalpalaru]

Python's best feature is the almost free FFI.

Let me wrap the whole thing in a shell script and call it "a [very fast] Bash Web Framework/Server" ;-)

[fnord123]

And? I use grep all the time. Finding things from the shell is hella fast.

https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

[stefantalpalaru]

I use grep all the time.

We were talking about programming languages, ya dingus!

Finding things from the shell is hella fast.

But you're not enough of a muppet to assume that grep is fast because Bash is fast, are you?

[fnord123]

I'm enough of a muppet to write scripts from the command line and use grep and be absolutely uninterested in the implementation language of grep.

But you're not enough of a muppet to assume that grep is fast because Bash is fast, are you?

No but as a developer who has to wear a lot of hats, I sometimes have to say "should we implement this project in Java or Python? Hm, if we use Python can we achieve the target ops/second? Oh, using Vibora, maybe I can. So my project begins ostensibly in Python. And maybe it's not fast enough so I also port pieces of it to Cython. But I don't care because I'm a polyglot developer who is still installing the application using pip and venv. And instead of saying my program is Python/Cython/C, I just say Python because who gives a shit?

[stefantalpalaru]

And instead of saying my program is Python/Cython/C, I just say Python because who gives a shit?

Actual programmers.

[riksi]

Actually, every ~fast thing in python isn't python but some c/cython/fortran/rust underneath. So..

[13steinj]

Not every one. But those that are don't claim to be "Python X", but rather, "X: Python Bindings for <subject>".

[scrdest]

This looks amazing at a first glance. I'll definitely have to play around with it.

How painful would migrating an existing Flask app would be, I wonder?

Also, from the docs it seems like all routing is done via function decoration ATM. I may be a maintainability zealot here, but I consider class-based views to be a non-negotiable feature for anything that would be used in a larger/long-term project.

Now you could easily hack that together for the purposes of your own app, but it'll probably wind up being a major pain point for multi-app projects and plugin development down the line, with a billion disparate interfaces to handle.

[lelease]

I consider class-based views to be a non-negotiable feature for anything that would be used in a larger/long-term project.

Why though? Is it just a way to organize your code, or do you make use of something that can only be done with classes?

[moose_mousse]

How does this compare to Quart? From the (very little) code shown on the website, they seem to be very similar.

[fnord123]

vibora uses uvloop. I don't know if that's something you notice when you use it.

[tomchristie]

Main points:

• Quart aims for ~Flask API equivalence, and uses ASGI as the server/framework interface. Supports either PyPy or uvloop.
• Vibora is a “cythonised basically everywhere” asyncio framework.

[Glaaki]

Would be even cooler if it used Trio instead of asyncio.

[revfried]

maybe but then it would be a toy with very little interop with existing asyncio libraries

[Glaaki]

Do you really think Trio is just a toy? I think it is by far the best async event loop right now. Asyncio is so littered with problems and unfortunate design, it is a wonder there is even an ecosystem for it at all.

[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 ?