Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 增强提案

PEP 283 – Python 2.3 版本发布计划

作者:
Guido van Rossum
状态:
最终
类型:
信息性
主题:
发布
创建:
2002年2月27日
Python 版本:
2.3
发布历史:
2002年2月27日

目录

摘要

本文档描述了 Python 2.3 的开发和发布计划。该计划主要关注 PEP 级别的项目。在第一个 Beta 版本发布之前,可能会添加一些小功能。在最终版本发布之前,可能会修复一些 Bug。

将至少发布两个 Alpha 版本、两个 Beta 版本和一个候选版本。Alpha 和 Beta 版本之间至少间隔 4 周(除非必须发布紧急版本来纠正上一个版本中的错误;则错误修复版本不计入间隔时间)。候选版本之间至少间隔一周(同样不包括错误修复版本)。

alpha 1 2002年12月31日
alpha 2 2003年2月19日
beta 1 2003年4月25日
beta 2 2003年6月29日
候选版本 1 2003年7月18日
候选版本 2 2003年7月24日
最终版本 2003年7月29日

发布负责人

Barry Warsaw、Jeremy Hylton、Tim Peters

2.3 版本已完成的功能

此列表不完整。有关更多信息,请参见 CVS 中的 Doc/whatsnew/whatsnew23.tex,当然也可以查看 Misc/NEWS 以获取完整列表。

  • Tk 8.4 更新。
  • bool 类型及其常量 TrueFalse (PEP 285)。
  • PyMalloc 进行了大幅增强,并默认启用。
  • 通用换行符支持 (PEP 278)。
  • PEP 263 定义 Python 源代码编码,Lemburg

    已实现(至少实现了第一阶段,这也是 2.3 版本计划中的全部内容)。

  • 所有内置序列都扩展了切片表示法。Michael Hudson 的补丁现已全部签入。
  • 通过填充 tp_iter 和其他调整来加快列表迭代速度。参见 https://bugs.python.org/issue560736;对于 xrange 和元组也进行了同样的操作。
  • 套接字超时。 https://bugs.python.org/issue555085
  • int/long 集成的 B0 阶段 (PEP 237)。这意味着在 hexoct 转换或左移操作返回 int 的值与具有相同值的 long 的值不同的情况下,会发出 FutureWarning 警告。Python 2.3 中的语义 *不会* 发生变化;这将在 Python 2.4 中发生。
  • 从所有代码对象中删除 SET_LINENO(提供了一种不同的设置调试器断点的方法)。这可以使 pystone 的速度提高 >5%。https://bugs.python.org/issue587993,现已签入。(不幸的是,pystone 的速度并没有提高。发生了什么?)
  • 编写一个 pymemcompat.h,人们可以将其与他们的扩展捆绑在一起,然后使用 2.3 内存接口与 1.5.2 到 2.3 范围内的所有 Python 版本兼容。(Michael Hudson 签入了 Misc/pymemcompat.h。)
  • 添加了一个新的概念,“即将弃用”,以及相关的警告 PendingDeprecationWarning。此警告通常会被抑制,但可以通过适当的 -W 选项启用。目前只有少数东西使用了它。
  • 当扩展类型的 tp_compare 返回除 -1、0 或 1 之外的任何值时发出警告。https://bugs.python.org/issue472523
  • None 进行赋值(以各种形式)时发出警告。
  • PEP 218 添加内置集合对象类型,Wilson

    Alex Martelli 贡献了 Greg Wilson 原型的最新版本,我对其进行了相当大的修改。它现在作为 sets 模块包含在标准库中,但一些细节在第一个 Beta 版本发布之前可能还会发生变化。(目前没有计划将其设为内置类型。)

  • PEP 293 编解码错误处理回调,Dörwald

    已完全实现。现在可以自定义 unicode.encodestr.decode 中的错误处理。

  • PEP 282 日志系统,Mick

    Vinay Sajip 的实现已被打包并导入。(文档和单元测试仍在进行中。)https://bugs.python.org/issue578494

  • 修改后的 MRO(方法解析顺序)算法。共识是我们应该采用 C3。Samuele Pedroni 已贡献了一个 C 语言的草案实现,请参见 https://bugs.python.org/issue619475 此实现现已签入。
  • 新的命令行选项解析器。Greg Ward 的 Optik 包 (http://optik.sf.net) 已被采用,并转换为名为 optparse 的单个模块。另请参见 https://pythonlang.cn/sigs/getopt-sig/
  • 标准的 datetime 类型。这最初是一个 Wiki:http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage。一个原型在 nondist/sandbox/datetime/ 中用代码实现。Tim Peters 已完成 C 语言的实现并将其签入。
  • PEP 273 从 Zip 档案导入模块,Ahlstrom

    作为 PEP 302 实现工作的一部分实现。

  • PEP 302 新的导入钩子,JvR

    已实现(尽管 2.3a1 版本包含一些在发布后已修复的 Bug)。

  • 新的 pickle 协议。请参见 PEP 307
  • PEP 305(CSV 文件 API,由 Skip Montanaro 等人撰写)已包含在内;这是 csv 模块。
  • Raymond Hettinger 的 itertools 模块已包含在内。
  • PEP 311(简化扩展的 GIL 获取,由 Mark Hammond 撰写)已包含在 Beta 1 版本中。
  • 两个新的 PyArg_Parse*() 格式代码,“k” 返回一个无符号的 C 长整数,该整数接收 Python 参数的低 LONG_BIT 位,并在不进行范围检查的情况下进行截断。“K” 返回一个无符号的 C 长长整数,该整数接收低 LONG_LONG_BIT 位,并在不进行范围检查的情况下进行截断。(SF 595026;Thomas Heller 完成了这项工作。)
  • 从 IDLEfork 项目 (http://idlefork.sf.net) 导入了一个新版本的 IDLE。该代码现在位于标准库中的 idlelib 包中,并且 idle 脚本由 setup.py 安装。

2.3 版本计划中的功能

为时已晚,无法在此处完成更多工作。

正在进行的任务

以下是我们应该尝试进行的持续待办事项,但不要指望在任何特定日期前完成。

  • 文档:完成发行版和安装手册。
  • 文档:完成新式类的文档。
  • 查看 Demos/ 目录并在需要时更新(Andrew Kuchling 已经完成了其中很大一部分)
  • 新的测试。
  • 修复 SF 上的文档 Bug。
  • 删除核心代码中对已弃用功能的使用。
  • 适当地记录已弃用的功能。
  • 使用 Py_DEPRECATED 标记已弃用的 C API。
  • 弃用未维护的模块,或者可能为模块创建一个新的类别“未维护”
  • 总的来说,进行大量清理,以便更容易地向前推进。

未解决的问题

在最终版本发布之前(最好在第一个 Beta 版本发布之前),可能有一些问题需要更多工作和/或思考:没有剩余问题。

未进入 Python 2.3 的功能

  • 导入锁可能需要重新设计。(SF 683658。)
  • 集合 API 问题;sets 模块是否完美?

    我认为它已经足够好了,可以停止对其进行打磨,直到我们获得更广泛的用户体验。

  • 一个更友好的打开文本文件的 API,替换了(在某些人看来)难看的“U”模式标志。有一个提议是引入一个新的内置类型 textfile(filename, mode, encoding)。(它是否也应该有一个 *bufsize* 参数?)

    同上。

  • Tkinter 的新部件???

    有人为此腾出时间了吗?Tk 8.4 中 *有* 任何新部件吗?请注意,我们已经获得了更好的 Tix 支持(尽管在 Windows 上还没有)。

  • Fredrik Lundh 的 basetime 提议

    http://effbot.org/ideas/time-type.htm

    我相信这现在已经终止了。

  • PEP 304(由 Montanaro 控制字节码文件的生成)似乎已经失去了动力。
  • 对于在一个类内部定义的另一个类,__name__ 应该为 "outer.inner",并且 pickling 应该可以工作。(SF 633930。我不确定这是否容易或正确。)

  • reST 将在 Zope3 中被大量使用。也许它可以成为标准库模块?(由于 reST 的作者认为它还不稳定,我倾向于不这样做。)
  • 确定更清晰的弃用策略(尤其是针对模块),并付诸实施。首先,请参阅 Neal Norwitz 的这封邮件:https://mail.python.org/pipermail/python-dev/2002-April/023165.html 似乎大家对以有组织的方式推进此事兴趣不足,而且它也不是特别重要。
  • types 模块的常用用法提供替代方案;

    Skip Montanaro 发布了一个关于此想法的 PEP 草案:https://mail.python.org/pipermail/python-dev/2002-May/024346.html

    据我所知,这方面没有任何进展。

  • typesstring 模块使用即将弃用的状态。这需要为尚未覆盖的部分提供替代方案(例如 string.whitespacetypes.TracebackType)。看起来我们无法就此事达成共识。
  • 弃用 buffer 对象。

    看来这个问题永远无法解决。

  • PEP 269 Python 的 Pgen 模块,Riehl

    (一些必要的更改已完成;pgen 模块本身需要进一步成熟。)

  • 添加对期待已久的 Python 目录的支持。Kapil Thangavelu 有一个基于 Zope 的实现,他在 OSCON 2002 上进行了演示。现在我们只需要一个托管它的位置和一个支持它的人。(至少 distutils 中已经有一些支持它的更改。)
  • PEP 266 优化全局变量/属性访问,Montanaro

    PEP 267 优化访问模块命名空间,Hylton

    PEP 280 优化访问全局变量,van Rossum

    这些基本上是三个友好的竞争性提案。Jeremy 在新的编译器方面取得了一些进展,但进展缓慢,而且编译器只是第一步。也许我们能够在这个版本中重构编译器。我倾向于说我们不会屏住呼吸。与此同时,Oren Tirosh 有一个更简单的想法,可以通过优化和内联字典访问来大幅提升访问全局变量和内置函数的性能:http://tothink.com/python/fastnames/

  • 延迟跟踪元组?

    我相信没有多少热情。

  • PEP 286 增强的参数元组,von Loewis

    我还没有时间仔细审查它。它似乎是一个深度的优化技巧(尽管也提供了更好的正确性保证)。

  • 将“as”设为关键字。它已经足够长时间充当伪关键字了。太麻烦了,不值得费力。

来源:https://github.com/python/peps/blob/main/peps/pep-0283.rst

上次修改:2023-09-09 17:39:29 GMT