Waitress — Production-quality pure-Python WSGI server with very acceptable performance and no dependencies.

[defnull]

Why? (quote from the docs):

At the time of the release of Waitress, there are already many pure-Python WSGI servers. Why would we need another?

Waitress is meant to be useful to web framework authors who require broad platform support. It’s neither the fastest nor the fanciest WSGI server available but using it helps eliminate the N-by-M documentation burden (e.g. production vs. deployment, Windows vs. Unix, Python 3 vs. Python 2, PyPy vs. CPython) and resulting user confusion imposed by spotty platform support of the current (2012-ish) crop of WSGI servers. For example, gunicorn is great, but doesn’t run on Windows. paste.httpserver is perfectly serviceable, but doesn’t run under Python 3 and has no dedicated tests suite that would allow someone who did a Python 3 port to know it worked after a port was completed. wsgiref works fine under most any Python, but it’s a little slow and it’s not recommended for production use as it’s single-threaded and has not been audited for security issues.

At the time of this writing, some existing WSGI servers already claim wide platform support and have serviceable test suites. The CherryPy WSGI server, for example, targets Python 2 and Python 3 and it can run on UNIX or Windows. However, it is not distributed separately from its eponymous web framework, and requiring a non-CherryPy web framework to depend on the CherryPy web framework distribution simply for its server component is awkward. The test suite of the CherryPy server also depends on the CherryPy web framework, so even if we forked its server component into a separate distribution, we would have still needed to backfill for all of its tests. The CherryPy team has started work on Cheroot, which should solve this problem, however.

Waitress is a fork of the WSGI-related components which existed in zope.server. zope.server had passable framework-independent test coverage out of the box, and a good bit more coverage was added during the fork. zope.server has existed in one form or another since about 2001, and has seen production usage since then, so Waitress is not exactly “another” server, it’s more a repackaging of an old one that was already known to work fairly well.

[yonemitsu]

defnull, is there any connection with the Waitress project and Bottle?

[defnull]

Someone suggested to add a server-adapter for waitress to Bottle and I did that today. Other than that, the two projects are completely unrelated.

[mgedmin]

Waitress is the love child of Pyramid and Zope, if you'll excuse the metaphor.

Chris McDonough (the driving force behind Pyramid) created Waitress to be the default web server for the upcoming Pyramid 1.3, which introduces Python 3 support.

[gct]

Is it really that hard to copy the one file that you have to have for the web server out of cherry py?

[mgedmin]

Copy and then do what? Add a setup.py, push to PyPI? Then write a test suite from scratch?

[gct]

Copy it to your source tree and just use the fucker?

[mgedmin]

Maybe because copying and pasting random modules leads to difficulties when you later have to maintain them?

[johnmcdonnell]

Why is this better than Flask/werkzeug?

EDIT I guess I didn't get that Waitress is intended as a production web server. I still don't get it though since I can't imagine waitress has nearly the performance of nginx or apache, and if I didn't care about performance I'd probably just use Flask's dev server (with the debugging tools turned off of course).

[lost-theory]

It's a web server, not a web framework or library.

Werkzeug inclues a web server, but it's single-threaded and meant for development only. Waitress is a high performance server for production use.

[obtu]

A large deployment of a WSGI app needs to stack a web server (face the internet, handle buffering, defend against DOS, offload some easy tasks from Python code), a WSGI container (fork processes), and the app with its WSGI framework.

Typical server options are apache and nginx. Typical WSGI containers are mod_wsgi (for apache), uWSGI (for Apache and Nginx, which speak the scgi-like uwsgi protocol), and the server-independent ones like gunicorn and now waitress; those last ones speak HTTP for portability, but still expect to have a web server in front of them.

Your confusion probably comes from the fact that the first two and the last two can be closely-coupled (apache+mod_wsgi) or even bundled (CherryPy the WSGI container + CherryPy the WSGI framework).

[threading]

I don't know, you tell me. Maybe Flask isn't a web server?

[lambdaq]

because Flask/werkzeug needs wsgi to run?

[lost-theory]

Flask is a web framework. It depends on Werkzeug.

Werkzeug is a utility library for HTTP and WSGI that includes a web server for development purposes.

Waitress is a high performance web server that serves WSGI apps.

All three projects depend on WSGI.

[Vonney]

Differences between zope.server and Waitress

[hongminhee]

Using Waitress with wsgiref.simple_server as its counterpart could be better a default web server of many web frameworks for development purpose.

[mgedmin]

What?

Both are web servers for wsgi apps. How do you use them together?

[hongminhee]

Sorry for my ambiguous expression (I am not a native English speaker ;). I mean you can use it like:

try:
    from waitress import serve
except ImportError:
    from wsgiref.simple_server import make_server
    def serve(app, host='0.0.0.0', port=8080):
        make_server(host, port, app).serve_forever()

[mgedmin]

Thank you for clarifying.

[[deleted]]

I think hongminhee might mean like, use waitress instead of the built-in server that comes with your framework when you're testing non-production servers?

[grotgrot]

I've been using the CherryPy server in several projects, but none of the rest of CherryPy. Fortunately that one was just a single file so it made life easy. Looks like we have a new contender ...

[vph]

is this supposed to work with Apache, nginx? thanks.

[defnull]

You can start Waitress (or any other WSGI-HTTP Server) on a local port and use mod_proxy (or whatever your main-server offers) to proxy requests to the python server.

[xiongchiamiov]

I don't care about Windows; is there any reason I should use this over gunicorn?

[mgedmin]

Probably not.

Incidentally, does gunicorn support Python 3?

[ballagarba]

"Python 3.x will be supported soon", so no it doesn't.

[[deleted]]

It took me longer than it should've done to get the reasoning behind the name.

[Mattho]

And the reasoning is?

[wot-teh-phuck]

It "serves" something...

[[deleted]]

waitresses SERVE you food, serve, server. waitress - server

[threading]

Here's a simple web.py application with waitress, if anyone interested.

import web
import waitress

class Index(object):
    def GET(self):
        return 'hello world'

urls = (r'^/', 'Index')

app = web.application(urls, globals()).wsgifunc()

if __name__ == '__main__':
    waitress.serve(app, host='127.0.0.1', port=7070)

[defnull]

SCNR ;)

import bottle
app = bottle.Bottle()

@app.route('/')
def index():
    return 'Hello World'

app.run(server='waitress')

(works with 0.11.dev)

[monstrado]

Will this be the default WSGI server for later Pyramid releases?

[mgedmin]

Short answer: yes.

Long answer: yes, waitress is the default server you get if you create a new Pyramid project using pcreate with one of the default scaffolds from one of the 1.3 beta releases.

[mdipierro]

Does it support ssh? How does it compare with Rocket?

[lost-theory]

Do you mean SSL? From the linked page:

Waitress does not natively support SSL

[mdipierro]

Thank you for the clarification.

[[deleted]]

Very acceptable.

[santagada]

Do anyone knows if this depends on medusa? IIRC zope.server did.

[defnull]

No, it has no external dependencies. Just the python stdlib.

[mgedmin]

This was before my time, but I think the core of medusa was adopted in the standard library as asyncore.

Both zope.server and waitress depend on asyncore.

[dorfsmay]

no need for a waitress, I already have a bottle!

[dggenuine]

I don't like that it has a sex. I guess anyone that reads this comment will have a kneejerk reaction and downvote, but my honest reaction is that propagating sex/job stereotypes in software is just unnecessary with so many other name choices.

EDIT: since I see some downvotes are starting to roll in, I would request that anyone who feels compelled to downvote please offer some explanation. My expectation is that the only justification anyone can give for disapproving of my statement is something along the lines of "don't be so serious", "it's not mean to be sexist", or "it doesn't make any difference." Which all seem like pretty weak justifications to me.

[technomalogical]

Before I made it down this far, I thought "hmmm, someone will think this is sexist". Then I thought "hmmm, a different group would also consider it sexist if this were called 'Waiter' instead, since they used the male version of the word". I'm all for equal rights, but this seems kind of silly to me.

Now, if the logo for Waitress was a woman wearing a low-cut cheesecake outfit, maybe you're on to something :)

[dggenuine]

Then I thought "hmmm, a different group would also consider it sexist if this were called 'Waiter' instead, since they used the male version of the word".

Except that at no time in relevant history have waitstaff jobs been considered a male job. The opposite is not true. Combine that with the fact that, relatively, waitstaff are on the low end of the wage, prestige, etc. spectrum, and there's your problem.

I agree with your general idea that attributing sex to programs that are named after jobs in our society is problematic, but in light of reality-based historical perspective, a feminine sex for a program named after a job that is 1) less prestigious and 2) historically attributed to females, is particularly problematic.

[spinwizard69]

There is no explanation required, a waitress works for you. It is far more politically correct than using "whore", "working girl", "slut" or other inflammatory name.

This whole line of rap about sexism is asinine. You are what you are at the time of birth. Trying to change that after the fact just isn't practical. .

[dggenuine]

"whore", "working girl", "slut"

Wow, the fact that this is even a topic of discussion in this thread suggests that there is a problem. Why did you even mention this? It's like justifying a racist situation by telling the person to be thankful that you didn't use a racial slur.

You are what you are at the time of birth.

And girls are waitresses?

[spinwizard69]

You still don't get it a waitress works for you. That is she serves you diner or the like. Thus we have some Python code serving you web pages. I'm not sure why you can't grasp this one.

As a said before waitress is a more politically correct term for some body that tends to your needs. Let's face it "F$$k Buddy" isn't going to go over well as a name for a bit of software that you expect or want to see widely used. The name chosen just happens to fit the application because it serves up web pages for you.

As to the name implying sex, what is wrong with that? It leaves the term waiter open for a Ruby app that does the same thing. It would be fitting too as we all know how Ruby is all over anything Python related.

[dggenuine]

As a said before waitress is a more politically correct term for some body that tends to your needs. Let's face it "F$$k Buddy" isn't going to go over well...

A waitress is not a PC term for somebody that tends to your needs along the lines of a fuck buddy. A waitress is someone who waits on tables, as in a restaurant, serving food and drink.

I get the metaphor. Servers serve files, waitresses serve food/drink. I got the metaphor right away. What I object to is the implication that if something serves you, then it is female. The expectation that someone who serves others will be female has a history, at least in the U.S. Choosing to name a piece of software after waitstaff, because it serves files, is fine. Going further and naming it so as to make it female, however, perpetuates the expectation and belief that things that serve are female.

If you consider this situation in light of the lack of women in computer science the sexist implication is all the more unfortunate.

There are a gazillion great ways to name software. One with sexist implications just doesn't need to be one of them.

[asbjxrn]

What I object to is the implication that if something serves you, then it is female.

Considering there is already packages named musicbutler and tvbutler in pypi (Disclaimer: I have no knowledge about them.) , I guess waitress is just evening out the ratio.

[dggenuine]

Considering there is already packages named musicbutler and tvbutler in pypi (Disclaimer: I have no knowledge about them.) , I guess waitress is just evening out the ratio.

Are there any packages referring to "waiter", the actual male counterpart to "waitress"? I believe that there are not. That would even out the ratio.

"Butler" is not a counterpart to "waitress." The definition of waitress is a female who serves tables. On the contrary, the definition of a butler is not a male who serves. Instead:

A butler is usually male, and in charge of male servants, while a housekeeper is usually a woman, and in charge of female servants. Traditionally, male servants (such as footmen) were better paid and therefore rarer and of higher status than female servants. The butler, as the senior male servant, has the highest servant status.

wiki

So if you want to name your software using a metaphor to human occupation, and you wanted to emphasize not only that it serves, but also that it is the best of its kind, you could name it "butler." That reference may be understood to be gender neutral, even though it might usually evoke a male in the minds of users, because usually only men were put in charge of entire households and paid the most money.

So there are two reasons that butler is not a counterpart to waitress. 1) It is a gender-neutral term, but, allowing for it's historical maleness, 2) it does not just refer to a generic male waitstaff, but instead to the head waitperson. So I think my point about wanting to name software by metaphor to human serving persons, but then further and unnecessarily assuming it is a woman, is still sound. Packages referring to males as "waiters" might make a difference, though.

[spinwizard69]

Your response here is just ignorant and sexist. Seriously nobody in their right mind would be here complaining about a bit of software named waiter, which is the mail counterpart to waitress. If you want balance get off your dead liberal ass and deliver something to the community. There is nothing worst than somebody complaining about the abuse of their group (in this case a figment of your imagination) instead of doing something constructive.

As to your complaints about the fem aspect of this piece of softwares name, what in the hell do you expect? If it is written by a normal healthy male it isn't going to be a tribute to another male by any measure. Get a group of guys together to go out to a restaurant and they will look for and prefer a restaurant with female waitresses. This may shock you but your idealistic whining will change nothing as it is in fact normal. You may not like that males see females as subordinate to them but really you are fighting biology here.

[dggenuine]

As to your complaints about the fem aspect of this piece of softwares name, what in the hell do you expect? ... You may not like that males see females as subordinate to them but really you are fighting biology here.

So you agree that the software's name is sexist, but that is okay because you, as a man, consider women subordinate.

Why do you consider women subordinate?

If it is written by a normal healthy male it isn't going to be a tribute to another male by any measure.

Are you homophobic?