Streamlit 是一个 Python Web 应用框架。但和常规 Web 框架，如 Flask/Django 的不同之处在于，它不需要你去编写任何客户端代码（HTML/CSS/JS），只需要编写普通的 Python 模块，就可以在很短的时间内创建美观并具备高度交互性的界面，从而快速生成数据分析或者机器学习的结果；另一方面，和那些只能通过拖拽生成的工具也不同的是，你仍然具有对代码的完整控制权。
也许最令人惊讶的是，我们可以完全抛弃复杂的回调/异步代码，以及服务器/客户端之间繁琐的通信细节，而创建的程序仍然是实时和动态的，这令人耳目一新。尽管 Streamlit 也有它自己的限制，但是在了解它以后，相信你会感叹“原来还有这种操作”（哪怕你并不关心数据分析或机器学习）。
通过本文，我们会了解到 Streamlit 的使用方法，包括各种构建块（Building Block）和编写方法，并初步了解它的运行机制，以及缓存、配置和部署等相关话题。
作为（伪）松鼠党，多年来也我积累了大量资源，终于到了好几个移动硬盘都装不下的地步。我也很担心万一哪个盘某天突然坏了，里面的所有内容都付之东流，于是动了把这些资源转存到云端的心思。
当然，在作这个迁移之前，首先我应当考虑清楚自己的需求，以及有哪些可能的解决方案。这些资源中大部分是从网络上收集来的，属于有价值、但是万一丢失也可以接受的内容，同时容量太大（几个 TB）。因此不同于个人的重要资料，我需要找一个可长期保存、以允许非 100% 的可靠性来换取较低平均价格的方案。同时，考虑各种现实方案的可行性：
按照规定，Flask 的模板默认放在 app 所属的 templates 子目录下，但也可以通过构造参数 template_folder （以及类似的 static_folder）来修改。同时，在 Blueprint 的构造方法中也包含同样的 template_folder/static_folder 参数。我从前并未真正修改过这些参数，按照一般的理论推测，既然 Blueprint 提供了这些参数，那么它应该覆盖 app 级别的配置才对。
这几天要写一个 Flask 程序，由于相关模块较多，都堆在一起找起来很麻烦，也容易产生无疑的耦合。因此我考虑采用另外一种代码布局，即把每个 Blueprint 和它所使用的模板一起存放，同时和其他模块分离开来。哪知道，修改以后才发现这样无法工作：不管怎么配置 App/Blueprint 的参数，所有 index.html 都会显示同一个页面。
最近在使用 Python 的时候发生了很奇怪的现象：从命令行执行 python.exe 并不会进入 REPL，似乎也没有其他反应，然而稍等片刻，会看到系统弹出 Windows Store 页面，并定位到 Python App 的详情页。
这个现象让我很是迷惑了一下，还以为是 Python 运行环境出了什么状况，但很快反应过来，从现象看，应该是 Windows 搞的鬼。
Flask 框架提供了蓝图（Blueprint）的概念，作为划分大型网站的主要工具。但对于地址较为复杂的网站，仅靠 Blueprint 仍然是不够的。以个人博客为例，如果我们把它规划为个人网站的一个子分区，那么很自然地会设置一个 url_prefix='/blog' 的蓝图。但 blog 下面可能不只是一个简单的平面结构，还会有更多的层次，类似这样：
当然，我们仍然可以逐项在路由中添加必要的前缀，但是这样显然违反了 DIY 原则。有没有办法将 Blueprint 再进行细分呢？
信号（Signal）是 Flask 中一个比较鲜为人知的功能，在官方文档中也对此着墨不多。的确，Signal 并不是 Flask 的核心功能————你完全可以在不使用 Signal 的前提下写出完整的 Flask 应用。但在某些场景下，使用 Signal 有助于避免代码中不必要的耦合，提高可维护性；并且，部分工程化实践，比如针对特定逻辑进行的测试，需要借助 Signal 的帮助才能完成（后面我们会看到一个具体的例子）。因此，本文将帮助你了解什么是 Signal，它的原理、使用方法，以及它在 Flask 中有哪些实际应用。
在 Flask 中，蓝图（Blueprint）通常是基于路径进行分派的，因此我们看到典型的注册代码一般类似这样：
app.register_blueprint(home_bp, url_prefix='...')
相对少见的另一种用法是，Blueprint 也可以通过子域名来分派，这涉及到程序结构上会有一些改变，同时也会带来一些新的问题（当然都是可以解决的）。使用子域名是大型网站的常规做法，同时也使得 URL 路径更有针对性，比如提供一个 https://api.mydomain.com/... 比起所有页面都堆到 https://mydomain.com/ 下面，看上去也显得更专业一些。我自己也在尝试通过这种方式重构自己的网站，最开始尝试的是每个域名使用一个单独的 app 去管理，但很快发现如果一些比较小的功能也做成独立的网站，会带来比较多额外的管理负担。因此，把这些功能合并到一个app，对外又能通过子域名公开，是不错的做法。因此，我对这种实现做了一些尝试，并对遇到的问题和解决办法做一个记录，以供自己和其他朋友参考。
在本系列前面的文章中，我们已经提到过 PyInstaller 的 Hook，不过尚未详细说明它是怎么回事。本文就将介绍关于 Hook 的知识。
注意，本文讲述的内容属于比较高级的部分，一般用户可以如果没有问题的话，可以不用特意去关心它。但是在如果发生下列情况之一，你可能还是需要对 Hook 有点基本的了解：
在本系列的 基本用法 篇中我们曾说过，PyInstaller 在生成文件的同时会创建一个相应的 .spec 文件。其实，.spec 文件才是生成过程的真正核心。它本质上是一个特殊的 Python 脚本，其中记录了生成所需的指令，和包管理所使用的 setup.py 在某种程度上有些相似。当熟悉它的格式以后，你也可以按自己的意愿去修改此文件，并且某些特殊场景下修改 .spec 文件是最简便的方法。本文就讲述 spec 文件的格式、原理和一些常用使用案例。
在 本文系列前一篇 - 简介 中，我们介绍了 PyInstaller 的入门知识。本文重点讲解一下 PyInstaller 的单目录（onedir）和单文件(onefile) 模式，并解释我个人一直强调的观点：不应该使用单文件模式。
这是本系列的第一篇，介绍 PyInstaller 的基础知识。
PyInstaller 是一个跨平台的 Python 应用打包工具，支持 Windows/Linux/MacOS 三大主流平台，能够把 Python 脚本及其所在的 Python 解释器打包成可执行文件，从而允许最终用户在无需安装 Python 的情况下执行你的程序。
本文系列介绍 PyInstaller 的使用知识和一些技术性的内幕，以便读者更好地掌握 PyInstaller，正确打包程序。
最近有不少朋友反映用 PIP 更新包时遇到了问题，典型场景之一是在 PyCharm 中更新软件包，可能遇到如下的出错信息（截屏来自 JetBrains 社区）:
在多数项目中，总有一些几乎一成不变的 CRUD 操作，编写这些代码很无聊，但又是整个系统必不可少的功能之一。我们在上一个项目中也面临类似的问题，虽然已经实现了一个功能相对完整的管理后台，也尽量做到了代码复用，但随着项目规模的增长，需要编写的样本代码也不断膨胀，占用了大量开发时间。
今日新闻：Python 2.7 支持将于 2020 年 1 月 1 日终止 近日，Python语言作者Guido van Rossum在邮件列表上宣布 Python 2.7将于2020年1月1日终止支持。用户如果想要在这个日期之后继续得到与Python 2.7有关的支持，则需要付费给商业供应商。
PyCharm 小知识系列索引
Flask 是著名的 Python Web 微框架，而 《Flask Web 开发——基于 Python 的 Web 应用开发实战》（OReilly出版社出品，以一只大狗作为封面，所以也有人戏称“狗书”）则是这一框架的经典书籍。特别是该书的第七章，描述如何将网站划分为多个模块，很多 Flask 网站都是参照该例子的形式进行规划的。
我的 个人主页 也用了 Flask 框架来开发，网站结构在很大程度上参考了该书的示例。但在开发过程中，我也感觉到该方式也有一些不够合理的地方，主要表现在：
