标签归档:Python

和中学生们聊聊学习和使用 Python 的趣事

  • 录像:bilibiliYouTube
  • 嘉宾:王俊杰 / 胡博文 / Andy Zhou / Rice Zong
  • 主持人:李辉
  • 详情页:https://cn.pycon.org/2021/talks/young-pythonistas
  • 介绍:高中生和初中生们是怎么学习 Python 的?他们都开发了什么项目?他们未来会计划做程序员吗? 在这场圆桌里,一个高中生和三个初中生会一起聊一聊他们学习和使用 Python 的经历,以及他们的未来畅想。

这是 PyCon China 2021 第一天的一场圆桌讨论(PyHouse)。辛庆老师跟我说的时候,本来没打算参加,后来想到可以邀请我的两个小读者来聊聊,所以在前一天决定来策划和主持这场圆桌。

邀请的两个人一个是 Andy Zhou,他在六年级就开始学习 Python 了,初中时通过读我的书学习了 Flask,然后做了一个班级网站(博客程序 Flog),让同学们可以注册在上面写东西。另一个是陈绍坤(现在才想起来他似乎还在上六年级),知道他是因为他在一个知乎回答里介绍了自己学习编程的经历,而且提到有读我的书(文章?)。不过因为我在大会前一天才发出邮件,陈绍坤没来得及看到,看到邮件时圆桌讨论已经接近尾声……

第二天上午,Andy 的同学 Rice Zong 突然发邮件给我,做了一番相当正式的自我介绍,然后说想和我做朋友,原话是「我正式向你发出交朋友的邀请。希望你能接受这个朋友。」。哈哈,感觉好可爱(希望这样说他不会觉得冒犯)。他告诉我 Andy 跟他嘚瑟我发出去的圆桌邀请邮件,所以问我「作为初中生,如何才能参加 PyCon China 2022?就像 Andy 一样。」。看到最后这个问题,还没看清他说的是 2022,我就赶紧补了一封邀请邮件给他,这样我们就有了一位新嘉宾。再加上辛老师邀请的两位在上海现场的王俊杰和胡博文同学,四人成行。

我一开始准备了很多问题,但是几个人三下五除二就回答完了,而这时圆桌还剩一个小时。后面我已经不知道要说什么了,好在 Andy 和 Rice 实在是能聊,他们完全撑起了整场圆桌。再后来他们久仰大名的 Frost Ming 神秘现身;shell 叔给我们科普了很多法律相关的事情;现场的其他老师也加入进来聊起了网络安全……最后我实在坐不住了,只好把已经跑到月球的话题拉回来,给这场圆桌收了尾。这些跑题内容在最终视频里都剪掉了,要不然视频足足有两小时那么长。

也许是我笑点太低,不过和他们聊天真的非常开心,你很难不被他们的单纯和热情感染。希望明年可以看到他们几个来 PyCon China 演讲,期待明年的 PyCon China。

P.S. 这个视频是基于直播录屏的私人剪辑版本。视频中使用了冒险岛(MapleStory)的背景音乐 101 Building,我知道这样使用属于侵权,但我还是用了……版权属于 Nexon 公司。希望这是我最后一次未经授权使用版权音乐。

欢迎来 GOTC 大会听我的演讲

GOTC(The Global Opensource Technology Conference,全球开源技术峰会)是由开源中国(OSCHINA)和 Linux 软件基金会(The Linux Foundation)联合主办的开源技术大会。上海站(上海世博中心 SECC)在 7 月 9 日 ~ 7 月 10 日举办;深圳站(深圳会展中心)在 7 月 31 日 ~ 8 月 1 日举办。大会邀请到很多非常厉害的开发者,比如 Linus Torvalds。两个会场均免费开放,仅需报名即可。欢迎参加!

我的演讲主题是《基于 Python 的 OpenAPI 实践》,介绍如下:

OpenAPI(原 Swagger)是一个流行的 REST API 描述规范,围绕它有许多非常实用的 Web API 开发工具。而 Python 是一门流行的编程语言,使用它可以非常高效地开发 Web API。这个议题将会以 OpenAPI 的入门介绍开始,探索如何在流行的 Python Web 框架中实现 OpenAPI 支持,并在最后介绍一些现有的解决方案和工具。

这个演讲基本上是正在写的《Python Web API 设计与开发》第八章的内容概括 + 开发 APIFlask 的一些想法 + 周边项目(FastAPIConnexion 等)研究总结。暂定大纲为:

  • OpenAPI 介绍
  • Code-first 模式(从 Python Web 框架代码生成 OpenAPI spec)
  • Design/API-first 模式(从 OpenAPI spec 生成 Python Web 框架基础代码)

我的演讲在深圳站第一天分会场「编程语言艺术」专题论坛。如果你感兴趣的话,欢迎来听;如果对演讲内容有任何建议,欢迎提出。

请不要把 Flask 和 FastAPI 放到一起比较

The war has begun. Let’s end the war between Flask and FastAPI.

去年在知乎上看到一篇文章,后来想找却找不到了,最后通过关键词「5 分钟」和「四年」在掘金上找到了原文——《用它5分钟以后,我放弃用了四年的 Flask》。作者先是给出了一个手动用 if 验证请求数据的 Flask 视图函数:

@app.route('/insert', methods=['POST'])
def insert():
    info = request.json
    name = info.get('name', '')
    if not name:
        return {'success': False, 'msg': 'name 参数不可省略,不可为空!'}
    age = info.get('age', 0)
    if not isinstance(age, int):
        return {'success': False, 'msg': 'age参数不是数字!'}
    age_after_10_years = age + 10
    msg = f'此人名叫:{name},10年后,此人年龄:{age_after_10_years}'
    return {'success': True, 'msg': msg}

然后给出了一个使用 Pydantic 编写数据模型类 + FastAPI 路径操作函数的代码:

class People(BaseModel):
    name: str
    age: int
    address: str
    salary: float
    
@app.post('/insert')
def insert(people: People):
    age_after_10_years = people.age + 10
    msg = f'此人名字叫做:{people.name},十年后此人年龄:{age_after_10_years}'
    return {'success': True, 'msg': msg}

通过这两段代码进行对比,文章作者得出结论「我用了 Flask 四年,但在使用了5分钟 FastApi 以后,我决定以后不再使用 Flask 了」。你确定你用了四年的是 Flask 而不是 Flash?在此后的很长一段时间里,经常看到类似的对比和结论,所以我打算用这篇文章来澄清这个非常普遍的误解。如果看到有人把 FlaskFastAPI 放到一起比较,请把这篇文章的链接丢过去。

利益相关:笔者系 Flask 维护者和 APIFlask 作者。本文观点仅代表个人看法,与 Pallets 团队无关。

为什么 Flask 和 FastAPI 不能放到一起比较?

我在此前介绍 APIFlask 的文章里一开始就提到过这件事情:

经常看到有人把 FastAPI 和 Flask 放到一起比较,但是却没有意识到这完全是两种东西——前者是基于 Web 框架 Starlette 添加了 Web API 功能支持的(框架之上的)框架,而后者是和 Starlette 同类的通用 Web 框架。你怎么能让小明和骑电动车的小军赛跑然后还夸小军好快好强?

前两天看了 Reddit 上 Flask 2.0rc 帖子下的很多回复,预感到在 Flask 2.0 发布后在中文网络上也许会出现许多类似的问题和讨论,所以想着还是值得单独写一篇文章来谈这件事。

受那个 Reddit 主题里某个评论启发,想到一个更好的比喻: Flask 和 FastAPI 就像是苹果和橙汁。你不能把苹果和添加了更多蔗糖和添加剂的橙汁放在一起比较哪一个更甜。苹果(Flask)应该和橙子(Starlette)比较,橙汁(FastAPI)当然也应该和苹果汁(基于 Flask 的 Web API 框架)进行比较。也就是说,Flask 是一个通用型框架,和 FastAPI 依赖的 Starlette 一样,而 FastAPI 是添加 Web API 支持的二次框架。因此,Flask 应该和 FastAPI 所依赖的 Starlette 进行比较,而 FastAPI 应该和基于 Flask 的 Web API 框架进行比较。

同理,FastAPI 也不能和 Django、Tornado、web2py、Bottle、CherryPy、Pyramid、Sanic 等通用型 Web 框架比较。

更合理的比较对象是什么?

既然「FastAPI 应该和基于 Flask 的 Web API 框架比较」,那么合适的比较对象有哪些?Flask-RESTXFlask-Rebarflask-apispecflask-smorestFlask-RESTfulAPIFairy 这些虽然试图做成框架,但在具体实现上仍然是 Flask 扩展,所以真正公平合理的比较对象是:

这三个框架都是基于 Flask 实现的 Web API 框架。不过 Eve 没有内置 OpenAPI 支持,而 Connexion 是一个 Spec-First 框架,也就是 OpenAPI spec 优先(先编写 spec,然后生成项目基础代码进行开发)的框架。因此,尽管 APIFlask 只是一个刚发布没多久的实验项目,但它是最适合和 FastAPI 进行比较的项目。

FastAPI 和 APIFlask 有着同样的组成结构,都是作为一层胶水粘起来一个 Web 框架和一个数据序列化/验证库,然后加一点 Web API 功能支持:

在主要功能上也有很多交集:

  • 自动反序列化和验证请求数据,自动生成错误响应
  • 自动格式化和序列化响应数据
  • 自动生成 OpenAPI specification 文件
  • 自动生成交互式 API 文档

当然,相对于发布已经三年的 FastAPI,APIFlask 还只是一个三个月大的新项目,还有很多地方需要改进和完善。如果你对 APIFlask 感兴趣的话,可以在这篇文章了解详细介绍或是在它的 GitHub 仓库查看源码。

为什么会有这样的误解?

为什么会有那么多人把 FastAPI 和 Flask 放到一起比较?在我看来有三个原因:

首先是 FastAPI 采用了和 Flask 类似的装饰器路由,很容易让人联想到 Flask。

二是 FastAPI 没有给它的项目构成做足够的说明。如果 FastAPI 在其介绍的第一句就加上「based on Starlette and Pydantic」而不是放到 Requirements 部分才提及,这样也许会让 StarlettePydantic 获得更多应有的关注,也就不会有这么多人拿 Flask 和它比较。

再就是 FastAPI 的推介者对 FastAPI 了解的不够多。不清楚它的项目结构,自然就不了解它和其他 Web 框架的区别。而介绍时为了带来足够的吸引力,推介者常常选择拉上和用户量足够大的「竞品」进行对比这种方式,所以才会有大量类似本文开头提到的那种文章。这些文章甚至完全没有提及 Starlette 和 Pydantic,只是一味强调「这是一个超高性能的、碾压 Flask 的框架」。

FastAPI 不是银弹

FastAPI 只是说它能把「功能开发速度提升约 200% 至 300%」,距离十倍还差了一些,自然不能算是银弹。但是这两年看到了很多对 FastAPI 的盲目吹捧,仿佛 FastAPI 就是完美的解决方案。这也许都要归功于 FastAPI 在其 README 和文档里「大胆」的措辞和承诺以及不厌其烦的特性介绍。举例来说,如果它只是说「Very high performance, it is comparable to some frameworks in Go and NodeJS」,那么用户也许就会认为「和 Go/NodeJS 有一拼」,但是说成「Very high performance, on par with NodeJS and Go」,那么用户就会想「和 Go/NodeJS 不相上下」(以至于中文翻译是「可与 NodeJS 和 Go 比肩的极高性能」),这当然会带来一些争议。再比如,如果只是说「double or triple the development speed」,那么用户大概会想「效率还不错」,但是它用了「Increase the speed to develop features by about 200% to 300%」,数学不好的用户就会惊呼「哇,提高 30 倍开发效率」。同时这种营销带来的狂热用户,也很容易被煽动去给 Python Steering Council 施加压力——在 Python 3.10 快要发布的时候突然跳出来要求撤销一个 PEP。

这种营销至上的项目运营方式带来的直接后果是糟糕的维护状态。FastAPI 似乎在慢慢变成一个翻译项目,在代码里的文档字符串都还没写的情况下,其用户文档就已经开始扩展到十几种语言。而这十几种语言的翻译和项目源码都放在同一个仓库里,这导致所有开启的近 300 个 PR 里有过半是翻译。issue tracker 和 discussion 不做区分的使用,这导致所有开启的近 600 个 issue 里有九成是提问)。我在此前创建过一个 issue 来反馈这个问题,但并没有得到回应。另外凭个人喜好来说,在每个 commit 信息里都加上 emoji 并不可爱。而每一个 commit 都要触发 bot 更新 changelog,带来的是一份丑陋的 commit 历史(所有 commit 里有三分之一是在更新 changelog)。这些也许是发展社区或是让项目看起来很活跃的有效方法,但很显然这带来的是建立在混乱之上的虚假繁荣。

另外,许多推介文章都会在最后贴出来一张 benchmark 截图来证明 FastAPI 有多么 fast,但是完全不会提及的是:贴出来的 benchmark 对于开发生产应用来说有多大的意义?这里的 benchmark 背后有没有任何的 hacky?异步是否等同于高性能还是要看情况?框架本身的性能在一个请求处理流程中占多大的影响?asyncio 的生态怎么样?

从长远看这些大都是一些临时问题,而且 FastAPI 作者已经开始全职开发开源项目,这些问题在未来应该都会慢慢得到改善。指出这些是希望更多的人可以客观看待 FastAPI,吹捧并不能让一个东西变得更好,参与开发、介绍用法和回答社区提问是比盲目吹捧更有意义的事情。我当然期待 FastAPI 能够越来越好,也期待看到有更多优秀的 Python 框架出现,但我不喜欢过度炒作、盲目的吹捧和错误的对比。

P.S. Flask 2.0 版本即将发布

顺便说一句,Flask、Werkzeug、Jinja 等 Pallets 项目都将在 5 月 11 日(PyCon 开始)之前发布下一个主版本,主要包含下面这些新特性(完整变动见 changelog):

  • Flask、Werkzeug 和 Click 添加了 type hints
  • Flask 实现了有限的 async/await 支持
  • Flask 支持嵌套蓝本
  • Flask 添加了快捷版本的 route 装饰器(即 @app.get@app.post 等)
  • Flask 支持在视图类上使用 route 装饰器(我前两天刚提交了一个 PR 来实现这个功能,暂时不确定是否会被合并,在这先提前说一下 :p)
  • Werkzeug 的 multipart 解析性能大幅提升

你可以使用下面的命令安装 Flask 2.0.0rc 版本进行测试:

 $ pip install --pre flask

欢迎反馈 bug 和提改进建议。关于 2.0 版本的详细介绍将会在发布后另外撰文说明。

延伸阅读

PyCon China 2020: Python 技术名词发音指南

这是我在今年 PyCon China 的闪电演讲,不过没有去年那么闪电:

Django 怎么读?十个 Python 程序员也许会有十种读法。如果这个你刚好会读的话,那么还有 Werkzeug、SQLAlchemy、Gunicorn、PyPI、Bokeh、Huey…… 根据可靠来源,因为错误的发音,两个 Python 程序员在交谈时平均每小时会浪费三分钟时间用来互相确认和纠正名词发音。为了减少整个 Python 社区因为错误的技术名词发音产生更多的熵,这个演讲带来了一个可信度 95% 的 Python 技术名词发音指南。

这是我第一次做线上直播形式的演讲,在提交演讲申请之后我一直在想不知道会有多少人来听。也一直在担心 Windows 会不会蓝屏,国产软件会不会弹广告,猫会不会拔掉猫的电源……后来才知道可以提前录制,那就没什么好担心的了,所以你坐在屏幕前看到的我,当时也正坐在屏幕前看自己。

准备的过程中发现这可能是很容易带来争议的演讲:有些读音没有标准,有些读音我自己也读错好久,再加上有些人觉得发音无关紧要,有些人觉得错的人多了就成了正确发音,有些人还会守着错误发音扯到文化自信……不过没关系,反正这个演讲总能让台球再转起来一次,至少也可以短暂的让大家再一次正视错误发音问题。这个演讲也是我自己的一个发音纠正练习。

你也许觉得发音正不正确无关紧要,不,这其实是一件很重要的事情。拥有正确一致的发音可以让大家见面聊天更顺畅一点,不用停下来确认说的是同一个东西,在听播客和演讲的时候也不用被错误的发音打断思绪。而且有些错误的发音并不好听,比如「Windows 叉屁」……你只要稍稍花一点心力就可以避免让错误的发音变成主流发音,最后变成「事实上的正确发音」。一旦你不在乎这一点对错,生活里的很多事情都会慢慢变成无所谓和差不多另一方面,这份指南也希望可以给技术演讲和播客提供一个参考,如果 Python 培训班和各种九块九的网课感兴趣的话,这个指南或许可以放在第一课的最后作为延伸阅读的内容。只此两项,就可以避免错误发音大范围传播。

请从今天开始重视发音吧!


演讲准备备注:

  • 耗时:48h 35m(加上后期写这篇文章和上传视频的时间)
  • 幻灯片工具:Marpit
  • 一共录了 9 遍,演讲前一晚匆匆录了最后一版,很努力也才把时长压缩到 15 分钟(要求 10 分钟长度和最多五分钟偏差),有点赶。今天下午又重新录了一版,放轻松刚好 20 分钟。
  • 感觉线上演讲有点无聊……没有观众反馈,也没有紧张和兴奋的感觉。
  • 这个演讲最后本来有一个恶搞。虽然是录播,但我原本打算在最后假装有问答环节,问「大家有没有问题要问?」,然后停顿一分钟,再说「好,那没有问题就拜拜啦」。因为这样会让超时更加严重,而且会有点让人讨厌,所以最后就去掉了。现在的结尾的意思是「用 Python 之杖赐予各位听众 Pythonic 原力」。
  • PyCon China 网站也太难看了……

要不我们还是用回 virtualenv/venv 和 pip 吧

这篇文章没什么新东西,只是介绍古老又靠谱的 Python 虚拟环境和依赖管理方式:virtualenv/venv+pip。一来方便被我在《Flask 入门教程》和《Flask Web 开发实战》带入 Pipenv 坑的初学者了解基础工具的用法,二来方便其他 Python 初学者参考,自己顺便做个总结。如果你想了解更多详细内容,Python 官方教程这一章写的更好,可以替代这篇文章。

既然大部分试图简化 Python 虚拟环境和依赖管理工作流程的新工具都不够稳定,继续使用 virtualenv/venv 和 pip 这样的底层工具也是一个不错的选择,而且大多数人也是这么做的。它们虽然用起来有一点麻烦,但至少更可靠。

基本概念

下面是一些基本概念:

  • PyPA:指 Python Packaging Authority,一个维护 Python 打包相关项目的小组,相关项目具体见 https://github.com/pypa
  • pip:Python 包安装器 。
  • virtualenv:Python 虚拟环境管理工具。
  • venv:Python 标准库内置的虚拟环境管理工具,Python 3.3 加入,Python 3.5 开始作为管理虚拟环境的推荐工具,用法类似 virtualenv。如果你使用 Python 3,推荐使用 venv 来替代 virtualenv。

使用 virtualenv/venv 管理虚拟环境

venv 模块

如果你使用 Python 3(具体说是 Python 3.3 及以上版本),推荐使用标准库内置的 venv 模块替代 virtualenv,两者的使用方式基本相同,唯一不同的是创建虚拟环境的方式。

如果你使用 Python 2,那就只能选择 virtualenv,你需要额外安装它。我先假设你已经安装了 pip,因为在 Python 2 >=2.7.9 或 Python 3 >=3.4 这些版本的 Python 会一并安装 pip,其他版本可以参考文档的安装部分。在 Windows 下使用下面的命令安装 virtualenv:

$ pip install virtualenv

其他操作系统可以使用下面的命令安装:

$ sudo pip install virtualenv

尽管不推荐使用 sudo pip 的方式安装 Python 包,但这仍然是最简单和统一的方式。更安全的方式是使用系统包管理器来安装,或是使用 pip –user 方式安装。

创建虚拟环境

假设我们的项目名叫 snow,创建对应的文件夹然后切换到根目录:

$ mkdir snow
$ cd snow

如果使用 venv,那么使用下面的命令创建虚拟环境,其中 snow-venv 是虚拟环境的名字,也作为创建的虚拟环境文件夹名称,你可以自由修改(通常会使用 venv 或 env 作为虚拟环境名):

$ python -m venv snow-venv

如果使用 virtualenv,则使用下面的命令:

$ virtualenv snow-venv

这会在当前目录创建名为 snow-venv 的虚拟环境文件夹,你需要把这个文件夹名称加入 .gitignore 文件以便让 Git 忽略。

激活虚拟环境

通过执行对应的激活脚本来激活虚拟环境,不同操作系统的激活命令(激活脚本及路径)有一点不同。Windows(CMD.exe)使用下面的命令激活:

$ snow-venv\scripts\activate

Linux 和 macOS(bash/zsh)使用下面的命令:

$ source snow-venv/bin/activate

或:

$ . snow-venv/bin/activate

类似的,其他终端程序可以执行对应的激活脚本来激活虚拟环境。

激活虚拟环境以后,命令行提示符前会显示当前虚拟环境的名字:

(snow-venv) $

使用 deactivate 命令可以退出虚拟环境。

使用 pip 管理依赖

简单列一下基本用法,虽然大部分人都很熟悉了……以 Flask 为例,首先是安装依赖:

(snow-venv) $ pip install flask

更新依赖:

(snow-venv) $ pip install --upgrade flask

或是:

(snow-venv) $ pip install -U flask

卸载依赖:

(snow-venv) $ pip uninstall flask

除此之外,还有 pip show flask 命令可以查看某个依赖的详细信息,pip list 列出所有依赖。

下面的命令可以手动生成依赖列表:

(snow-venv) $ pip freeze > requirements.txt

如果你需要手动开发依赖和生产依赖,可以手动把开发相关的依赖放到单独的文件,比如 requirements-dev.txt。

当你需要在新的机器创建程序运行环境时,(创建虚拟环境后)只需要使用下面的命令从依赖文件安装所有依赖:

(snow-venv) $ pip install -r requirements.txt

如果安装包的时候速度太慢,可以考虑设置 PyPI 国内镜像,具体参考这篇文章

从其他工具迁移回来

如果你想从 Pipenv 迁移回来,方法很简单,只需要生成一个 requirements.txt 文件即可。使用下面的命令生成一般依赖列表:

$ pipenv lock -r

使用下面的命令输出开发依赖列表:

$ pipenv lock -r --dev

然后手动把两个命令的输出保存为 requirements.txt 和 requirements-dev.txt。

从 Poetry、Conda 等其他工具迁移回来可以使用 pipreqs 来生成 requirements.txt,它会基于项目代码的导入语句来生成依赖列表。

在下一篇文章,我会介绍一些辅助工具来搭配 virtualenv/venv+pip 使用,让虚拟环境和依赖管理更方便,比如 virtualenvwrapper、pip-tools 等。

(4)

只用来管理 Python 版本和虚拟环境,Miniconda 也是一个很好的选择

Anaconda 是一个面向数据科学的 Python 发行版,它打包了 Conda、Python 和一堆机器学习和人工智能相关和常用的包,而且还可以用来安装一些非 Python 编写的库。对于科学计算相关的用途非常方便,开箱即用。看起来很适合实验室或是学校机房使用……

对于常规的 Python 开发来说,Anaconda 太重了,而且主要面向科学计算领域,但是精简版的 Miniconda 却是一个很好的 Python 版本和虚拟环境管理工具。

更重要的是 Miniconda 兼容三个主流操作系统,而且不同平台使用同样的命令和接口(Conda 4.6 以上)。这大概算是个人偏好,因为我总在写东西给别人看,所以总是喜欢兼容主流操作系统并且接口统一的解决方案。而且另一方面 pyenv、virtualenvwrapper、direnv 等等相关替代工具都没有原生 Windows 支持。 

Miniconda 是什么

先来理清几个概念:

  • Conda:包、依赖和环境管理器。
  • Anaconda(某种蟒蛇的名字):面向数据科学的 Python 发行版,包含 conda、conda-build、Python 和 100+ 常用的数据科学常用的库及其依赖。
  • Miniconda:精简版的 Anaconda,也是一个 Python 发行版,只包含 conda、Python 和一些基本的包。

相关资源:

Miniconda 基本用法

首先你需要访问下载页面下载对应操作系统的安装包进行安装,Python 版本选择你想作为默认选项(base version)的版本。然后打开 Windows 下的 Anaconda Prompt 或是 Anaconda Powershell Prompt,Linux 或 macOS 直接使用终端程序。

下面是一些关键用法介绍,详细内容可以阅读 Conda 文档

创建虚拟环境

使用 conda create 命令创建虚拟环境,使用 –name 选项(-n)指定虚拟环境名称:

$ conda create --name foo

使用 conda info 命令查看当前环境名称、Python 版本、虚拟环境文件夹位置、Conda 版本等等各种信息:

$ conda info

使用 –envs 选项(-e)查看所有已创建的虚拟环境。在列出的虚拟环境中,使用星号(*)标识的是当前激活的虚拟环境:

$ conda info --envs

激活虚拟环境

使用 conda activate 命令激活虚拟环境,添加虚拟环境名作为参数:

$ conda activate foo

激活以后会在命令行提示器前显示虚拟环境名称,比如:

(foo) $

不添加虚拟环境名称,就会重新激活基础环境(base):

$ conda activate

设置虚拟环境的 Python 版本

在创建虚拟环境的时候,可以使用 python 参数指定 Python 版本。假设你使用的 Miniconda 默认版本是 Python 3.7,如果你想创建一个 Python 2.7 的虚拟环境,使用下面的命令:

$ conda create --name snakes python=2.7

你可以在虚拟环境名加上标识方便识别 Python 版本,比如:

$ conda create --name snakes-py27 python=2.7

搭配 pip / Poetry 来管理依赖

因为 Conda 安装库的时候默认使用 Conda 自己的仓库,这里包含的 720 多个库除了流行的 Python 包外大多是数据科学相关的包。所以,更好的选择是使用官方 PyPI 仓库,这样可以确保你使用到最近更新的包,而且不会出现有些包找不到的情况。

我们要做的就是只用 Conda 的 Python 版本和虚拟环境管理功能,不用它来管理依赖。依赖管理(安装、卸载、更新等)仍然使用 pip 进行,或是进一步搭配 pip-tools 来管理依赖。

你需要在 conda 环境内使用下面的命令安装 pip:

$ conda install pip

或是统一使用下面的命令格式创建虚拟环境:

$ conda create --name bar pip

这样在执行 pip 命令时会使用虚拟环境内的 pip,而不是系统全局的 pip。这样做的副作用是会产生几个多余的依赖。

除此之外,你也可以搭配使用 Poetry。Poetry 默认会自动创建虚拟环境,所以需要关闭 Poetry 自动创建虚拟环境的设定,执行下面的命令即可:

$ poetry config settings.virtualenvs.create false

总结

按照我目前掌握到的信息,Miniconda 的优缺点总结如下:

优点

  • 用法简单,​易于上手
  • 替代 pyenv+virtualenv/venv+virtualenvwrapper 的多个工具组合
  • 类似 virtualenvwrapper,可以在任意位置激活虚拟环境,而不是必须在项目根目录
  • 支持管理不同的 Python 版本
  • 兼容性很好,支持 Windows

缺点

  • 在 Windows 下,需要使用专用的命令行程序
  • 依赖管理比较弱,需要搭配 pip/Poetry 来使用
  • conda 和 pip/Poetry 组合存在潜在的冲突,但情况在改善

既然一个 Miniconda 就能很好的胜任 Python 版本管理和虚拟环境管理的任务,为什么要用 pyenv+virtualenv/venv+virtualenvwrapper 呢?遗憾的就是依赖管理功能不够完善,和 pip/Poetry 搭配使用则可能会有潜在的冲突。所以,推荐觉得 virtualenv/venv+pip 搭配太麻烦的初学者使用;推荐能接受 Conda+pip/Poetry 这种搭配的人使用;推荐使用 Python 做数据科学相关工作的人使用。

对比之下,最稳定的解决方案大概还是 virtualenv/venv+pip+其他工具……
(如果你发现了错误描述、有不同看法和想要补充的信息,欢迎评论。)

(3)

不要用 Pipenv

注意:本文写于 2019 年 8 月,其中描述的内容在新版本的 Pipenv 中或已得到修复或改进,请谨慎参考。

如果你是《Flask Web 开发实战》的读者,请访问《Flask Web 开发实战》虚拟环境/依赖/Pipenv 等问题解决方法


Pipenv 让我用的很痛苦,有一种被欺骗的感觉,而且很后悔在《Flask Web 开发实战》里采用它。

大部分情况下,它很好用,但却存在太多问题,有一些问题让人简直没法接受。我知道有人会说「这是开源程序,有 bug 就自己去修」、「爱用不用,没人强迫你」,但问题是,一个进行大肆推广,甚至借 PyPA 做背书来宣传(经常让人误以为是 Python 官方推荐)的工具却连基本的使用流程都没做好,这不是合理和正常的行为。 引用这个 HN 评论的话说就是:

Kenneth Retiz 滥用他在 PyPA 的位置(而且快速把一个实际上是 beta 状态的产品的版本号从 0 升到 18)来暗示 Pipenv 已经非常稳定,受到大力支持并且非常官方,但事实却并不是这样。

在这篇(劝退)文章里,我会分别从包的安装、更新、卸载来测试并指出 Pipenv 的一些问题。

测试准备

  • 项目:Bluelog(一个 Flask 博客)
  • Pipenv 版本:2018.11.26(最新版本)
  • 操作系统:Windows 10,Cmder
  • 测试流程:每一次测试命令前都会删除已经创建的虚拟环境(pipenv –rm),重置 Pipfile 和 Pipfile.lock 文件变动,然后重新创建虚拟环境(pipenv install)。

安装包

假设想给这个旧项目 Bluelog 添加新功能,拿到旧项目的代码,打算安装一个 Flask-Avatars 包。查了文档,发现安装包要使用 pipenv install 命令,所以执行了下面的命令:

$ pipenv install flask-avatars

结果发现其他所有的不相干依赖都被更新了……

WTF,这不是反人类吗(说好的「Python Development Workflow for Humans.」呢)?我安装一个包,默认行为竟然是更新其他所有不相干且已经锁定版本的依赖!

翻了文档才发现,要加一个 –keep-outdated 选项才能避免更新其他锁定的依赖:

$ pipenv install --help
...
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED]

好吧,那先忍着,多打一个命令行选项就是了:

$ pipenv install --keep-outdated flask-avatars

WTF,为什么所有依赖还是被更新了?

好吧,有 bug 很正常,我来提个 issue 吧,哎,好像有很多 issue 了?

重点评论:

Kenneth Reitz 先是说 lockfile 只要是过期了就总是会被重新生成(这是什么逻辑?),接着又说用 pipenv update depname,但其他人都回复不起作用(我下面会进行单独测试)。

接着,看到其他评论提到用 –selective-upgrade 选项:

$ pipenv install --help
...
--selective-upgrade Update specified packages.

我又继续使用 –selective-upgrade 选项:

$ pipenv install --selective-upgrade flask-avatars

仍然会更新所有依赖……

对了,顺便还测试了这个命令,依然没用:

$ pipenv install --keep-outdated --selective-upgrade flask-avatars

除了安装某个包会导致所有依赖版本被更新,Pipenv 在解决依赖的冲突上面也有一些不足,比如执行下面的安装命令(具体见 Poetry README):

$ pipenv install oslo.utils==1.4.0

会提示无法安装成功:

ERROR: ERROR: Could not find a version that matches pbr!=0.7,!=2.1.0,<1.0,>=0.6,>=2.0.0

更新包

假设我想更新 Bluelog 这个项目用的 Flask 版本(从 1.0.2 更新到最新的 1.1.1)。查了文档,找到了 update 命令(https://docs.pipenv.org/en/latest/basics/#example-pipenv-upgrade-workflow),于是我执行下面的命令:

$ pipenv update flask
Locking [dev-packages] dependencies…
Success!
Locking [packages] dependencies…
Success!
Updated Pipfile.lock (fd55e3)!
Installing dependencies from Pipfile.lock (fd55e3)…
================================ 26/26 - 00:00:12
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
All dependencies are now up-to-date!

突然看到最后一行赫然写着「All dependencies are now up-to-date!」,我以为是搞错了,赶紧看了下 Pipfile.lock,WTF,为什么我所有的依赖(包括和 Flask 完全不相关的)又都被更新了?
依然,已经有很多相关 issue:

重点评论:

如果这个 issue 没有被锁定,这一句「I have no idea.」下面的图标不知道还会被点多少次。我猜 Kenneth Reitz 对这个 issue 让多少人头疼也没有 idea。

继续搜索,查文档,发现 update 命令也有 –keep-outdated 和 –selective-upgrade 两个选项:

$ pipenv update --help 
... 
--selective-upgrade Update specified packages.
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED]

先来试下 –keep-outdated:

$ pipenv update --keep-outdated flask

no luck,还是更新了所有依赖。继续试一下 –selective-upgrade:

$ pipenv update --selective-upgrade flask

依然没用,仍然会更新所有依赖……

继续查 issue,发现下面这些:

在 #3461 里发现了下面这个评论:

(因为 Frost Ming 是国内的同学,也是核心维护者,说明一下,这里无意冒犯,引用这个评论只是想说明 Pipenv 现在的开发状态。)

这段评论的重点是「In fact, the package name passed as argument is not used at all.」。

也就是说,pipenv update 实际上是不接受包名称参数的。这在下面这个评论也得到了印证:

Here is the important caveat:pipenv updatealwaystargets every package in your lockfile, without exception. It does not accept arguments.

一个还没实现的功能就写到文档里了?这真的不是开玩笑吗?不仅是写到了文档里,还写到了命令行帮助文档里:

$ pipenv update --help
Usage: pipenv update [OPTIONS] [PACKAGES]...

类似下面的场景:

  • 用户:怎么运行程序呢?好,查下文档,文档里说「执行 run 命令就可以运行程序」。哎?怎么没用?
  • 开发者:哦,这个功能还没实现,先写出来让你练练手。

最终的结果就是,如果你想更新一个包,那就只能手动把更新版本的包版本和 hash 编辑到 Pipfile.lock 里。这么做实在是太蠢了。

卸载包

假设我决定不再使用 Gunicorn,需要卸载它,在文档里查到 pipenv uninstall 命令https://docs.pipenv.org/en/latest/basics/#pipenv-uninstall),于是执行下面的命令:

$ pipenv uninstall gunicorn

结果呢?为什么我所有的依赖又都被更新了!?好,我已经习惯了。看命令行帮助文档,同样有 –keep-outdated 命令:

$ pipenv uninstall --help
...
--keep-outdated Keep out-dated dependencies from being updated in
Pipfile.lock. [env var: PIPENV_KEEP_OUTDATED] 

再试一下,虽然我已经不抱期待了:

$ pipenv uninstall --keep-outdated gunicorn

顺便说一句,卸载的另一个问题是,当你卸载一个包的时候,只会卸载这个包本身,而这个包引入的相关依赖都会被保留,需要手动使用 clean 或 sync 命令修正(参考 Poetry README)。

不要使用 Pipenv(至少是现在)

当然,Pipenv 一直在改进。比如 Windows 支持,Lock 很慢的问题,都有过很多的优化(暂且不提没优化之前的痛苦经历)。

但是,种种证据都在表明,这其实是一个半成品。承诺了很多,兑现的却很少。或许过一段时间等它真正成熟了,能够保证基本使用流程,并且可以修改哪些反人类的设定以后再考虑用它(我怀疑这一条是否能实现,除非完全「去 Kenneth Reitz 化」,并且有一个核心维护者能够来推动执行)。

现在,请不要使用它。

我很抱歉在《Flask Web 开发实战》以及文章《Pipenv:新一代Python项目环境与依赖管理工具》中,推动更多人用它,给大家带来潜在的麻烦。我计划了一些补救措施,会逐一执行:

  • 写这篇文章【DONE】
  • 给《Flask Web 开发实战》的五个实例项目追加 requirements.txt 文件,并在 README 中添加说明。
  • 如果《Flask Web 开发实战》能出第二版,修改所有 Python 包安装命令,去掉所有 Pipenv 相关介绍。
  • 写文章介绍替代的几种工具和用法,包括原有的 virtualenv+pip、virtualenvwrapper、Poetry 等。
  • 在 PyCon China 2019 的闪电演讲《Python 虚拟环境和依赖管理工具大乱斗》里提及这个信息。
  • 以后写推荐文章时对这种带着强烈个人风格的项目保持警惕,并对 Kenneth Reitz 这个名字相关的东西保持警惕。

你可以选择用回 virtualenv+pip(+virtualenvwrapper),或是尝试新工具,我会在下一篇文章介绍主要替代品 Poetry 的基本用法。

相关文章

(1)

PyCon China 2019 Tutorial:Python Web 开发第一课

这是在 PyCon China 2019 上海场 9 月 22 号上午九点开始的 Tutorial(实践课程)《Python Web 开发第一课》 的介绍和相关信息。

购票链接:https://www.bagevent.com/event/5886131(Tutorial T3,优惠码 hellogrey)

标题

Python Web 开发第一课

介绍

这是一个面向 Python 程序员的 Web 开发课程,目标听众需要对 Python 基本语法有一定的了解,但对 Web 开发的了解程度没有要求。

在这个课程里,我会将 Python Web 开发所涉及的相关概念进行一个系统的梳理和介绍,包括 HTTP 协议、前端基础知识、常用的 Python Web 框架以及其他各种工具。

这个课程还会包含一个动手编程的环节。我会从最让人头疼的开发环境搭建开始,一步一步教你如何使用 Flask 开发一个简单的 Web 程序。

在课程过后,参与者会对整个 Python Web 开发技术栈有一个全局认识,并掌握基本的 Web 开发知识,而且会对接下来的学习路径有一个清晰的了解。

流程

时长:三小时

一、基本概念

  • Python Web 开发技术栈地图
  • HTTP 协议基础知识(请求与响应、URL 等)
  • 前端基础知识(HTML、CSS、JavaScript、AJAX 等)
  • Python 后端框架的特点和选择(Flask、Django 等)
  • 传统 Web 程序和 Web API 的对比
  • 测试、部署、持续集成等相关概念快速扫盲

二、动手编程

  • 开发环境搭建
  • 运行和调试程序
  • 编写 HTML 模板
  • 添加表单支持
  • 添加数据库支持

三、Q&A

  • 介绍常见的学习误区和建议的学习方向
  • 关于代码或其他任何相关内容的提问

内容难度

初级

目标听众

  • 想了解 Web 开发的前端、运维、测试或其他工程师
  • 想自己做网站的编程爱好者
  • Web 开发或 Python 初学者

听众要求

  • 了解 Python 基本语法
  • 有一台安装了 Python 和浏览器的电脑,并且了解命令行基本操作

讲者介绍

李辉,Flask 等相关项目的维护者,《Flask 入门教程》和《Flask Web 开发实战》的作者,HelloFlask 社区创建者。他撰写过大量技术文章,回答过大量技术问题,在这个过程中积累了一些编程教学的技巧,擅长用简单的语言解释复杂的编程概念。你可以在他的个人网站 greyli.com 了解到更多相关信息。

PyCon China 2019:Python 虚拟环境和依赖管理工具大乱斗

这是在 PyCon China 2019 上海场 9 月 21 号分会场 B 下午 4:40 开始的闪电演讲《Python 虚拟环境和依赖管理工具大乱斗》(时长限定 5 分钟以内) 的介绍和相关信息。

PyCon China 2019 上海场购票链接:https://www.bagevent.com/event/5293611(优惠码 helloflask)

Meta

标题

Python 虚拟环境和依赖管理工具大乱斗

介绍

大多数人都会在 Python 虚拟环境和依赖管理的路上经历重重困难。一开始,你使用 pip + virtualenv + requirements.txt 的工具组合,或者再加上 virtualenvwrapper;接着,更高级的新东西出现了。Pipenv 号称新一代 Python 项目环境和依赖管理工具,打算替代上面的复杂组合,但是发展并不顺利;接着,竞争者出现了,其中实力最强的 Poetry 除了可以替代 Pipenv 来管理依赖之外,甚至还可以让你不用写 setup.py。故事就这样结束了吗?当然没有,尚在草案阶段的 PEP 582 在一边虎视眈眈,试图终结这一切混乱……

总结

加上写相关研究文章的时间,一共花了 36 小时来准备这个演讲(5 分钟),整体效果还不错,后半部分时间太紧说的有点快。

另外最后几天太忙(懒),有几处幻灯片页面样式都使用了行内 CSS,暂时没时间改,就这样吧 :/

蛇蛋:Python 中隐藏的彩蛋和笑话列表

这是一个 Python 中隐藏的彩蛋和笑话列表。如果你还知道其他有趣的彩蛋和笑话,欢迎在 GitHub 上创建 PR 添加。

项目地址:https://github.com/greyli/shedan

Python 比你想象中的更有趣。

blank

A little girl goes into a pet shop and asks for a wabbit. The shop keeper looks down at her, smiles and says:

“Would you like a lovely fluffy little white rabbit, or a cutesy wootesly little brown rabbit?”

“Actually”, says the little girl, “I don’t think my python would notice.”

—Nick Leaton, Wed, 04 Dec 1996, Python Humor

1. Hello World

>>> import __hello__
Hello World!

Note:在 Python 中打印「Hello, World!」最简单的方式。

2. Python 之禅

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Note:Python 设计哲学 & Python 代码风格指南。

3. 《Python 之禅》丢失的一行

《Python 之禅》在 PEP 20 中引入,它本应该是 20 条格言,但是最终只写了 19 条。

Note:也许只是为了说明在文件的结尾总是应该保留一个空行。

4. 一堂简单的人生课

>>> import this
...
>>> love = this
>>> this is love
True
>>> love is True
False
>>> love is False
False
>>> love is not True or False
True
>>> love is not True or False; love is love  # FML
True

Note:不是彩蛋,只是一个解释器里的玩笑。

5. 反重力漫画

>>> import antigravity

Note:这会打开这个 xkcd 漫画,漫画展示了 Python 有多么简单易学。

6. 这不是一个选择,它定义了我们是谁

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Note:这用来快速结束任何关于在 Python 中引入大括号的讨论——不可能!

7. 起源

「Python」这个名字和蛇的种类没有关系。

Note:实际的来源是 Guido van Rossum 喜欢的电视剧《Monty Python’s Flying Circus》。

8. 反差

下面是打印出《Python 之禅》的 this.py 模块的内容:

s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print("".join([d.get(c, c) for c in s]))

生成《Python 之禅》的代码本身违背了自己宣扬的风格建议。它丑陋而不美丽,隐式而不直观。

Note:使用了一种叫 ROT13 的置换加密法。

9. 有没有 C/C++ 用户?

再次引用《Python 之禅》:

There should be one-- and preferably only one --obvious way to do it.

Note:在很多语言里常常有两种方法做同一件事,即 --no 和 no--。这一行包含了一个隐藏的示例。

10. 命名标识符可以非常酷

>>> from math import pi
>>> π = pi
>>> area = π * r**2

>>> résumé = 'knows Python'
>>> 'Python' in résumé
True

>>> 我的英文名 = 'Grey Li'
>>> 我的英文名
'Grey Li'

>>> import webbrowser
>>> 我的网站 = 'http://greyli.com'
>>> webbrowser.open(我的网站)

Note:Python 3 中支持使用 Unicode 字符作为变量名。尽管如此,使用非英文字符作为变量名可能不是一个好主意,不过它确实会让处理科学公式的工作变得更有意思。

11. 选一个见面地点

>>> from antigravity import geohash
>>> # Your location, a date and that date's (or most recent) DJIA opening.
>>> # 你的位置,一个日期和这个日期(或最近)对应的道琼斯工业指数。
>>> geohash(37.421542, -122.085589, b'2005-05-26-10458.68')
37.857713 -122.544543

这可以用来生成一个 GPS 定位,在基于你所在位置的一个 1 经度长和 1 纬度宽的区域里。

Note:这个函数的源码在 这里,工作原理解释可以在这个 xkcd 漫画看到,也许这就是为什么这个函数也放到了 antigravity 模块里。

12. The FLUFL – Friendly Language Uncle For Life from PEP 401 — BDFL Retirement

>>> from __future__ import barry_as_FLUFL
>>> 1 <> 2
True
>>> 1 != 2
  File "<stdin>", line 1
    1 != 2
       ^
SyntaxError: invalid syntax

在认识到 Python 3.0 的不等运算符(!=)非常糟糕,是手指疼痛导致的错误后,FLUFL(指 Uncle Barry)重新恢复钻石型操作符(<>)作为唯一的不等运算符拼写。

Note:PEP 401 是一个愚人节玩笑(从编号可以看出来)。这个 PEP 声明 Guido van Rossum 要退休了。他会获得一个新的头衔,叫做「BDEVIL」(Benevolent Dictator Emeritus Vacationing Indefinitely from the Language,去度无限期语言假期的仁慈退休独裁者),接任者将会是 Barry Warsaw(即 Uncle Barry),Uncle Barry 的官方头衔是「FLUFL」(Friendly Language Uncle For Life,终生友好语言叔叔)。

13. InPynite?

>>> infinity = float('infinity')
>>> hash(infinity)
314159
>>> hash(float('-inf'))
-314159

一个散列值是一个固定尺寸的整型,它会标识一个特定的值。仔细观察,你会发现散列值的无限大是 10^5 x π。有意思的是,在 Python3 中,hash(float('-inf')) 将会生成 -10^5 x π,而在 Python 2 中则是 -271828(即 10^5 x e)。

Note:来源

14. types.CodeType – Not for the faint of heart

如果你开始钻进 Python 的内部,你会在 help 输出看到一个关于 types.CodeType 的警告:不适合心脏脆弱者。

>>> import types
>>> help(types.CodeType)
...
Help on class code in module builtins:                                                    
                                                                                          
class code(object)                                                                        
 |  code(argcount, kwonlyargcount, nlocals, stacksize, flags, codestring,                 
 |        constants, names, varnames, filename, name, firstlineno,                        
 |        lnotab[, freevars[, cellvars]])                                                 
 |                                                                                        
 |  Create a code object.  Not for the faint of heart.                                    
 |                                                                                        
 |  Methods defined here:                                                                 
 |                                                                                                                                       
 ...

翻译自 https://github.com/OrkoHunter/python-easter-eggs 项目,原项目没有许可协议,已通过邮件申请获得翻译和发布许可。

 

PyCon China 2019 闪电演讲和 Flask 主题演讲征集

在 Python 诞生 30 周年之际,PyCon China 2019 将于 9 月 21 日在上海(主会场)举行,今年我们设置了闪电演讲和 Flask 专场,正在征集相关议题。

如果你对演讲不感兴趣,但是想购票参加,可以直接跳到文章结尾。

闪电演讲

5 分钟能做的事情很多,但是你有没有想过用这 5 分钟在技术大会上进行一场闪电演讲?如果你有些心动的话,现在就一个这样的机会放在你面前!

尽管只有 5 分钟,你仍然需要做足准备。反过来,5 分钟并不短,足够让你完成一场让人记忆深刻的精彩演讲。

不用担心自己「资历」不够,因为我们只关心你的演讲内容是否有趣和有质量;也不用担心自己没有演讲经验,因为我们将在会前进行一系列线上培训和交流,帮助你完成几次试讲并给出相应的建议和指导。

无论你最终是否提交议题,只要你感兴趣,都可以加我的微信(备注「闪电演讲」),我会邀请你加入微信交流群。

Flask 主题演讲

除了策划闪电演讲,我还负责策划一个 Flask 专场。如果你在 Flask 方面有过丰富的探索和实践,想和大家分享你的知识和经验,欢迎报名。当然,如果你想分享的内容和 Flask 无关,但和 Python 有关,也欢迎报名。

总而言之,只要你的演讲和 Python 有关,并且内容不算无聊,那就大胆提交你的议题吧!

报名方式和福利

点击下面的链接即可提交议题申请:

https://jinshuju.net/f/BH2z26

报名的城市会场不限上海,报名将在 8 月 10 号截止,如果你申请的是闪电演讲,记得在「演讲类型」选项里勾选对应选项。

如果你的议题成功入选,除了可以在 PyCon China 2019 大会上分享你的想法外,你还可以获得下面的福利:

  • 免费参加 PyCon China 2019 所有城市,所有主题会场;
  • 额外赠送两张对应城市的参会票,方便你带上自己的男朋友或女朋友;
  • 免费参与组委会特别策划的「Python 之夜」大聚会。

购票参会

如果你对演讲不感兴趣,那么报名参加大会也是一个不错的选择,点击下面的链接购买上海场门票(早鸟票 7 月 30 号截止):

https://www.bagevent.com/event/5293611

在这里,你将有机会交到穿着同款格子衬衫而且使用 Python 的朋友,还有机会和很多 Python 技术大牛小牛们面对面交流。我邀请到了两位 Flask 领域的重量级嘉宾,一个是 Flask 的作者 Armin Ronacher,另一个是 Flask 的维护者之一 Hsiaoming Yang(lepture)。Flask 目前的核心维护者 David Lord 虽然没能成行,但是表示可以远程支持 Sprint 活动。

如果你离上海太远,也可以考虑参与其他会场,比如北京、杭州、成都、深圳等等,具体议程可以关注 PyChina 公众号或 PyCon China 官网

PyCon China 2019,期待你的参与!

从国内的 PyPI 镜像(源)安装 Python 包

不论是使用 pip,还是 Pipenv、Poetry等工具,安装 Python 包的时候会默认从官方的 PyPI 源下载文件,速度比较慢。国内的一些公司和机构提供了 PyPI 镜像源(mirror source),你可以设置让这些工具从国内的镜像源安装 Python 包,以便提高下载速度。

官方 PyPI 源的 URL 为 https://pypi.org/simple (旧的 URL 为 https://pypi.python.org/simple ),下面我们将以豆瓣提供的镜像源为例(URL 为 https://pypi.doubanio.com/simple/),介绍不同工具更改 PyPI 镜像源的方法:

pip

临时设置可以通过 -i 选项:

$ pip install -i https://pypi.doubanio.com/simple/ flask

全局设置有不同的层级和文件位置,以用户全局(per-user)为例,在 Linux & macOS 中,配置需要写到 ~/.pip/pip.conf 文件中;Windows 中,配置文件位置为 %HOMEPATH%\pip\pip.ini,%HOMEPATH% 即你的用户文件夹,一般为“\Users\<你的用户名>”,具体值可以使用 echo %HOMEPATH% 命令查看。

通常你需要手动创建对应的目录和文件,然后写入下面的内容:

[global]
index-url = https://pypi.doubanio.com/simple
[install]
trusted-host = pypi.doubanio.com

附注:按照 pip 文档,上面的配置文件位置是旧(legacy)的配置方式,但是因为比较方便设置,这里沿用了。新的建议是 Linux & macOS 放到 $HOME/.config/pip/pip.conf,Windows 则放到 %APPDATA%\pip\pip.ini。具体可以访问 pip 文档配置部分查看。

Pipenv

类似 pip 的 -i (–index-url)选项,你可以使用 –pypi-mirror 临时设置镜像源地址:

$ pipenv install --pypi-mirror https://pypi.doubanio.com/simple flask

如果想对项目全局(per-project)设置,可以修改 Pipfile 中 [[source]] 小节:

[[source]]

url = "https://pypi.doubanio.com/simple"
verify_ssl = true
name = "douban"

另外一种方式是使用环境变量 PIPENV_PYPI_MIRROR 设置(Windows 系统使用 set 命令):

$ export PIPENV_PYPI_MIRROR=https://pypi.doubanio.com/simple

你可以通过把这个环境变量的设置语句写入到终端的配置文件里实现“永久”设置,Linux & macOS 可参考这里,Windows 可参考这里

Poetry / Flit

因为 Poetry,Flit 这些工具遵循 PEP 518 创建了一个 pyproject.toml 文件来替代 setup.py、Pipfile 等配置文件,所以我们可以在这个文件里更改 PyPI 源。

使用 Poetry 时,在 pyproject.toml 末尾添加下面的内容来设置自定义镜像源:

[[tool.poetry.source]]
name = "douban"
url = "https://pypi.doubanio.com/simple/"

目前暂时没有其他方式,未来或许会为 poetry add 命令添加一个相关的设置选项。

同样的,Flit 大概要添加下面这些内容(未测试):

[[tool.flit.source]]
name = "douban"
url = "https://pypi.doubanio.com/simple/"

常用的国内 PyPI 镜像列表

  • 豆瓣 https://pypi.doubanio.com/simple/
  • 网易 https://mirrors.163.com/pypi/simple/
  • 阿里云 https://mirrors.aliyun.com/pypi/simple/
  • 清华大学 https://pypi.tuna.tsinghua.edu.cn/simple/

顺便提一下,使用镜像源需要注意一个问题:包的版本可能不会及时更新,遇到这种情况可以通过临时换回官方源解决。