Python 基础语法 - 变量与命名规则一、python 变量的真实模型变量 名字name→ 对象object的“绑定关系”python 中变量本身不存值值永远存储在对象里变量只是标签/引用。a10底层语义等价于创建整数对象 10 将名字 a 绑定到对象 10明白这点有助于理解赋值传参可变 / 不可变拷贝 / 引用globel / nonlocal二、变量的绑定而不是赋值重新绑定Rebindinga10a20不是修改 10是创建对象20a从原来的对象解绑a绑定到新对象a ──▶ 10 ↓ a ──▶ 20这就是为什么id(10)id(10)# True小整数缓存多个变量指向同一个对象a[1,2,3]ba内存模型a ─┐ ├──▶ [1, 2, 3] b ─┘修改对象a.append(4)print(b)# [1, 2, 3, 4]三、变量名命名规则Python 变量名必须满足只能包含字母a-z, A-Z)数字0-9下划线_不能以数字开头区分大小写不能是关键字共35个FalseNoneTrueandasassertasyncawaitbreakclasscontinuedefdelelifelseexceptfinallyforfromglobalifimportinislambdamatchcasenonlocalnotorpassraisereturntrywhilewithyield为什么这样设计这和 **词法分析Lexical Analysis**有关。Python 在解析源码时需要快速区分标识符identifier数字字面量运算符如果允许2name解析器将无法区分这是数字2变量name 这不是“规定”而是编译器设计必然结果四、命名 ≠ 语法问题而是「语义设计」变量名的语义作用x 3.14vspi 3.14Python 不做类型声明变量名本身就是“类型提示 业务语义” 这也是 Python 社区极度强调命名的原因PEP 8 命名规范不是形式主义标识符类型规范示例备注变量、函数、方法、模块、包全小写 下划线user_id,calculate_total(),my_module最通用的规则。常量全大写 下划线MAX_CONNECTIONS,DEFAULT_PORT定义在模块级别值不应改变。类、异常首字母大写单词串HttpClient,CustomError类名应有名词属性。类的方法参数首选self,clsdef method(self, param):self是实例引用cls是类引用。“私有”属性/方法单下划线开头_internal_cache,_helper_method()提示“内部使用”非强制。避免命名冲突单下划线结尾class_,type_避免与关键字冲突。类/模块内部实现双下划线开头__private_var触发名称改写实现弱私有。下划线的“语义约定”重点_var约定为内部使用_internal_cache{} 含义“你可以用”“但别依赖它”__var名称改写Name ManglingclassA:def__init__(self):self.__x10等价于self._A__x 目的不是安全而是避免子类命名冲突_临时变量 / 无意义变量for_inrange(10):print(hello)或a,_,c(1,2,3) 明确表达“我知道这里有值但我不关心”五、变量的「生命周期」与「作用域」变量是否存在取决于名字是否在当前作用域的命名空间中deffunc():x10print(x)# ❌ NameError后面系统展开变量存在于命名空间而不是代码本身。六、变量 vs 对象 vs 类型三者关系a 10分解为层级内容名字a对象10类型inttype(a) is int # True 类型属于对象不属于变量 Python 是动态类型 强类型动态类型动态类型的含义变量的类型在运行时才确定并且可以随时改变。我们无须也无法在代码中提前声明变量将存放何种类型的数据。# 典型动态类型代码x100# 此时 x 引用一个整数xPython# 现在 x 引用一个字符串完全合法x[1,2,3]# 现在 x 引用一个列表# 编译器/解释器在运行前不知道 x 会是什么类型动态类型的优势与代价✅灵活、代码简洁无需类型声明快速原型开发。❌运行时类型错误类型相关的错误只能在代码运行时被发现。❌工具支持难度大IDE 的自动补全、跳转、重构不如静态语言精准。强类型强类型含义对象一旦创建其类型就固定不变。不同类型对象间的操作受到严格限制除非进行显式的类型转换。# 强类型语言的典型表现a10b20# print(a b) # ❌ TypeError: 不能隐式地将 int 加到 strprint(aint(b))# ✅ 30需要**显式**转换 str - intprint(str(a)b)# ✅ 1020需要**显式**转换 int - str对比弱类型// JavaScript (弱类型) - 隐式类型转换很常见leta10;letb20;console.log(ab);// ✅ 1020数字 10 被隐式转换为字符串 10强类型的优势与代价✅行为可预测代码意图明确减少因隐式转换带来的诡异bug。✅更安全意外地将字符串当数字用的错误会被立即抛出。❌稍显繁琐需要多写一些类型转换代码。动态 强类型 Python 的特点结合两者Python 的特点是“可以随时把变量名贴到任何类型的对象上动态但贴上去之后这个对象能做什么由它自己的类型严格决定强类型。”为什么 Python 不需要“声明变量”对比 C / Javaint a 10;Pythona 10原因Python 是动态类型运行时创建对象变量只在运行时绑定不需要编译期类型检查 这直接影响了 Python 的灵活性性能错误发现时机工程化实践原则之 .py 文件命名规范.py文件命名看似随意其实暗含了 Python 的模块机制、导入规则和工具生态假设。一、.py文件名在 Python 中意味着什么一个.py文件 一个模块moduleutils.py → 模块名 utils 文件名直接成为模块名的一部分 影响importfrom ... import ...__name__包结构工具扫描pytest / mypy / coverage二、Python 官方命名规范PEP 8✅ 推荐规则核心模块名应使用全小写字母 下划线snake_casegood: utils.py file_reader.py user_service.py bad: Utils.py FileReader.py userService.py 原因不是“好看”而是跨平台一致性导入语义清晰避免大小写敏感问题Windows vs Linux 不推荐的命名方式1. 含大写字母import Utils # 可行但不推荐问题Linux 区分大小写Windows 不区分Git 合并冲突高发区2. 含连字符-my-utils.py # ❌ import my-utils # 语法错误 因为-在 Python 中是减号3. 以数字开头1_utils.py # ❌ import 1_utils # ❌原因同变量命名规则。4. 使用关键字作为文件名强烈不建议import.py class.py async.py 结果import import # ❌ 语法直接炸即使你用importlib也会造成灾难性的可读性问题。三、.py文件命名与 import 机制模块名 文件名去掉 .pymath_utils.py import math_utils Python 在sys.path中查找内置模块第三方模块当前项目模块文件名不能是内置模块❌典型踩坑random.pyimportrandom random.randint(1,10)# ❌ 崩原因你自己的random.py把标准库random**遮蔽shadow**了 这是 Python 新手和老手都会踩的坑。常见不要用的名字sys.py os.py time.py json.py logging.py asyncio.py四、包 package命名规范一个目录 __init__.py 包my_project/│ ├── data_utils/│ ├── __init__.py │ ├── reader.py │ └── writer.py 包名规则和模块名完全一致小写下划线不用关键字不和标准库重名五、包的初始化在Python 3.3 之前只有包含__init__.py的目录才会被认为是一个包。mypkg/ ├── __init__.py ← 有它mypkg 才是包 ├── a.py └── b.py没有__init__.pymypkg/ ├── a.py └── b.py➡Python 不认为它是包无法import mypkg.a为什么要用__init_.py这个名字因为 Python 的模块机制是模块一个.py文件包一个“特殊的模块”对应一个目录__init__.py就是这个包对应的“模块文件”包 ≈ 目录 __init__.pyimportmypkg# 实际执行的是 mypkg/__init__.py__init__.py的核心语义__init__.py是 “包被导入时最先执行的代码”包导入时发生了什么importmypkg等价于# 1. 找到 mypkg 目录# 2. 执行 mypkg/__init__.py# 3. 创建一个 mypkg 模块对象所以我们可以在__init__.py里初始化包级变量导入子模块控制对外暴露的 API执行一次性初始化逻辑常见用途一聚合子模块最常见mypkg/├── __init__.py ├── user.py └── order.py不用__init__.py聚合from mypkg.user import User from mypkg.order import Order用__init__.py聚合# mypkg/__init__.py from .user import User from .order import Order现在用户可以这样用from mypkg import User, Order对外 API 更干净、更专业常见用途二限制from package import *# mypkg/__init__.py__all__[User]frommypkgimport*只会导入User不会导入内部实现。常见用途三包级初始化# mypkg/__init__.pyprint(mypkg 初始化中)DB_CONNcreate_connection()整个程序中这段代码只执行一次。Python 3.3 没有__init__.py也可以作为包从Python 3.3PEP 420开始没有__init__.py的目录也可以作为包mypkg/ ├── a.py └── b.py我们可以import mypkg.a✅ 成功这类包叫做命名空间包为什么现在还要写__init__.py?因为场景是否需要__init__.py想写初始化代码✅ 必须想定义__all__✅ 必须想聚合子模块✅ 必须想明确“这是一个包”✅ 推荐大型工程 / 团队协作✅ 强烈推荐临时脚本❌ 可省略现实工程中几乎都会加工程视角为什么“专业项目一定有__init__.py?1️⃣ 明确模块边界非常重要__init__.py是一个“设计边界”这是一个对外提供 API 的包 而不是随便 import 的目录2️⃣ 防止隐式 Bug没有__init__.py容易被误判为普通目录IDE、打包工具、老版本 Python 行为不一致相对导入行为更复杂六、文件名的”语义粒度“工程经验1️⃣ 文件名 职责边界好的auth.py # 认证 permissions.py # 权限 token.py # Token 逻辑坏的utils.py # 万能垃圾桶 common.py helper.py 如果一个文件叫utils.py 往往意味着“该拆了”2️⃣ 单数 vs 复数场景推荐行为 / 逻辑单数auth.py集合 / 数据复数models.py Django / FastAPI 都遵循这个约定七、特殊.py文件命名__init__.py标记目录为包控制包的对外 API影响from pkg import *__main__.pypython -m mypackage 入口模块__all__不是文件但与模块导出强相关__all__ [func1, func2]八、工具生态对文件名的隐含要求pytesttest_*.py *_test.pyalembic / django / flask有强约定文件名偏离会导致工具扫描不到 命名 ≠ 个人喜好 命名 与生态工具“对齐”