django vs flask和Flask这两个框架在设计上各方面有什么优缺点

Django博客开发实战:开篇 | Django学习小组 - 今日头条()
编程派微信号:codingpy这个公号开通已经大半年的时间了,之前推送了许多有关Python核心知识的内容,现在或许是时候发布一些 Web 开发相关的文章了,主要涉及 Flask 和 Django 这两个框架。其中,针对 Django 框架,编程派将与“Django学习小组”合作,首发 Django 博客开发实战等系列教程,本文是第一篇;针对 Flask 框架,上周收到了 Millyn 同学的投稿,会分三部分放出。以后日常推送的内容,也会逐步往这方面靠拢。文中蓝色带下划线的文字为超链接,请“阅读原文”后点击。Django开发环境搭建django 的开发环境搭建以及如何创建工程在网上有大量的博客和教程介绍,在此不再重复说明。但是我们认为最好的参考资料,还是Django官方的入门 Tutorials ,即官方文档的 First steps 部分的六个 部分。当然如果你不喜欢英文,可以看网友的翻译版本:Django1.8.2中文文档的入门部分。要开始 Django 开发,你需要掌握以下知识:如何创建 Django 工程,并了解 Django 默认的工程目录结构如何创建 Django APP理解 Django 的 MTV 模式,学会编写 Model、View、TemplateDjango 如何处理静态文件,即各种 CSS,JS,以及图片文件等Django应用是如何工作的?先看一张流程图,再来逐步讲解其过程:1:用户通过浏览器输入相应的 URL 发起 HTTP请求(一般是 GET/POST)2:django 接收到请求,检测 urls.py 文件,找到和用户输入的 URL 相匹配的项,并调用该 URL 对应的视图函数(view)。例如,通常来说 urls.py 文件里的代码是这样的:url(r'^homepage/$', views.home_page)则当用户输入的 URL 为 www.某个网址.com/homepage 时,django 检测到该 URL 与上面的代码匹配,于是调用后面的 views.home_page 视图函数,把相应的请求交给该视图函数处理。3:视图函数被调用后,可能会访问数据库(Model)去查询用户想要请求的数据,并加载模板文件(Template),渲染完数据后打包成 HttpResponse 返回给浏览器(Http协议)大致工作流程就是这样,从流程可以看出,我们需要做的就是:编写相应的 url编写数据库(Model)编写处理 Http 请求的视图函数(View)编写需要渲染的模板(Template)这就是 Django 开发的最主要工作,下面遵循这样的开发流程开始编写我们的博客吧。编写 ModelModel 对应数据库,我们编写的是一个 Blog 应用,因此数据库中应该存放 Blog 下的文章(Aticle),文章由标题(title)、正文(body)、发布时间(publised_time)等组成。先看 django 是如何定义数据库的,之后再逐行解释代码(假设你已经对 django 的工程目录结构了解了,我们一般把 Model 定义在 models.py 文件中):models.py:由上可见,设计数据库结构就是编写 models,数据库中每一个实体对应的表在 django 中对应着 models.py 中的一个类,类的属性对应着数据库表的属性列。model 定义完毕后,运行以下命令即可生成相应的数据库:python manage.py makemigrationspython manage.py migrate你可以打开相应的数据库文件,看看里面生成的表结构,加深理解。以上的代码中涉及到一些 django 相关的概念,分别给出以下参考资料供学习:Django 模型层(model)的概论:官方文档、中文翻译文档类中各属性(field):官方文档对 django 提供的各 field 的介绍、相应的中文文档ForeinKey(一对多),还有 ManyToMany(多对多)、OneToOne(一对一)的介绍:官方文档对外关系的介绍编写 View上面已经介绍了 django 应用的工作流程,数据库建立完毕后需要编写视图函数(view)来处理 Http 请求。同样先来看 django 的视图代码是如何写的。我们现在要设计的是一个首页的视图函数,即用户进入我们的 博客首页后,我们需要把数据库中存储的文章的相关信息取出来展示给用户看:你可能觉得奇怪,既然是视图函数,为什么不是用 def 来定义,而是写成一个类?这里涉及到 django 关于类的通用视图的概念:参考类的通用视图。我们通过调用 as_view 方法会将该类视图转为一般的视图,这在 url 部分会介绍。这个视图的工作流程如下:首先接受来自用户的 Http 请求,然后从数据库中获取到已经发布的文章列表:article_list = Article.objects.filter(status='p'),并转换 markdown 语法标记,再加载模板文件:template_name = "blog/index.html",将模板中的变量用相应数据库中的数据替换后返回给浏览器。这样,用户就看到了从数据库中被取出,然后被渲染后的文章列表了。编写 Templatetemplate 稍微麻烦一点,因为涉及到 html 的相关知识。如果你没有学过 html ,可能会有些看不懂,因此推荐学习一下,这里有很棒的教程:w3school 的 html 教程供学习使用。这里只介绍一点点本项目涉及的模板相关知识,其实 django 文档的入门教程的六个部分中涵盖的点已经足以对付此简单的博客项目了。模板标签,用 {% %} 表示,一些常用的有 {% for %} 循环标签,{% if %} 判断标签等。模板变量,用 {{ variable }} 表示,模板渲染指的是这些变量会被数据库中相应的值代替,例如article_list = Article.objects.filter(status='p'),从数据库中取出了已发布的文章列表,赋给了 article_list 变量。如果模板文件中有如下代码:{% for article in article_list %} {{article.title}}那么渲染时就会循环渲染 n 篇文章,并且 {{article.title}} 也会被存储在数据库中文章的标题取代。更多详细的资料,请参考官方文档关于 template 的介绍,或者中文文档编写 URL写好了数据库、视图和模板,现在就是当用户在浏览器输入 url 访问我们的博客时,要告诉 django 哪个 url 的请求对应哪个视图函数来处理,通过 urls.py 来指定:urls.py:urlpatterns = [
url(r'^blog/', views.IndexView.as_view()),
# 首页调用IndexView
]至此,Blog 应用的首页算是完成了,当用户访问我们的主页就可以看到文章列表了:结束语本节是 django blog 项目的开篇,是 django 学习小组的集体学习成果。django学习小组是一个促进 django 新手互相学习、互相帮助的组织。小组在一边学习 django 的同时将一起完成几个项目,包括:一个简单的 django 博客,用于发布小组每周的学习和开发文档;django中国社区,为国内的 django 开发者们提供一个长期维护的 django 社区;上面所说的这个社区类似于 segmentfault 和 stackoverflow ,但更加专注(只专注于 django 开发的问题)。目前小组正在完成第一个项目,本文即是该项目第一周的相关文档。更多的信息请关注我们的 github 组织首页,本教程项目的相关源代码也已上传到 github 上。同时,你也可以加入我们的邮件列表 django_study@ ,随时关注我们的动态。我们会将每周的详细开发文档和代码通过邮件列表发出。如有任何建议,欢迎提 issue,欢迎 fork,pr,当然也别忘了 star 哦!
不怎么好用
听详细的教程,期待后续
等一个人、还是等一个故事。
第一时间分享有关Python的最新资讯、独家编译教程和学习资源,以及其他与IT相关的国外优质文章。
关注互联网架构及高可用、可扩展及高性能领域的知识传播
上谈【安卓】,下论【苹果】。以扯淡的态度,面对操蛋的技术,用幽默的语言,诠释开发的经典。
《电子技术应用》创刊于1975年,由华北计算机系统工程研究所主办,经过30多年积淀,已成为电子、电信、工控、通讯、计算机等领域人士的首选期刊。
用户体验设计,交互设计,用户研究,UI,UE;
专注于中文Linux技术、资讯的社区。
易车购物10万买豪车 新劲炫ASX等你询底价
(C) 2016 今日头条 违法和不良信息举报电话:010-公司名称:北京字节跳动科技有限公司最后一个广告位招租
PythonTip是一个公益项目,网站托管于付费服务器。由于目前访问人数飙升,每日流量等资源消耗较多,现出售广告位以支付每月机器费用,有意者请加qq联系站长。~
请大家谈谈对各种python web框架的感受和优缺点!
关于Web应用框架与技术的选择小结
最近在做Web应用框架与技术的选择。我们需要实现一个Web2.0特征的网站,
考虑的因素:
1.功能模块(基本的2-3个功能(发布、评论、图片、tag、搜索)、初期扩展功能1-2(地图、伴随))
2.开发效率(真正可用于开发的时间、开发人员)
3.UI(整体设计的可能性不大、最好有现成模版)
4.静态页面(用户体验、速度)
5.Ajax(吸引用户的界面、与目前国内网站的差异、体现Web2.0)
可选框架:
Java+Apache+Hibernate+MySQL
1.功能强大
2.开发人员熟悉,有一定技术储备
3.有一些可选控件资源
4.数量级用户量的扩展
1.需要整体配置和构架(企业开发)
2.UI设计、对Ajax的支持、Web2.0页面风格
3.需要统一个配置、功能模块独立性差,当功能增加或关联度增加时对开发人员的压力较大
4.模版代码、数据库代码、配置代码和模块编码量大
Ruby on Rails
Ruby+Webrick+Active Record+MySQL
1.快速开发
2.使用者多、开发控件非常丰富
3.有多个成功案例 43things、Odo
4.支持Ajax
1.Ruby由日本人创造的,尽管ROR是丹麦的小伙子David开发的
Python+Apache+Plone+MySQL
1.功能强大
2.Google的主力平台
3.已经发布Zope3
2.从头熟悉需要太多时间
TurboGears
Python+Apache+TurboGears+MySQL
1.快速开发
3.有一定的时间积累、相应的开发工具和模块
4.支持Ajax,i18n
5.开发工作量少
6.Python语言,安装布置上手快
1.国内人气不旺
2.未找到类似成功案例
Python+Apache+Django+MySQL
1.功能框架清晰
2.编码量小、开发效率高
3.有现成模版减少UI工作量
4.国外网站开发应用选型热点
5.可交流资源多
6.在迅速发展中
1.上手有一定门槛
2.发布时间短,应用模块资源不多
参考文档:
1.Ruby on Rails and J2EE: Is there room for both?(英文)
Ruby on Rails 和 J2EE:两者能否共存?(中文)
2.WebProgramming
3.美国航空航天局(NASA)的工程师对web开发框架(j2ee, rails, zope/plone, turbogears, django)的选型做的报告
4.Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite
5.The SquizLog: J2EE vs Ruby on Rails
6.Python Tutorials, more than 300, updated February 15, 2005, and carefully sorted by topic and category
7.Is Rails Ready for Prime Time?
8.Ruby on Rails 实践
1.Ruby由日本人创造的,尽管ROR是丹麦的小伙子David开发的
搞笑,看不出来是做技术的】
其实很多人不学ruby真的是因为他是日本人创造的。至少我目前还没兴趣学ruby。
【Zope, Google的主力平台?】
我也有点怀疑
quixote没有提到!douban的框架哈。再给因为日本人不学ruby投一票,
quixote作为框架来说没有那么闪光,当时豆瓣没选择其他的框架也不是因为其他的框架不好,只是当时python的框架还没有现在这么繁荣。不用ruby有日本人搞的一面,其中也有技术成分:就是怀疑文档的语言要是日语可能不太方便。
有人说过,用过python的不喜欢ruby,也是有一定道理的。
用ruby的时候,一些语法我也不喜欢。
kiragille是个很可爱的框架,法国人整的,但是跑起来很慢。我在局域网里面架了个下的blog用的是Django TurboGears和Django目前是Python最好的轻量级框架了,这两个框架各有优劣,自己选择吧,从架构的设计思想而言,我各人更喜欢TG。
如果用ZOPE,尽量从简,一套ZOPE自己就可以搞定一切了,不要跟外面关联那么多。
django目前国内规模最大的是海报时尚网,当然总感觉如果做企业级开发的话,python不够成熟django目前国内规模最大的是海报时尚网,当然总感觉如果做企业级开发的话,python不够成熟
+++++++++++++++++++++++++++++++++++++++++
Django不够成熟。不是其本身怎么样,而是第三方开发的东西,良莠不齐。Zope是没有问题的。除了包里有一个simplejson。。。。django没第三方的东西。。。。。。。。和第三方类库盘根错节的是pylons和turbogears。。。。我最担心的是rails的性能。
从开发者角度看我关心书写的舒适度,和开发速度
若从创业的角度上看,性能我还是蛮重视的。
我会学rails,因为它是一种思想和一种不错的思路。
比较看好的project以后会用rails的python实现(未接触)是pylons或者turbogears来开发我所说的第三方良莠不齐并不是指django/contrib下的东东而言,而是说网上自行开发的某些库,比如django-registration之类。
我不认为admin和auth有什么不妥。但是,就django框架本身来说,文档做得并不好。读程序,经常可以读到一些文档中没有收录的函数。这一点正与Python本身相同。你发现黑盒子上有个洞,漏出了些什么东西,但当你想透过孔洞看的时候,却只发现黑乎乎的一片。还是统一的好,我曾经自己写过一个framework,但是这样不会给社区带来什么好处。只会让社区更加的乱,社区资源大量的浪费。所以我觉得还是选择其中一个最热门的来用的好,我们可以修改它的代码,甚至可以架空它,但是现在还不能去创造更多的轮子来扰乱它。号召社区一起用django。无论如何它是不断进步的,至少我看它的代码已经非常的“合口味”了。
至于谁比较厉害,呵呵,这个没有什么可比性的。没有什么比较有优点的,大家都是千篇一律的。这个毫无疑问,不信大家可以列出来,我们可以一一的挖下去最后发现原来大家都是一样的。DJANGO还不错啊。 公司内部项目好几个用DJANGO了。 其中一个在已有数据库基础上的二次开发。一个命令就把数据库表变成 model了,稍微改改外键关系就直接可以用了。一对多关联只要设一边就可以了。比hibernate那一套舒服多了。
喜欢就是喜欢,不喜欢就是不喜欢。
喜欢什么用什么吧。
我个人来说不喜欢django。就好象不喜欢原装机一样。
比较喜欢组装,而且喜欢精巧。rails的性能已经不成问题了,javaeye就是rails开发的, 升级到REE 性能很不错,说到性能,google还不是尽量回避python?凡事有个相对!2009,ruby一直往性能方面调优,rails以后会很好用,找到一份rails相关的工作将是程序员的一种莫大的幸福!django也不错,只是低调了点,性能和开发效率方面并不逊色于rails,严谨的django 和充满乐趣的rails 会走得很长!
本人就是使用django的,喜欢她的扩展性和重用性!可惜pythoner 都是低调的,没有贡献多少代码到django的第三方app,使得django 的相关技术没有得到发挥。没事也得接触一下rails了,rails火辣得让人按耐不住“花心”!django好比一个单反相机,需要调,直到满意为止,稍微急躁,就照不出好效果,而rails就象一款高端智能机,省心省力,刚刚用,效果并不差,用长了 效果还相当完美!django
选择框架和技术,可以参考大公司的选择
google 选择了 python ,这是他们日常使用最多的语言
google 选择了 django,在 google app engine 中,python SDK 缺省支持的就是 djangoFlask
新生代Web框架,用着很省心,按照阿北以前解释如何选择Quixote一样,框架不会跑出来跳过来跳过去妨碍你去实现业务逻辑
如果你用tornado做app-server的话,无耻的打个广告,用我的tor皮吧
怎么没人提web.py呢,很简洁,用的很爽啊,对于Django感觉过多的功能反而成为累赘,反正我不喜欢webpy确实特别简洁,什么功能都是只有一个壳子。
除了路径解析还比较靠谱外,像db功能、session什么的直接用恐怕就不能像你所想的那样工作。
但这也是它吸引人的特点之一。
个人喜欢精简
首先是“精”,如果一个团队维护过多的功能,是比较难的
比如sqlalchemy就异常强大
再是"简",用起来要顺手。
像web.py、flask、bottle这种,就很好。
只此两点而已 10:11:14 素心涤尘
不管怎么说:因为Ruby是日本人开发的而不学它的人占大多数
---------------------------------------
是不是因为A片都是岛国产的就有人拒绝撸管?
那真是'民族英雄'了... 10:52:13 石州灯笼
谁都没有自称“民族英雄”,有些人至于急成这样?
---------------------------------------
解释就是掩饰,掩饰的就是事实
lol5年前的帖子了,那时候django还不成熟,如果现在选择,就毫不犹豫的选Django吧
以前我也质疑Django,认为Django各方面都提供,各方面都不深入,比如model(orm)、form,现在想想,Django这样做是对的
拿orm来说吧,很多人通过比较SQLAlchemy和Django的orm得出结论:Django的orm功能太弱,很多需求Django的orm满足不了。但反过来想想,所有Django的orm提供不了的功能都是应该用原生sql去实现的。SQLAlchemy的那种完全用orm代替原生sql的做法是愚蠢的,弄到最后你会发现用SQLAlchemy实现复杂的查询比用原生sql还要麻烦的多
Django能简化工作中大部分简单而繁琐的工作,这已经足够了,对于复杂的业务部分,果断的用原生技术解决我所说的第三方良莠不齐并不是指django/contrib下的东东而言,而是说网上自行开发的某些库,比如django-registration之类。
----------------------------------------------------------------------------------------------------------
你对django第三方库指名道姓批判的时候最好挑对对象。比如你说的django-registration的作者就是django项目的team lead。如果你说他的库在良莠不齐的库之列,那不如说所有的开源项目都良莠不齐。我用过很多django的第三方库,都很好用,不少库的作者都是研究django源码多年的高手,因为有不少用户提供建议甚至提供代码,所以这些库的质量一直很高。不少第三方库甚至被包括到了最新的django官方库里。
我去,被谁刨出来的。
用过web.py和django.
我感觉django的优点和缺点都是想做到包罗万象,喜不喜欢分人而异。
个人挺喜欢web.py,留给程序员的自由比较多,但是前一阵由于得在公司里使用Windows服务器,所以发现和IIS结合的不太好。支持digango, 对ruby没兴趣,日本是原因之一,但是ror的思想学了,用哪里自己说了算。python确实是非常优美的开发语言。缺点:
  1.Ruby由日本人创造的,尽管ROR是丹麦的小伙子David开发的
搞笑,看不出来是做缺点:
  1.Ruby由日本人创造的,尽管ROR是丹麦的小伙子David开发的
搞笑,看不出来是做技术的很久没来豆瓣小组了,没想到我6年前发的帖子至今依然有人顶,不容易。
事实上我从6年前发了帖子到现在,没有怎么用过python的web框架,知道最近实实在在的学习了一下Django,把一些感受在这里说出来。
1. 快速。Django从RoR学了不少好东西,自动生成数据库表model,model和form绑定等等。
2. 文档齐全,社区还算活跃。这个其实很重要,应为总会遇到各种各样的小问题,如果文档不全或者用的人不够多,很痛苦。比如我之前尝试了一下Java的Play框架,文档是个问题,狠多细节查不到。
3. django的模板有点不爽,太罗嗦,比如{%if %} {% endif%},每次在输入{%%}的时候都觉得很崩溃,这两个字符里的离的太远,而且都需要按住SHIFT,很不习惯。后面的那个endif完全按没有必要,end就完了呗。
不过如果python和ruby都不熟的新手,我建议还是学学ruby on rails吧,因为从语言的层面,ruby比python抽象能力更强
原文链接:/item/D0wNYwl4
阅读: 1055 |在Flask项目中使用FIS
(window.slotbydup=window.slotbydup || []).push({
id: '2611110',
container: s,
size: '240,200',
display: 'inlay-fix'
您当前位置: &
[ 所属分类
| 时间 2015 |
作者 红领巾 ]
最近在Flask项目中用上了百度的 FIS ,感觉不错。
前端资源管理是Web开发中非常重要的一环,涉及到资源压缩、资源合并、添加hash版本等等。全栈式Web开发框架中一般都会集成前端管理模块(或以插件的形式),比如RoR中的 sprockets-rails 、Django中的 django-pipeline 。Flask是一种微框架,其本身只有最核心的组件,要在Flask项目中进行前端资源管理,可以用一些插件,或者自己实现。
之前我用过 webassets (以及 Flask-Assets 插件),不过用起来略感别扭,而且一些重要功能一直缺失(比如对图片添加hash版本,见此 issue ),后来就没用了。
之前朋友推荐了百度的FIS前端工具框架,所以最近找时间把它用到了Flask项目中,积累了一点点入门级经验,分享下。
npm install -g fis
npm install -g fis-postpackager-simple
其中,fis-postpackager-simple是用于资源打包合并的插件。
application为Flask app根目录,其下的static和templates分别存放静态文件和HTML模板文件,这两个文件夹即为FIS的输入
application/fis-conf.js为FIS的配置文件
根目录下的output是FIS输出目录
确定输入、输出路径之后,就可以在fis-conf.js中进行配置了:
// 指定输入路径
fis.config.set('project.include', ['templates/**', 'static/**']);
// 忽略无需参与编译的文件
fis.config.set('project.exclude', ['static/**.less']);
使用绝对路径引用静态资源
为了让FIS能正确找到静态资源地址,在HTML中引用外部静态资源(JS、CSS、图片等)时,不能使用Flask提供的 {{ url_for('static', filename='xxx') }} ,而要采用绝对路径:
&script src="/static/js/libs/jquery.min.js"&&/script&
&link rel="stylesheet" href="/static/css/libs/bootstrap.min.css"/&
&link rel="Shortcut Icon" href="/static/image/favicon.png"&
编译静态资源
简单配置之后,就可以进行资源编译了:
cd application
fis release -d ../output -om
o代表对资源进行压缩,m代表添加MD5版本值。运行后,可以发现html页中的外部引用资源已经添加了hash版本:
静态资源的合并
接着利用FIS对静态资源进行打包,这样可以减少HTTP连接数,提高网站性能。打包规则需要在fis-conf.js中定义,如:
fis.config.set('modules.postpackager', 'simple');
fis.config.set('pack', {
'pkg/libs.js': [
'static/js/libs/jquery.min.js',
'static/js/libs/bootstrap.min.js',
'static/js/init.js'
'pkg/libs.css': [
'static/css/libs/*.css'
'pkg/layout.css': [
'static/css/bootstrap.theme.css',
'static/css/common.css',
'static/css/macros/*.css',
'static/css/layout.css'
运行 fis release -d ../output -omp 后,打包后的文件就出现在output/pkg文件夹下面了,同时html中的引用资源也发生了相应的变化:
设置templates和static路径
由于FIS将templates和static输出到了另外的路径,所以需要更改配置Flask app。
app = Flask(__name__, template_folder=os.path.join(project_path, 'output/templates'))
app.wsgi_app = SharedDataMiddleware(app.wsgi_app, {
'/': os.path.join(project_path, 'output')
生产环境下一般用Nginx来serve静态文件,以上第2-4行代码是不必要的。
FIS支持对静态资源设置域名前缀,如果打算采用CDN托管静态资源的话,这个特性就很有用了:
fis.config.merge({
roadmap: {
domain: ''
编译命令中需要多出一个D:
fis release -d ../output -ompD
顺便附上一段项目中用于上传静态资源到七牛的代码:
# coding: utf-8
from qiniu import Auth, put_file
class Qiniu(object):
def init_app(self, app):
access_key = app.config.get('QINIU_ACCESS_KEY')
secret_key = app.config.get('QINIU_SECRET_KEY')
self.bucket = app.config.get('QINIU_BUCKET')
self.auth = Auth(access_key, secret_key)
def upload_file(self, filename, filepath):
token = self.auth.upload_token(self.bucket, filename)
ret, info = put_file(token, filename, filepath)
if info.exception is not None:
raise UploadError(info)
class UploadError(Exception):
qiniu = Qiniu()
qiniu.init_app(app)
def upload_dir(dir_name):
"""上传文件夹中的文件到七牛"""
for root, _, files in os.walk(os.path.join(os.getcwd(), dir_name)):
for f in files:
absolute_path = os.path.join(root, f)
relative_path = absolute_path.split(os.path.join(os.getcwd(), 'output'))[1].lstrip('/')
qiniu.upload_file(relative_path, absolute_path)
print("%s - uploaded" % relative_path)
def upload_assets():
"""上传静态资源到CDN"""
upload_dir('output/pkg')
upload_dir('output/static')
上传静态资源时存在一个小问题,就是每次FIS生成新版本的静态资源时,不会删除老版本文件,这就导致上传时间会越来越久。目前尚未找到优雅的解决方法(或许利用FIS生成的map.json可以解决),暂时的做法是不定期删除output文件。
以上仅涉及到FIS一些最常用的特性,其他的比如图片合并、内容嵌入等都挺有意思的,有待实践。值得一提的是 FIS3 已经出炉,据说易用性和可扩展性大幅提升,有机会要试试。
BTW,我的开源项目 Flask-Boost 的fis分支已经集成了上述实践,欢迎试用、欢迎PR。
本文开发(python)相关术语:python基础教程 python多线程 web开发工程师 软件开发工程师 软件开发流程
转载请注明本文标题:本站链接:
分享请点击:
1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
阅读(1051)
我们的所思所想,必然决定着我们的心态。因此,一切力量、成就与财富,其奥秘全在于我们的思维方式。
手机客户端
,专注代码审计及安全周边编程,转载请注明出处:http://www.codesec.net
转载文章如有侵权,请邮件 admin[at]codesec.net

我要回帖

更多关于 django和flask 的文章

 

随机推荐