我最近一直在努力学习WSGI以及Web如何处理Python。 所以我一直在阅读Werkzeug和PEP333来学习。
然而，我遇到了一个小问题，我认为我理解但可能没有，所以我很感激你的指导正确。
PEP333规定：
应用程序对象只是一个可调用的对象，它接受两个参数。 术语“对象”不应该被误解为需要实际的对象实例：具有调用方法的函数，方法，类或实例都可以用作应用程序对象。 应用程序对象必须能够被多次调用，因为几乎所有服务器/网关（CGI除外）都会发出这样的重复请求。
实施：
class AppClass: """Produce the same output, but using a class (Note: 'AppClass' is the "application" here, so calling it returns an instance of 'AppClass', which is then the iterable return value of the "application callable" as required by the spec. If we wanted to use *instances* of 'AppClass' as application objects instead, we would have to implement a '__call__' method, which would be invoked to execute the application, and we would need to create an instance for use by the server or gateway. """ def __init__(self, environ, start_response): self.environ = environ self.start = start_response def __iter__(self): status = '200 OK' response_headers = [('Content-type', 'text/plain')] self.start(status, response_headers) yield "Hello world!\n"我的问题只是澄清我是否理解正确。
它声明AppClass是应用程序，当我们调用它时，它返回一个AppClass实例。 但是后来进一步指出'如果我们想要使用AppClass ass应用程序对象的实例 '，那么这就是说当WSGI的服务器端调用AppClass对象时，只有一个实例在运行吗？
例如。 服务器可以向应用程序发出多个请求（200 OK）以获得更多响应，因此将其放入类中的原因。 但是每个请求都运行在同一个单一的AppClass实例中，每个对服务器的请求基本上都没有实例化AppClass的多个实例？
对不起，如果这是漫长的啰嗦，如果我没有多大意义，请再次道歉。 我正在努力提高自动量。
一如既往地欣赏您的输入。
谢谢。
I have recently been trying to learning about WSGI and moreover, how the web works in regards to Python. So I've been reading through Werkzeug and PEP333 to learn.
However I've run up against a small question, that I think I understand but probably don't, so I would appreciate your steering in the right direction.
PEP333 states:
The application object is simply a callable object that accepts two arguments. The term "object" should not be misconstrued as requiring an actual object instance: a function, method, class, or instance with a call method are all acceptable for use as an application object. Application objects must be able to be invoked more than once, as virtually all servers/gateways (other than CGI) will make such repeated requests.
The implementation:
class AppClass: """Produce the same output, but using a class (Note: 'AppClass' is the "application" here, so calling it returns an instance of 'AppClass', which is then the iterable return value of the "application callable" as required by the spec. If we wanted to use *instances* of 'AppClass' as application objects instead, we would have to implement a '__call__' method, which would be invoked to execute the application, and we would need to create an instance for use by the server or gateway. """ def __init__(self, environ, start_response): self.environ = environ self.start = start_response def __iter__(self): status = '200 OK' response_headers = [('Content-type', 'text/plain')] self.start(status, response_headers) yield "Hello world!\n"My question here is just to clarify if I have understood it correctly.
It states that AppClass is the application, and when we call it, it returns an instance of AppClass. But then further down states that 'if we wanted to use instances of AppClass ass application objects instead', is this saying that when the server side of WSGI calls the AppClass object, there is only one instance running?
For example. The server can issue multiple requests (200 OK's) to the Application for more responses, hence why iter is placed into the class. But each request runs through the same singular AppClass instance, each request to the server basically doesn't instantiate more than one instance of the AppClass?
Sorry if this is long winded, and apologies again if I haven't made much sense. I'm trying to improve atm.
Appreciate your inputs as always.
Thanks.
最满意答案
服务器技术将为每个请求调用您的app （在本例中为类AppClass ，导致对象构造）。 这是因为每个请求都具有潜在的唯一environ 。
关于这一点的好处是它并不意味着你的app必须是一个类，我经常发现将我的wsgi应用程序（或中间件）定义为返回函数的函数是有用的：
# I'd strongly suggest using a web framework instead to define your application def my_application(environ, start_response): start_response(str('200 OK'), [(str('Content-Type'), str('text/plain'))]) return [b'hello world!\n'] def my_middleware(app): def middleware_func(environ, start_response): # do something or call the inner app return app(environ, start_response) return middleware_func # expose `app` for whatever server tech you're using (such as uwsgi) app = my_application app = my_middleware(app)另一种常见模式涉及定义一个对象来存储构造一次的一些应用程序状态：
class MyApplication(object): def __init__(self): # potentially some expensive initialization self.routes = ... def __call__(self, environ, start_response): # Called once per request, must call `start_response` and then # return something iterable -- could even be `return self` if # this class were to define `__iter__` ... return [...] app = MyApplication(...)至于PEP333，我建议改为阅读PEP3333 - 它包含的信息基本相同，但澄清了整个过程中使用的数据类型。
The server technology will call your app (in this case the class AppClass, causing an object construction) for each request. This is because each request will have a potentially unique environ.
The neat thing about this is it doesn't mean your app has to be a class, I often find it useful to define my wsgi app (or middleware) as a function returning a function:
# I'd strongly suggest using a web framework instead to define your application def my_application(environ, start_response): start_response(str('200 OK'), [(str('Content-Type'), str('text/plain'))]) return [b'hello world!\n'] def my_middleware(app): def middleware_func(environ, start_response): # do something or call the inner app return app(environ, start_response) return middleware_func # expose `app` for whatever server tech you're using (such as uwsgi) app = my_application app = my_middleware(app)Another common pattern involves defining an object to store some application state which is constructed once:
class MyApplication(object): def __init__(self): # potentially some expensive initialization self.routes = ... def __call__(self, environ, start_response): # Called once per request, must call `start_response` and then # return something iterable -- could even be `return self` if # this class were to define `__iter__` ... return [...] app = MyApplication(...)As for PEP333, I'd suggest reading PEP3333 instead -- it contains largely the same information, but clarifies the datatypes used throughout.
更多推荐
发布评论