Laurence的技术博客

简单讲：Conda 的 Channel 就是 Repo，与 Yum 和 Maven 中的 Repository 是一样的，用于存放各种 Python 包的公共库。以下几个 Channel 是 Conda 中最为常见的，简单介绍一下. Default Channel：顾名思义，默认的 Channel，它由 Anaconda 公司维护Anaconda Channel：是由社区维护的，通常比默认 Channel 包含更多的包，更新也更快

【代码】PIP 常用操作汇总。

(参考：https://github.com/zeromq/pyzmq/issues/1505），但是在复杂的依赖状况下，这种方法可能改起来会很麻烦。出现这个问题可能和你本地使用了某种VPN软件有关，解决这个问题有两种说法，一种是降低 pyzmq 版本至。经测试，上述方法有效！

最近同时在Window和Linux上交替使用Virtualenv和Anaconda，期间一直在思考两种工具哪一个更好？是否可以统一使用其中一个完成所有Python项目的环境构建？两者共存，机器学习项目优先选择Conda，其他类型项目视情况而定，可能多数会以Virtualenv为主；使用更轻量的Miniconda替代Anaconda；依然在本地安装并建立系统级Python环境 （与Virtualenv配合工作）；禁止Conda全权接管本地Python环境和虚拟环境

在Windows上安装某些Python依赖包时经常会遇到如下错误，其原因是：安装包（此处是box2d-py）没有找到Microsoft Visual C++ 14.0或更高版本的运行环境，所以无法正常启动。解决方法如错误信息中给出的提示：在本地安装上MSVC 14+版本即可。由于安装完整的Microsoft C++ Build Tools会占用巨大的磁盘空间，如果不是在Windows上开发C++应用完全没有比较全部安装，在我们的场景下，只需要MSVC的运行时环境，因此只需选择: 核心组件 + MSVCv14

使用Anaconda / Conda时有这样一个常见需求：在Windows右键菜单中添加：Condar Here (在此处打开Conda)，单击后会打开一个命令行窗口，并自动执行conda的activate.bat脚本激活conda（使conda等命令直接可用，无需输入绝对路径），同时还能自动定位到当前目录，以下是注册表脚本，请根据自身环境替换activate.bat路径，菜单显式文本是"Conda Here"，也可以自行修改

安转Anaconda / Miniconda时，安装向导中会有这样一个选项：“Add Miniconda3 to my PATH environment variable”,如果勾选，会给出红色提示，说有可能影响与其他应用程序冲突。经过测试发现，冲突主要来自于系统中安装的其他版本的Python。因为安装Anaconda / Miniconda并不需要Python，它通常会自带一个版本的Python（当然，用户也可以选择系统中现有的Python），如果你选择使用Anaconda / Miniconda自带的P

该问题一般发生在Windows系统上，如果项目依赖到gym，就有可能触发该问题，因为AutoROM是gym的一个依赖，错误信息如下：ImportError: It seems that you are trying to install the Atari ROMs on Windows. While this is not supported, the DLL error can be solved by installing the OpenSSL DLLs。根具官方建议：在Windows上下载并安装O

既然程序能成功运行，就说明鸭子类型的示例代码能够通过Python的（运行期）类型检查。在Python中，由于它的“动态”特性，导致变量的类型随时可以变化，在这样的前提下，如果你是Python解释器的设计者，要怎么进行“类型检查”呢？你只能让Python解释器放宽“类型检查”的条件：只要在当前的上下文中（例如一个函数体内），调用方对这个类型所期望的属性和方法它都有，那它就是那个“正确的”类型。如果换做是其他语言，鸭子类型大概率会使用接口（Interface）进行定义，在Python这种动态语言里就是鸭子类型

安装Anaconda会自动安装Conda，如果上述官方地址下载缓慢，可切换为阿里云镜像，conda能解决很多ML库的安装问题，因为很多ML库会依赖OS上的一些C/C++的库，conda可以自行安装缺失的依赖，而virtualenv则不行。如下命令将创建一个名为my-python-env的虚拟环境，同时安装3.7版本的python。conda不同于virtualenv的地方在于：conda管理的包超越了python的范畴，可以是其他形式的安装包

产生这个错误的原因是因为：markupsafe从2.1.0版本开始已经不再支持soft_unicode，如果项目中引入了高版本的markupsafe就有可能报这个错。也没有关系，markupsafe-2.0.1依然会成功安装！

在虚拟环境工具的加持下，清空Python环境下所有安装包的需求并不常见，因为每次新构建的Python环境都是“纯净”的，需要手动清理的场合一般是针对系统Python环境进行的。我们知道，按照最佳实践来说：我们应该总是在一个虚拟的Python环境中工作，哪怕平实运行一些简单的Python脚本和程序，这样可以保证本地Python环境永远是纯净的，没有任何第三方包存在。执行完毕后pip list。

PyCharm/IntelliJ IDEA已经内置了对virtualenv的支持，我们要考虑的是：在本地启用了virtualenvwrapper的情况下，如何将virtualenvwrapper创建的虚拟环境和PyCharm/IntelliJ IDEA创建的虚拟环境对齐，也就是保持一致的视图。这件事要分两个方向看：1. 在PyCharm/IntelliJ IDEA上使用virtualenvwrapper创建的虚拟环境；2. 在virtualenvwrapper中使用PyCharm/IntelliJ IDEA

而swig并不是一个python库，应该说算是一个系统级别的库，在Linux，Windows和Mac上都有不同的发行包，无法通过pip自动安装。所以，在初次构建依赖到gym的Python项目时就会遇到“ERROR: Failed building wheel for box2d-py”错误，原因就是本地操作系统上没有安装swig。此外：网上有文章提到的：手动安装box2d的做法并不适用本文所说的情况，经过测试，box2d-py作为一个Python库是可以被pip自动安装的，并不是需要手动安装。

virtualenv已经可以支持正常的Python项目开发了，在工程目录下创建伴随项目的虚拟环境子目录也挑不出毛病。大概是有不少开发者认为virtualenv的一些工作可以进一步封装和简化，他们倾向于用一种集中式的思维和视角来管理虚拟环境，于是就有了在virtualenv基础上又包装了一层的虚拟环境统一管理工具：virtualenvwrapper,接下来我们介绍一下virtualenvwrapper的使用。（注：本文操作环境是Windows系统！）

介绍如何在Linux上查看和设置全局或局部的Python镜像源。根据官方文档: [https://pip.pypa.io/en/stable/topics/configuration/](https://pip.pypa.io/en/stable/topics/configuration/) 的解释，PIP的配置有三个“层级”，分别对应着三个配置文件，且在Linux/Windows下都存放于不同的位置。这三个层级分别是：- Global: 系统级- User: 用户级- Site: （虚拟）环境

目前Yum的Python版本是3.7，如需安装更高版本，需要从源代码编译安装。

本文我正式进入Virtualenv的使用环节。注：本文操作环境是Windows系统！注意：如果本地安装了多套Python系统环境，我们并不需要在每一套环境上都安装virtualenv，因为Virtualenv可以-p参数来设定Python解释器的路径，通过给出的解释器路径就能定位整个Python安装环境，进而可以复制相关文件，构造基于该版本的虚拟环境。所以，通常在系统默认的Python环境下安装一份就够了。

在Virtualenv等工具引入之前，Python是没有“虚拟环境”这一概念的，一个Python环境指的就是在本地操作系统上安装的Python，由于Python自身版本的兼容性问题，Python用户通常会在操作系统上安装多个不同版本的Python，也就形成了多套Python环境共存的局面，我们把这些实际安装在操作系统上的Python环境统称为“（Python）系统环境”，或者叫“（Python）本地环境”。最后是一点点探索和思考。虚拟环境的标准用法是面向一个Python项目构建一个独立的虚拟环境，即。

多版本依赖管理是一直是Python的一个痛点，广受诟病，尽管这么多年下来，Python早已提出了以“虚拟环境”为代表的多种成熟解决方案，但这依然难掩Python在设计之出在包管理系统上犯下的理念性错误。Python的包管理系统与`Yum`非常类似，可能在设计之出就是借鉴了Yum等Linux系统包管理工具的设计理念。这导致了Python包管理系统存在一个天生的缺陷：**同一软件包只允许存在一个版本**！这给Python后来带来了麻烦。

1. 位置参数，2. 可变参数，3. 关键字参数，4. 命名关键字参数，5. 多种参数形式组合，6. 代表任意可能参数的参数列表。注： 本文不会把“默认参数”(实际上应该称之为参数默认值才准确)作为一种独立的参数形式讲解，它实际上只是给参数赋予默认值的一种做法，可应用于位置参数和命名关键字参数等多种场合

如果我们想为这个函数，也包括所有其他函数添加一个自动日志的功能，以便记录一下函数调用前后的时间，这是一个典型的“横切”场景，实际上，更加具有实际应用价值的一个案例是：在方法调用前启动一个事务，在方法执行完毕后提交一个事务，此类是更加典型的案例。首先，我们要注意一下这个log的函数的整体“框架”：它先在函数体内定义了一个子函数warp，然后log函数最终返回的其实是wrap函数。至此，“朴素版”的装饰器函数log就算实现完成了，由于类似的装饰场景普遍存在，Python在语法层面上提升了对这一模式的支持力度，

在Python中，函数作为与对象地位相同的“一等”公民，是有最基本的“资格认证”的：函数也拥有对象模型的三个通用属性：id、类型、值。反过看，既然函数本质上已经是一个对象了，那么一个类（对象）也可以很容易地“成为”一个函数：即使用方法和调用函数一样。时，就是单纯地引用函数（对象）本身了，此时，它可以赋值给另一个变量，也可以作为参数传递或作为返回值返回。从这个示例中我们可以看到，在Python中，函数和对象实际上是双向打通的！地位是一样的，且可以相互转换。时就是在调用/执行函数，但当仅仅使用函数名不带。

在上篇文章《Python笔记 · 私有方法、私有属性 & 单下划线、双下划线》我们介绍过以前置双下划线开始，后置双下划线结束的方法名：，这是系统定义的一批特殊函数，通常被称之为：魔法函数（Magic Methods 或 Dunder Methods），其中Dunder意为：“Double Under (Underscores)”。本文我们就对这些Dunder函数做一次系统介绍。魔法函数并不会被直接调用，而在类的某些特殊行为发生时被自动调用。实际上，从其他语言观察Python的这些魔法函数，都有对应的解决方案

尽管对于Python程序员来说已经司空见惯，但是那些从非动态语言转过来的程序员在初次看到就是在定义对象属性时会感到“离奇”：一个未经声明（类似那样）变量，直接从self中“点”出来，后面跟一个赋值就同时完成了“添加属性”并“为其赋值”的二合一操作。这其中，当属这个操作最能体现Python的“动态性”了：当我们要“.”的时候，就是我们想给对象加属性或方法的时候了，没有预先的属性声明（类似那样），在任何需要的时候，直接“.”一个属性，就添加了一个属性，这就是“动态”的实际表现。鉴于Python动态添加属性/方法

首先，不同于其他编程语言，Python中不存在真正意义上的“私有方法/属性”，Python中所胃的“私有方法”要么基于约定，要么基于编译期的改写（Name Mangling）。与私有方法、私有属性密切相关的是单下划线、双下划线。

首先，`self`和`cls`并不是关键字，而是约定的统一命名规范。简单说：self用于指代实例/对象（Instance/Object），cls用于指代类（Class）。两者经常以参数形式出现在类方法中，通过它们，类方法可以读取或修改实例或类的状态，以及调用相关方法。

在《Python笔记 · With语法糖》这篇文章中我们提到：在Airflow中通过With构建DAG时，不必显示地将Operator添加到DAG中，只要是在With语句块内声明的Operator，都会被自动添加到DAG里。本文我们来详细说明一下这件事是怎么做到的。首先，我们知道，可以配合With关键字一起使用的Class必定实现了__enter__和__exit__两个魔法方法，DAG也不例外，我们来看一下DAG这两个方法的实现(本文使用的是Airflow 2.1.0版本的源码)

With的主要设计初衷和应用场景是用于异常处理，尤其是涉及资源申请和释放的场景。本质上，With是一段try…except…finally代码块，但应用起来要比try…except…finally干净优雅，所以会在Python程序中大量使用。With之所以能简化try…except…finally代码也没有什么特别的“秘密”，实际上它需要被操作的类“配合”才行，简单说就是实现__enter__和__exit__两个方法，而实现了这两个方法的类也被称之为上下文管理器(Context Manager)。