CPython 3.10.0a6 版本变更深度解读:从 NEWS 条目到源码实现的完整技术全览
CPython 3.10.0a6 是 3.10 系列发布周期中的第六个 alpha 里程碑版本,其变更记录完整保留在本仓库的 Misc/NEWS.d/3.10.0a6.rst 中,涵盖安全修复、核心语言运行时、标准库、构建系统与 C API 等数十项改进。本文以该 NEWS 文件为骨架,逐条解读其技术要点,并结合当前仓库中的 Lib/urllib/parse.py、Include/setobject.h、Objects/stringlib/fastsearch.h、Grammar/python.gram 等源码实现,讲清每项变更"改了什么、为什么改、影响谁",让读者既了解版本发布内容,也能追溯到底层实现。
说明:当前仓库主线已演进至更早的 Include/patchlevel.h 所标注的 3.16.0a0 开发版本,本文件是随源码树保留的历史发布记录。其大部分底层实现(如
parse_qsl的separator参数、Two-Way 字符串搜索、结构化模式匹配语法)仍活跃于现有代码中,因此下方源码佐证均可实地复验。
一、这份 NEWS 文件是什么:版本变更记录的来源与字段约定
在 CPython 仓库中,Misc/NEWS.d/ 目录存放着以 blurb 工具管理的零散新闻条目,每个 .rst 文件对应一个独立变更,最终会被汇入 Misc/NEWS 及对应版本的 What's New 文档。Misc/NEWS.d/3.10.0a6.rst 记录了计划于 2021-03-01(文件头部 release date 元数据)发布的 3.10.0a6 里程碑的全部条目。
每个条目由一组 RST 注释元数据与正文构成,字段含义如下:
| 元数据字段 | 含义 | 本文件示例值 |
|---|---|---|
.. bpo: |
关联的 Python bug tracker 编号 | bpo: 42967、bpo: 43321 |
.. date: |
条目提交/登记时间戳 | 2021-02-14-15-59-16 |
.. nonce: |
条目唯一标识(防止合并冲突) | YApqDS |
.. release date: |
所属版本计划发布日期 | 2021-03-01 |
.. section: |
变更归属分类 | Security、Core and Builtins、Library、Build、C API 等 |
本文件按 section 至少覆盖 Security、Core and Builtins、Library、Documentation、Tests、Build、Windows、macOS、IDLE、C API 十大类,合计约 47 个 bpo 条目。下文按这些分区组织,并尽量为每条补充源码级佐证。
二、Security:修复 URL 查询串解析导致的 Web 缓存投毒漏洞
bpo-42967(Security) 是 3.10.0a6 中最重要的一项安全修复:将查询参数分隔符默认固定为 &,同时允许用户自定义分隔符,从而消除 web cache poisoning(Web 缓存投毒)风险。
漏洞背景
urllib.parse.parse_qs() 与 parse_qsl() 在历史上使用"& 或 ;"双分隔符解析查询串。若一个 URL 形如 ?lang=en;foo=bar,不同解析器(如某些缓存代理按 & 切分、Python 却同时按 & 与 ; 切分)会得到不同的键值集合,缓存键与后端解析结果不一致,攻击者即可构造请求污染共享缓存中的响应。修复方式简单直接:默认只把 & 当作分隔符。
源码现状:separator 参数
在当前仓库 Lib/urllib/parse.py 中,parse_qs() 与 parse_qsl() 均已新增 separator='&' 关键字参数:
def parse_qs(qs, keep_blank_values=False, strict_parsing=False,
encoding='utf-8', errors='replace', max_num_fields=None, separator='&'):
"""..."""
parsed_result = {}
pairs = parse_qsl(qs, keep_blank_values, strict_parsing,
encoding=encoding, errors=errors,
max_num_fields=max_num_fields, separator=separator,
_stacklevel=2)
...
return parsed_result
参数 separator 的语义如下(见 Lib/urllib/parse.py 中 parse_qsl 的 docstring 与实现):
- 类型必须是
str或bytes,且非空,否则抛出ValueError("Separator must be of type string or bytes."); - 当输入
qs是str时,bytes型分隔符会被先转为 ASCII 字符串(Lib/urllib/parse.py),反之亦然(Lib/urllib/parse.py); - 内部先通过
qs.count(separator)预判字段数量(配合max_num_fields防内存耗尽),再用qs.split(separator)完成切分(Lib/urllib/parse.py)。
迁移与兼容
若旧代码依赖 ; 分隔符,需要显式传入 separator=';' 或 separator='&;'(任意自定义字符串均可)来恢复部分行为:
# 新默认:仅 '&'
urllib.parse.parse_qs('a=1&b=2;c=3') # {'a': ['1'], 'b': ['2;c=3']}
# 自定义分隔符:同时支持 & 与 ;
urllib.parse.parse_qs('a=1&b=2;c=3', separator='&;')
# 注意 split('&;') 需要字面连续出现 '&;',这里并不匹配,实际结果为键 'a'/'b=2;c=3'
实际迁移时,对必须兼容 ; 的历史数据的服务端代码,建议在解析前显式做一次分隔符替换或归一化,再交给默认配置的 parse_qsl()。
三、Core and Builtins:核心运行时与 C API 的修复与提速
3.1 C 参数解析错误修复:# 格式单元与 PY_SSIZE_T_CLEAN
bpo-43321 修复了在 未定义 PY_SSIZE_T_CLEAN 的情况下,PyArg_Parse*() 使用 # 格式单元(读取 Py_ssize_t 长度)可能触发的 SystemError。在 CPython 中,s#、y#、z# 等格式需要长度目标类型为 Py_ssize_t*,而经典参数解析在未显式定义 PY_SSIZE_T_CLEAN 时会按 int* 布局处理,两者不一致。本修复使该场景得到正确诊断处理。扩展作者应在源文件中、任何 Python.h 包含之前定义:
#define PY_SSIZE_T_CLEAN
#include <Python.h>
3.2 u / Z 格式单元弃用告警(PEP 623)
bpo-36346 使 PyArg_Parse*() 在传入 u(Py_UNICODE* 即 wchar 指针)或 Z(可为 NULL 的同型变体)格式时发出 DeprecationWarning。这呼应 PEP 623(移除 wchar_t 专用 API)的路线:新代码应改用 es、es#(配合 UTF-8 编码)或直接使用 PyObject* + unicode 对象 API。
3.3 新增 C API:PySet_CheckExact
bpo-43277 由 Pablo Galindo 贡献,在 C-API 中新增 PySet_CheckExact(op),用于精确判断对象是否为内建 set 的实例且非其子类实例。当前实现位于 Include/setobject.h:
#define PySet_CheckExact(op) Py_IS_TYPE(op, &PySet_Type)
对比已有的 PyAnySet_Check(接受 frozenset 与子类)与 PySet_Check(不接受子类、不区分两种 set),新宏提供"恰好是 set 类型本身"的强约束判断,可避免子类重写方法对类型判定造成的影响。
3.4 函数与内建符号查找机制调整:__builtins__
两条 bpo-42990(Victor Stinner、Mark Shannon 等)共同改变函数执行时的内建符号解析方式:
types.FunctionType构造函数行为:当传入的globals字典没有"__builtins__"键时,新函数会像eval/exec一样继承当前线程/解释器的内建命名空间,而不再是此前{"None": None}的退化默认。Python 层def语法不受影响(其globals不可覆盖,同样继承当前内建)。- 新增函数对象属性
__builtins__:函数执行时改从自身的__builtins__属性查找内建符号,不再查询__globals__['__builtins__']。函数对象的只读成员表中已存在该字段(见 Objects/funcobject.c 的{"__builtins__", _Py_T_OBJECT, OFF(func_builtins), Py_READONLY})。
这一改动的意义在于:通过 types.FunctionType 手工构造的函数(如某些动态代码生成框架)不再因缺少 __builtins__ 而调用不到 len、range 等内建函数;而新增的只读 __builtins__ 属性也为内省工具(如调试器)提供了统一、可靠的入口。
3.5 语法诊断信息改进
两条 parser 改进均出自 Pablo Galindo:
- bpo-43149:为"不带括号的异常组(exception group)"给出更友好的错误信息,引导用户在
try ... except*/raise ... from场景补全括号; - bpo-43121:修正字面量中缺少逗号时的
SyntaxError提示文案。
这些"无效语法"诊断规则在 PEG 语法文件中以 invalid_* 规则形式存在(如 Grammar/python.gram 的 invalid_match_stmt、invalid_case_block 等),由 Parser/pegen_errors.c 统一产出针对性提示,是 3.9+ PEG 解析器"更好报错"能力的延续。
3.6 type(object) 调用加速(vectorcall)
bpo-42808(Dennis Sweeney)指出:简单的 type(object) 调用受益于 vectorcall 调用约定而提速。vectorcall 允许以 C 数组而非 tuple 传参,省去构造与解构参数元组的开销。该机制在 Objects/typeobject.c 的 type_call 等内部入口落地后,type(x) 这类高频内建调用在 hot loop 中获得可测的常数级提升。
3.7 编译期去重:合并 co_code 与 co_linetable
bpo-42217 让编译器在同一模块内对 字节码 co_code 与行号表 co_linetable 做对象去重合并——此前模块级 co_consts 已有该优化。当模块内多个函数因常量折叠等原因拥有完全相同的字节码时,各 code 对象可共享同一份只读 co_code/co_linetable 底层存储,减少运行期内存占用,也利于缓存命中。
3.8 长字符串子串搜索:Two-Way 算法防退化
bpo-41972 是纯算法层改进:str1 in str2、str2.find(str1) 等子串查找在满足条件时改用 Crochemore 与 Perrin 的 Two-Way 字符串匹配算法,避免朴素算法在"长模式串 + 大量重复前缀"输入上的 O(n·m) 二次方退化。
在源码中,这一策略位于 Objects/stringlib/fastsearch.h,注释明确写道:"If the strings are long enough, use Crochemore and Perrin's Two-Way…",配套说明见 Objects/stringlib/stringlib_find_two_way_notes.txt。算法并非无条件启用:Two-Way 有 O(m) 的预处理开销,源码 Objects/stringlib/fastsearch.h 中说明只在候选场景下启用——即"当模式足够长、值得付出预处理成本"时,见同一 notes 文件对 needle 长度阈值的讨论。
3.9 结构性模式匹配落地(PEP 634)
bpo-42128(Brandt Bucher)标志 3.10 最重要的语言特性——PEP 634 结构化模式匹配(match/case)正式实现。PEG 语法树中相关产生式位于 Grammar/python.gram:
match_stmt[stmt_ty]:
| "match" subject=subject_expr ':' NEWLINE INDENT cases[asdl_match_case_seq*]=case_block+ DEDENT
case_block[match_case_ty]:
| invalid_case_block
这一语法基础设施使 3.10 用户可以编写:
def describe(point):
match point:
case (0, 0):
return "原点"
case (x, 0):
return f"x 轴上,x={x}"
case (x, y) if x == y:
return f"对角线上的点 ({x},{y})"
case _:
return "其他点"
match 支持字面量、捕获、序列、映射、类、通配、守卫等多种模式,相关内部类型定义在 Parser/Python.asdl(match_case、pattern 族)中。
3.10 object.__ipow__ 的 NotImplemented 正确回退
bpo-38302 修复就地幂运算的运算符分派缺陷:当 object.__ipow__ 返回 NotImplemented 时,**= / pow(x, y, ...) 语义应如其他就地运算符一样正确回退到 __pow__ 与 __rpow__。此前该回退链路缺失,会导致自定义 __ipow__ 返回 NotImplemented 的对象在就地幂运算时报出令人困惑的错误,而不是继续尝试右操作数侧协议。
四、Library:标准库行为修复与平台能力增强
4.1 readline:显式禁用 bracketed paste
bpo-42819(Dustin Rodrigues)解决 Python REPL 与 bracketed paste(括号粘贴) 模式的冲突。即使 inputrc 中已开启、GNU Readline 8.1 默认启用、或用户调用 readline.read_init_file() 显式加载了含该设置的配置,CPython 交互式解释器也会强制关闭它。
原因有二:一是 Python REPL 尚未实现 bracketed paste 支持;二是该模式会向 stdout 写入 "\x1b[?2004h" 转义序列,干扰不支持它的终端工具与测试输出。当前源码 Modules/readline.c 保留了修复注释与工具函数:
disable_bracketed_paste(void)
{
...
rl_variable_bind ("enable-bracketed-paste", "off");
}
需要时仍可在应用层显式开启:
import readline
readline.parse_and_bind("set enable-bracketed-paste on")
4.2 gzip 命令行工具
两条 gzip 修复(均为 bpo-43316/bpo-43317 同类维护):
- bpo-43316:
python -m gzip在检测到不支持的文件扩展名时,会以非零退出码失败并输出错误信息到 stderr,而不是静默处理; - bpo-43317:将主函数压缩/解压的分块大小从固定 1024 字节提升为
io.DEFAULT_BUFFER_SIZE。现代缓冲 IO 以io.DEFAULT_BUFFER_SIZE(通常为 8 KiB)为读写粒度更高效,块数减少即系统调用与循环开销减少。gzip模块中大量 IO 分块均已对齐该常量(见 Lib/gzip.py 中相关io.DEFAULT_BUFFER_SIZE的使用)。
4.3 traceback:单参数形式接受 None
bpo-43146(两条,其一为回归修复):traceback.print_exception(exc, ...) 与 traceback.format_exception(exc, ...) 的单参数便捷形式现在可以正确处理 exc=None。由于 3.10 将异常构造迁移为"单个异常对象 + 可选 value/tb"的签名(见 Lib/traceback.py 的 def print_exception(exc, /, value=_sentinel, tb=_sentinel, ...)),调用方常以 None 占位多余参数;本修复确保此时按旧语义使用实际异常回溯,不再抛错。
4.4 TextIOWrapper 大文本写入死循环
bpo-43260 修复:当写入极其大量的文本后,TextIOWrapper 内部缓冲可能"永远无法 flush 完"(表现为写操作卡死)。根因与文本编码后字节长度与内部缓冲区的循环搬移逻辑相关,修复位于 Modules/_io 下的 textio 实现,确保大块写入时缓冲推进条件必然收敛。
4.5 sqlite3 模块三连修(Erlend E. Aasland)
- bpo-43258:聚合查询无匹配行时,不再为聚合函数上下文做无谓分配;
- bpo-43251:
sqlite3_column_name()失败现在正确抛出MemoryError,而不是返回错误数据或静默失败; - bpo-40956:
sqlite3.Connection.backup()在不传参数调用时的段错误修复(回归自 PR 23838),现在能按默认目标数据库执行。
对应实现位于 Modules/_sqlite 目录下。
4.6 codeop:多行未闭合括号继续等待输入
bpo-43163(Pablo Galindo)修复 codeop(REPL 交互编译后端)对多行片段的判断:当代码中出现未闭合括号而用户提交空行后,解释器应继续提示更多输入而不是误判语句完整。交互体验表现为 REPL 中多行表达式(如跨行调用)不再被提前当作完整语句执行。
4.7 enum:弃用跨成员属性访问
bpo-43162 弃用了一种从未被支持却可用的能力——把枚举成员作为另一枚举成员的属性来访问(例如 Color.RED.GREEN)。这类访问会引发歧义与误用,新版将发出 DeprecationWarning 提醒迁移。枚举实现位于 Lib/enum.py。
4.8 namedtuple 的 __builtins__ 修复
bpo-43102 修复 namedtuple 生成类时 __new__ 方法对象的 __builtins__ 被错误设为 None 的问题。此前这会破坏内省工具对 __new__ 的检查(如分析默认参数、构建调用图)。修复后该属性恢复为真正的内建字典,与本文件 3.4 节函数 __builtins__ 机制相衔接。
4.9 os 模块:macOS 新增四个打开标志
bpo-43106(Donghee Na)为 macOS 补充四个 open() 标志常量,与系统 API 对齐(在支持它们的平台通过条件编译暴露,见 Modules/posixmodule.c 中以 #ifdef 包裹的 PyModule_AddIntMacro 导出):
| 常量 | 语义 |
|---|---|
os.O_EVTONLY |
仅请求事件通知(kqueue/FSEvents 场景常用) |
os.O_FSYNC |
等价于 O_SYNC 的强同步写入 |
os.O_SYMLINK |
以符号链接本身而非目标打开 |
os.O_NOFOLLOW_ANY |
拒绝解析路径中任何符号链接组件 |
4.10 resource:新增 FreeBSD 的 RLIMIT_KQUEUES
bpo-42960 将 FreeBSD 的 resource.RLIMIT_KQUEUES(限制进程可打开的 kqueue 描述符数量)加入 resource 模块,便于跨平台限流监控脚本在同一 API 下读取该资源上限。
4.11 xml.etree:纯 Python 实现对齐 C 实现
bpo-42151 修正 xml.etree.ElementTree 纯 Python 实现对默认属性处理的差异:与 C 版 _elementtree 保持一致,不再设置 specified_attributes=1 类标志,保证两套实现对外行为一致。
4.12 ctypes:压缩位域布局修正
bpo-29753 修正 ctypes 结构体**压缩位域(packed bitfields)**的计算:压缩布局下首个位域成员的收缩与后续成员的偏移计算现在正确,避免在不同 ABI 下读写错位。
4.13 进程池与平台探测
bpo-40692 令 concurrent.futures.ProcessPoolExecutor 在初始化前校验当前平台是否提供 multiprocessing.synchronize(该模块部分平台受限),并在 concurrent.futures 测试套件中依据该检查跳过与 ProcessPoolExecutor 无关的用例——让缺少该能力的平台仍能运行其余并发测试。相关代码位于 Lib/concurrent/futures/process.py。
五、Documentation 与 Tests:文档澄清与测试健壮性
- bpo-27646:文档澄清
yield from <expr>的右操作数可以是任意可迭代对象,而不只是迭代器(如列表、集合也合法)。 - bpo-36346:配合 PEP 623,将一批已弃用 Unicode C API 的文档化移除时间从"will be removed in 4.0"统一更新为 "3.12",让扩展作者明确迁移窗口。
- bpo-43288:修复
test_importlib,当文件系统不支持某些 Unicode 文件名时正确跳过对应用例,避免误报失败。
六、Build 与平台支持:构建系统演进
6.1 Windows:编译器 /utf-8 选项
bpo-43174:Windows 构建全面启用 /utf-8 编译器选项,将源码与外部字面量统一按 UTF-8 解释,消除因系统区域设置(如 GBK 代码页)导致的源文件编码错判,这也是 CPython 源码全库 UTF-8 化的配套措施。
6.2 configure:--without-static-libpython
bpo-43103 新增 configure 选项 --without-static-libpython:不再构建静态库 libpythonMAJOR.MINOR.a,也不安装 python.o 目标文件。适合纯共享库部署(如仅需 libpython3.x.so 的发行版打包),可显著缩短构建时间、减小安装体积。
6.3 支持 libedit 作为 readline 实现
bpo-13501:configure 新增 --with-readline=editline,允许在 macOS 等系统上使用 libedit(BSD 许可的 readline 兼容库)替代 GNU Readline 构建 readline 模块。bpo-43172 同步保证 readline 测试在直连 libedit 编译时也能通过,不过 readline.get_begidx() / get_endidx() 在 libreadline 与 libedit 之间的已知行为差异依然保留。
6.4 Tcl/Tk 检测改用 pkg-config
bpo-42603:configure 改为借助 pkg-config 探测构建 tkinter 所需的 Tcl/Tk 头文件与库位置。在 macOS 上,若 pkg-config 提供了 Tcl/Tk 配置,则优先于 /Library/Frameworks、/System/Library/Frameworks 中的框架;若两套并存且用户希望使用框架版本,须显式设置 --with-tcltk-* 系列选项。
6.5 makefile:regen-frozen 目标
bpo-39448 新增 make regen-frozen,用于重新生成冻结模块(frozen modules,如 __hello__)的 C 代码,是"改语法/改字节码后必须重新生成派生文件"工作流的一环。相关生成逻辑见 Programs/_freeze_module.c 与 Makefile.pre.in。
6.6 macOS:安装器内置 OpenSSL 升级
bpo-41837 将 macOS 安装器构建所用的 OpenSSL 升级到 1.1.1j,携带安全补丁的版本随官方 .pkg 一起分发。
七、C API 与内部接口清理
3.10.0a6 的 C API 改动呈现清晰的**"宏转函数、头文件归位、私有接口移除"**主线(多条由 Erlend E. Aasland 完成,bpo-40170):
7.1 宏转函数,隐藏实现细节
为隐藏对类型对象字段的直接访问、保证 ABI 稳定,以下宏改为普通函数(或 static inline):
| 条目 | API | 变更方式 | 此前直接访问的内部字段 |
|---|---|---|---|
| bpo-40170 | PyExceptionClass_Name |
宏 → 函数 | PyTypeObject.tp_name |
| bpo-40170 | PyIter_Check |
宏 → 函数 | PyTypeObject.tp_iternext |
| bpo-40170 | PyDescr_IsData |
宏 → 函数 | PyTypeObject.tp_descr_set |
| bpo-43181 | PyObject_TypeCheck |
宏 → static inline 函数 |
ob_type 比较逻辑 |
PyObject_TypeCheck 当前实现可参见 Include/object.h:
static inline int PyObject_TypeCheck(PyObject *ob, PyTypeObject *type) { ... }
7.2 头文件归位到 cpython/
两条 bpo-35134 将若干内部头文件迁入 Include/cpython/ 子目录:先是 odictobject.h、parser_interface.h、picklebufobject.h、pydebug.h、pyfpe.h,后是 pyarena.h、pyctype.h、pytime.h。这些头文件不应被直接 include——它们已由 Python.h 统一引入(参见 API 文档的 Include Files 章节)。迁移释放了顶层 Include/ 的命名空间,同时收紧公共接口边界。
7.3 移除私有宏,导出必要符号
- bpo-43270:删除私有
_PyErr_OCCURRED()宏,统一改用公开的PyErr_Occurred()函数; - bpo-43239:
PyCFunction_New在启用-fvisibility=hidden编译时现在仍会按 ABI 需求导出,避免隐蔽的链接缺失; - bpo-43155:Windows 导入库
python3.lib补上PyCMethod_New符号,使扩展在 Windows 下可以正常链接到该 API。
7.4 REPL 欢迎消息首行
bpo-43278:REPL 欢迎信息的第一行现在始终包含编译期编译器与系统信息(如 Python 3.10.0a6 (default, ...) [GCC ...] on linux),方便在自动化/CI 输出中一眼定位构建环境。
八、IDLE:Shell 打印性能的官方解释
bpo-43283 在文档层面解释了一个常见疑惑:向 IDLE 的 Shell 打印常常比系统终端慢。原因是每条输出都要经过 IDLE 与子进程间的 RPC 通信并逐块刷新;文档建议通过先格式化一个完整字符串再一次性打印来摊薄通信开销,而非循环中多次 print()。该说明已写入 IDLE 相关文档,对用 IDLE 跑日志密集脚本的开发者有直接指导价值。
九、小结:本文件的技术脉络
回看整份 Misc/NEWS.d/3.10.0a6.rst,可以用三条主线概括 3.10.0a6 的工程取向:
- 安全与健壮性优先:URL 查询串解析默认收紧为
&(bpo-42967),补齐sqlite3、TextIOWrapper、traceback等模块的边界错误处理; - 语言与运行时继续兑现 PEP:结构化模式匹配(PEP 634)、wchar API 弃用路线(PEP 623)、函数
__builtins__机制、vectorcall 提速、Two-Way 子串算法陆续落地; - C API 边界收缩与构建现代化:内部头文件迁入
Include/cpython/、私有宏删除、宏转函数、/utf-8、pkg-config 化,均服务于"更清晰的公共 ABI + 更可维护的构建"。
如需逐条核对历史,可结合 Misc/NEWS 汇总文件与 Doc/whatsnew 目录下的版本说明交叉阅读;想追踪某项机制的现行实现,则按上文各小节给出的源码路径(如 Lib/urllib/parse.py、Objects/stringlib/fastsearch.h、Grammar/python.gram、Include/setobject.h)深入即可。
atomcodeClaude Code 的开源替代方案。连接任意大模型,编辑代码,运行命令,自动验证 — 全自动执行。用 Rust 构建,极致性能。 | An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get StartedRust0629
MiniCPM5-2BMiniCPM5-2B 是一款面向端侧、本地部署和资源受限场景的 2B 稠密 Transformer,能够达到同尺寸开源模型 SOTA 水平。Markdown00
GLM-5.3GLM-5.3 与 GLM-5.2 使用相同的基座模型——所有提升均来自后训练。与 GLM-5.2 相比,它在复杂编程和长程任务上的表现显著提升。Jinja00
HivisionIDPhotos⚡️HivisionIDPhotos: a lightweight and efficient AI ID photos tools. 一个轻量级的AI证件照制作算法。Python07
DragonOSDragonOS is an operating system developed from scratch using Rust, with Linux compatibility. It is designed for **Serverless** scenarios. 使用Rust从0自研内核,具有Linux兼容性的操作系统,面向云计算Serverless场景而设计。Rust00
Spark-X2.5-1.7BSpark-X2.5-1.7B 旨在让强大的 AI 更加实用、高效且易于获取。这些模型在广泛的日常任务中表现出色,涵盖对话、写作、翻译、推理、编程、工具调用和智能体工作流,并在同等规模的开源模型中取得领先结果。Spark-X2.5 将面向效率的架构与最高 1M tokens 的原生上下文窗口相结合,并支持 200 多种语言。Python00