小小张说故事

摘要： 系列：Python 底层设计逻辑｜类型：排错清单型｜分发：CSDN / 博客园 / 腾讯云 字数：约 1500 字 结论先行：*args 把多出来的位置参数收成一个元组，**kwargs 把多出来的关键字参数收成一个字典。它不是"任意参数"的魔法，而是"打包/解包"语法。* 解包可迭代对象，** 解 阅读全文

摘要： 先给结论：if __name__ == '__main__' 不是"程序入口"的仪式感，它是一道防止模块被导入时误执行的闸门。不写它，最轻的后果是导入一个模块就顺手连了数据库、跑了三分钟的脚本；最重的后果是 Windows 上一跑 multiprocessing 直接无限递归启动子进程然后崩掉。 几 阅读全文

摘要： 先给结论：__new__ 才是真正的构造函数，它负责"造出"对象；__init__ 只是初始化函数，它拿到的是已经造好的对象，往里填属性。 很多人写了几年 Python，一直把 __init__ 当成构造函数。这在多数场景下不影响写代码，但一旦遇到不可变类型、单例模式、对象缓存，就会撞上一些怎么调都 阅读全文

摘要： LightGBM 为什么比 XGBoost 快这么多？直方图、GOSS、leaf-wise 三个优化一次讲透 训练一个 XGBoost 模型要等十分钟，换 LightGBM 同样的数据只要一分钟，精度还差不多。这不是玄学，是两者在构造决策树的方式上有根本差异。 这篇文章解决四件事：LightGBM 阅读全文

摘要： XGBoost 和 LightGBM 你已经调得很熟了，但只要数据里有一堆字符串类型的类别列，就免不了一段重复劳动：pd.get_dummies() 一下炸出几百列，或者 LabelEncoder 随手写上却悄悄引入了不存在的大小关系。 CatBoost 解决的就是这一件事——类别特征可以直接喂进去 阅读全文

摘要： 训练一个 XGBoost 模型要等十分钟，换 LightGBM 同样的数据只要一分钟，精度还差不多。这不是玄学，是两者在构造决策树的方式上有根本差异。 这篇文章解决四件事：LightGBM 为什么快、三个核心优化各自解决什么问题、Python 从训练到调参的完整代码、以及我踩过的 5 个坑。看完你能 阅读全文

摘要： 你有没有写过这样的代码：给 10 个请求各开一个线程，结果耗时和单线程差不多，CPU 还飙到 100%？或者线程开到几百个，程序直接卡死不动。 这不是你代码写错了，而是用错了并发模型。Python 的多线程在 IO 密集场景下，远没有你想象中那么"多线程"。 这篇文章解决三件事：Python 多线程 阅读全文

摘要： 一、开头痛点：驱动、等待、玄学报错 做过网页自动化的同学，大概率被这三件事折磨过： 装驱动：chromedriver 的版本必须和本机 Chrome 严丝合缝，浏览器一自动升级，脚本第二天就 SessionNotCreatedException。 等元素：页面还没渲染完就 find_element， 阅读全文

摘要： 一、开头痛点：想把数据变成应用，却被前端劝退 很多 Python 工程师都遇到过这样的尴尬：用 pandas 跑出一串漂亮的分析结果，用 matplotlib 画出几张图，最后只能截图发群里，或者用 Jupyter Notebook 自己看。想把它做成「别人打开网页就能用」的工具，就得学 HTML、 阅读全文

摘要： 写代码不写测试，改一处崩一片。Python 标准库有 unittest，但 pytest 以更少的样板代码、更聪明的断言、丰富的插件生态成为社区主流。本文带你从第一个测试用例到 fixtures 实战。 一、环境准备 pip install pytest # 验证 pytest --version 阅读全文