因受

最近学习python，发现整数比较时一个有趣的现象： 12345678910111213141516a = 256b = 256print id(a)print id(b)print(a == b)print(a is b)print(id(a) == id(b))print(id(a) is id(b))c = 257d = 257print id(c)print id(d)print(c == d)print(c is d)print(id(c) == id(d))print(id(c) is id(d)) 在pycharm中运行的结果是： 1234567891011123201910432019104TrueTrueTrueFalse4055042440550424TrueTrueTrueFalse 而在Python IDE中运行： 1234567891011121314151617181920>>> a = 256>>> b = 256>>> a == bTrue>>> a is bTrue>&...

1. Python中的“*”总结对于一般的Python使用者来说，清楚Python中的“*”号是作为乘法运算符就足够了，但是如果你想要更进一步，想要在Python领域中更进一步的话，就需要了解Python中“星号”的五个强大的用途。 1.1. 1.作为乘法或者是乘幂运算符 作为基础的Python应用，乘法运算和乘幂运算是大家最容易想到的星号作用。上述程序中，单个星号运算符起到了乘法运算的目的，而连续的两个乘号起到了乘幂运算的目的。从结果可以看出，3*3的结果是9，而3的3次方是27。 1.2. 2.接收多个参数当我们在编写函数时，有时候函数的参数数量太多，所以我们想尽量的缩短程序，让程序看起来简介，除此之外，我们可能不知道函数有多少个具体的参数，这个时候，就可以用星号来发挥作用。 上述程序中，单个星号起到的作用是帮助我们捕获多个位置参数，然后将其放入到字典中，需要注意的是，在传入参数时，它的顺序位置需要明确，以方便在函数调用中使用。 而对于双星号的参数，可以帮助我们捕获多个带关键字名字的参数，并放入到字典中去，这样的话，我们在程序内使用的时候，可以根据关键字名字来调用，而...

在 Jupyter notebooks 中进行单元测试我们都知道开发过程中应该编写单元测试，实际上我们中的许多人都这样做。对于生产代码，库代码，或者归因于测试驱动的开发过程，这一点尤其正确。 通常，Jupyter notebooks用于数据探究，因此用户可能不选择（或不需要）为其代码编写单元测试，因为当他们在Jupyter中运行时，通常会查看每个单元格的结果，然后得出结论，之后继续。但是，以我的经验来看，Jupyter通常会发生的情况是，Jupyter中的代码很快就超出了数据探究的范围，对于进一步的工作很有用。或者，Jupyter本身可能会产生有用的结果，需要定期运行。也许需要维护代码并将其与外部数据源集成。然后，确保可以测试和验证notebook中的代码就变得很重要。 在这种情况下，我们有哪些选择对Jupyter代码来进行单元测试？在本文中，我将介绍在Jupyter notebooks中对Python代码进行单元测试的几个选项。 也许只是不做？ Jupyter notebook 单元测试的第一个选择是根本不做。这样，我并不是说不要对代码进行单元测试，而是将其从notebook ...

SPEC 基础知识 写 RPM 包的核心，不是命令多复杂，而是把“构建过程”和“最终安装内容”写清楚。 这篇文章以 rpmbuild 为主线，整理一份可直接落地的 SPEC 入门指南。 1. SPEC 文件是什么SPEC 是 RPM 的打包脚本与元数据描述文件。它决定了： 包叫什么、版本是多少。 构建时需要什么依赖。 代码如何编译、安装到临时目录。 最终哪些文件进 RPM 包。 可以理解成：元信息 + 构建脚本 + 打包清单。 2. 最小可用 SPEC 模板123456789101112131415161718192021222324252627282930313233Name: helloVersion: 1.0.0Release: 1%{?dist}Summary: A simple hello packageLicense: MITURL: https://example.com/helloSource0: %{name}-%{version}.tar....

SPEC file writing - Best Practices这篇是 SPEC 系列的“最佳实践清单”。 目标不是再讲语法，而是减少线上踩坑、提升包的可维护性。 1. 头部字段不要留空Summary、License、URL、%description 等信息必须完整。这些信息会直接体现在 rpm -qi 输出里，也是排障和审计的第一入口。 2. 头部字段对齐，降低阅读成本推荐统一列宽对齐： 123456Name: mydaemonVersion: 1.2.0Release: 1%{?dist}Summary: My daemon serviceLicense: MITURL: https://example.com/mydaemon 团队协作里，这种“无功能变化但提升可读性”的规范非常值。 3. 分段清晰，段内紧凑建议： 段与段之间空一行。 段内不要插入无意义空行。 注释聚焦“为什么”，不要重复“做了什么”。 4. 能用宏就不要写死路径避免硬编码 /usr、/et...

Makefile.am 的例子这篇用“能直接抄走改”的方式，整理 Automake 常见写法。如果你已经会写 Makefile，这篇重点是：如何把规则写进 Makefile.am，再由 Autotools 生成可移植构建系统。 1. 先理解三层关系 configure.ac：定义项目配置逻辑（检测依赖、生成哪些 Makefile）。 Makefile.am：声明各目录编译/安装规则。 configure + make：生成 Makefile.in/Makefile 后执行构建。 一句话：configure.ac 管“配置”，Makefile.am 管“目标与安装”。 2. 最小项目结构示例12345678myapp/ configure.ac Makefile.am src/ Makefile.am main.c include/ myapp.h 顶层 configure.ac： 123456789AC_INIT([myapp], [1.0.0], [you@example.com])AM_INIT_AUTOMAKE([foreign subdi...

How to write SPEC file 如果说《SPEC 基础知识》解决“能打包”，这一篇解决的是“如何把 SPEC 写得可维护、可扩展、可发布”。 1. 先建立一个正确心智模型打包过程可以拆成三层： 上游构建系统（configure / Makefile）决定“会生成哪些文件”。 SPEC 的 %install 决定“这些文件安装到 %{buildroot} 的哪个路径”。 SPEC 的 %files 决定“最终哪些文件进入哪个 RPM 包”。 核心结论：SPEC 不负责创造文件，只负责组织和选择文件。 2. 从 Makefile 安装路径到 %files 的映射假设上游项目里有： 12scriptdir = $(libexecdir)/mydaemon/scriptsscript_SCRIPTS = conf/a.sh conf/b.sh conf/c.sh 执行 make install DESTDIR=%{buildroot} 后，文件会进入： 1%{buildroot}%{_libexecdir}/mydaemon/scripts/ 在 SPEC 中...

configure.ac 介绍configure.ac 是 Autotools 的配置入口文件。它的作用是：在不同机器上探测编译环境，并生成可用的 configure 脚本与 Makefile。 可以把它理解成“构建前的环境协商脚本”。 参考： https://www.gnu.org/software/autoconf/manual/autoconf.html https://www.gnu.org/software/automake/manual/html_node/index.html 1. configure.ac 到底负责什么核心职责有 4 个： 定义项目元信息（名字、版本、最低工具版本）。 检测工具链、头文件、库、函数是否可用。 定义条件编译和可替换变量。 生成目标文件（config.h、各目录 Makefile、其他 .in 模板）。 2. 常见宏分组（按用途记忆）2.1. 项目初始化1234AC_PREREQ([2.69])AC_INIT([myapp], [1.0.0], [you@example.com])AC_CONFIG_SRCDIR([src...

automake基础作为 Linux 下的程序开发人员，大家一定都遇到过 Makefile。用 make 命令来编译程序确实很方便。一般情况下，手工写一个简单 Makefile 并不难；但如果要写出一个符合自由软件惯例、可移植、可维护的 Makefile，就没那么容易了。 本文介绍如何使用 autoconf 和 automake 自动生成规范的构建文件。最终效果是像常见 GNU 程序一样，通过： ./configure make make install 完成构建与安装。 1. Makefile 介绍Makefile 用于自动化编译和链接。一个工程通常包含多个源文件，不是每次都需要全量重编译。Makefile 通过“依赖关系”判断哪些目标需要重新构建，从而节省时间。 手写 Makefile 的常见问题： 规则容易和本机环境绑定。 路径或变量变化后需要手工调整。 跨平台和多人协作维护成本高。 automake/autoconf 的价值在于： 你只需写少量声明式模板（configure.ac、Makefile.am）。 工具自动生成 configure 和 Makefil...

Jenkinsfile 是 CI/CD 流水线的“代码化配置文件”。 把构建、测试、发布流程写进仓库后，流水线就可以版本化、可复用、可审计。 1. Jenkinsfile 基本语法1.1. Pipeline 的定义方式Pipeline 通常有 3 种维护方式： 在 Blue Ocean 中可视化创建。 在 Jenkins 经典 UI 中直接配置脚本。 在代码仓库中维护 Jenkinsfile（推荐）。 最常见的是第 3 种：和代码一起评审、一起发布。 1.2. 一个最小可运行的声明式 Pipeline1234567891011121314151617181920212223242526272829pipeline { agent any environment { APP_NAME = "demo-app" } parameters { string(name: 'DEPLOY_ENV', defaultValue: 'staging', description: '部署环境') booleanParam(name: 'RUN_TEST', ...