应用上下文和请求上下文

from flask import Flask,request,session,url_for,current_app
from werkzeug.local import Local,LocalStack #线程隔离技术
#只要绑定在Local对象上的属性
#在每个线程中都是隔离

app = Flask(__name__)

# print(current_app.name)#RuntimeError: Working outside of application context.
#怎么解决上面的错误
app_context = app.app_context()
app_context.push()#把当前app推进取
print(current_app.name)#flask_context_demo
#可以用with语句简化
with app.app_context():
    print(current_app.name)

@app.route(‘/‘)
def hello_world():
    #就是显示当前app的名字
    print(current_app.name)
    print(url_for(‘my_list‘))
    return ‘Hello World!‘

@app.route(‘/list/‘)
def my_list():
    return ‘my list‘

with app.test_request_context():
    #手动推入一个请求上下文到请求上下文栈中
    #如果当前应用上下文栈中没有应用上下
    #那么会首先推入一个应用上下文到栈中
    print(url_for(‘my_list‘))

if __name__ == ‘__main__‘:
    app.run()

原文地址:https://www.cnblogs.com/wuheng-123/p/9748609.html

时间: 2024-10-10 04:34:49

应用上下文和请求上下文的相关文章

flask基础之AppContext应用上下文和RequestContext请求上下文(六)

前言 应用上下文和请求上下文存在的目的,官方文档讲的很清楚,可参考: http://www.pythondoc.com/flask/appcontext.html 应用上下文对象在没有请求的时候是可以单独存在的,但是请求上下文对象只有在收到请求后才会被创建.请求处理和应用上下文和请求上下文的关系是: 接收请求-->创建请求上下文-->请求上下文入栈-->创建该请求的应用上下文-->应用上下文入栈-->处理逻辑-->请求上下文出栈-->应用上下文出栈 系列文章 fl

2.5.1、程序和请求上下文

Flask 从客户端收到请求时,要让视图函数能访问一些对象,这样才能处理请求.请求对象就是一个很好的例子,它封装了客户端发送的 HTTP 请求. 要想让视图函数能够访问请求对象,一个显而易见的方式是将其作为参数传入视图函数,不过这会导致程序中的每个视图函数都增加一个参数. 除了访问请求对象,如果视图函数在处理请求时还要访问其他对象,情况会变得更糟. 为了避免大量可有可无的参数把视图函数弄得一团糟,Flask 使用上下文临时把某些对象变为全局可访问.有了上下文,就可以写出下面的视图函数: from

flask-本地线程-请求上下文补充

context(上下文)是flask里面非常好的设计,使用flask需要非常理解应用上下文和请求上下文这两个概念 本地线程 本地线程(thread local)希望不同的线程对于内容的修改只在线程内部发挥作用,线程内部互相不影响 from django.test import TestCase import threading mydata = threading.local() mydata.number = 42 print(mydata.number) logs = [] def f():

Flask中的请求上下文和应用上下文

本文章粘贴自 https://blog.tonyseek.com/post/the-context-mechanism-of-flask/ 用过 Flask 做 Web 开发的同学应该不会不记得 App Context 和 Request Context 这两个名字--这两个 Context 算是 Flask 中比较特色的设计.[1] 从一个 Flask App 读入配置并启动开始,就进入了 App Context,在其中我们可以访问配置文件.打开资源文件.通过路由规则反向构造 URL.[2] 

【转】进程上下文和中断上下文、原子上下文的区别

内核空间和用户空间是现代操作系统的两种工作模式,内核模块运行在内核空间,而 用户态应用程序运行在用户空间.它们代表不同的级别,而对系统资源具有不同的访问权限.内核模块运行在最高级别(内核态),这个级下所有的操作都受系统信 任,而应用程序运行在较低级别(用户态).在这个级别,处理器控制着对硬件的直接访问以及对内存的非授权访问.内核态和用户态有自己的内存映射,即自己的 地址空间. 系统的两种不同于行状态,才有了上下文的概念.用户空间的应用程序,如果想请求系统服务,比如操作某个物理设备,映射设备的地址

解决WCF“这可能是由于服务终结点绑定未使用 HTTP 协议造成的,这还可能是由于服务器中止了 HTTP 请求上下文(可能由于服务关闭)所致”异常

最近对系统的架构进行优化,用WinForm模拟客户端调用WCF,在WCF起一个Bus,把接收到的消息推送到各个Sub端. 本来很简单的调用关系,结果把WCF服务部署到IIS后,一直报"接收对 http://lenovo-y460:8099/Service.svc 的 HTTP 响应时发生错误.这可能是由于服务终结点绑定未使用 HTTP 协议造成的.这还可能是由于服务器中止了 HTTP 请求上下文(可能由于服务关闭)所致.有关详细信息,请参见服务器日志."异常,效果如下图所示: 出异常了

HttpContext请求上下文对象

一.HttpContext概述 HttpContext基于HttpApplication的处理管道,由于HttpContext对象贯穿整个处理过程,所以,可以从HttpApplication处理管道的前端将状态数据传递到管道的后端,完成状态的传递任务. HttpContext的生命周期从服务器接收的HTTP请求开始到反应发送回客户端结束. 在WebForm或类库(包括MVC)项目中,通过Current静态属性,就能够获得HttpContext的对象. HttpContext context =

IOC容器特性注入第七篇:请求上下文作用域

Ninject的对象作用域: Transient .InTransientScope() 每次调用创建新实例. Singleton .InSingletonScope() 单例,仅创建一个实例. Thread .InThreadScope() 每一个线程创建一个实例. Request .InRequestScope() 每当Web请求发起时创建一个实例,结束请求时释放实例 由于我们使用的web开发,所以一般都是InReuqestScope()的作用域,Kooboo对Ninject的作用域没有用,

【Nginx】请求上下文

上下文与全异步web服务器的关系 请求上下文指在一个请求的处理过程中,把一些关键的信息保存下来的类似struct这样的结构体.每个http模块都可以有自己的上下文结构体,一般都是在刚开始处理请求时在内存池上分配它,之后当经由epoll.http框架再次调用到http模块的处理方法时,这个http模块可以由请求上下文结构体中获取信息.请求结束时就会销毁该请求的内存池,自然也就销毁了上下文结构体. Nginx是全异步处理的web服务器,http模块可能会多次反复处理同一个请求,所以必须定义上下文结构