PEP 42 – 功能请求
- 作者:
- Jeremy Hylton <jeremy at alum.mit.edu>
- 状态:
- 已撤回
- 类型:
- 流程
- 创建日期:
- 2000年9月12日
- 发布历史:
引言
本 PEP 包含一份功能请求列表，这些请求可能会在 Python 的未来版本中考虑。大型功能请求不应包含在此处，而应在单独的 PEP 中描述；但是，没有自己的 PEP 的大型功能请求可以在此处列出，直到创建其自己的 PEP。有关详细信息，请参阅 PEP 0。
创建此 PEP 是为了允许我们关闭实际上是功能请求的错误报告。标记为“开放”时，它们会分散对真正错误的列表的注意力（理想情况下应少于一页）。标记为“已关闭”时，它们往往会被遗忘。现在的程序是：如果一个错误报告实际上是一个功能请求，则将该功能请求添加到此 PEP 中；将该错误标记为“功能请求”、“稍后”和“已关闭”；并向该错误添加一条评论，说明这是这种情况（明确提及 PEP）。将大型功能请求直接从错误数据库转移到单独的 PEP 也是可以接受的。
本 PEP 实际上应该分为四个不同的类别（类别由 Laura Creighton 提出）
- BDFL 认为这是个坏主意，并拒绝了。不要再提了。
- 如果有人编写代码，BDFL 将会实现它。（或者至少，如果你带着代码出现，BDFL 会说“改一下，我就把它放进去”。）
可能分为
- BDFL 非常想看到一些代码！
- BDFL 对此永远不会热情，但当它容易实现时会把它放进去。
- 如果你带着代码出现，BDFL 会发表声明。它可能是“令人讨厌的”。
- 这太模糊了。这被拒绝了，但仅因为模糊。如果你喜欢这个增强功能，请创建一个新的 PEP。
核心语言 / 内置
- 解析器应该处理更深层嵌套的解析树。
以下代码将会失败——
eval("["*50+"]"*50)——因为解析器对栈大小有一个硬编码的限制。这个限制应该提高或移除。移除会很困难，因为如果嵌套太深，当前的编译器可能会导致 C 栈溢出。 - 非意外的 IEEE-754 支持（无穷大、NaN、可设置的陷阱等）。大项目。
- Windows：尝试创建（甚至访问）某些特殊名称的文件可能会导致 Windows 系统挂起或崩溃。这实际上是操作系统中的一个错误，但有些应用程序试图保护用户免受其害。当它发生时，症状非常令人困惑。
使用名为 prn.txt 等文件时挂起 https://bugs.python.org/issue481171
- eval 和自由变量：如果有一种方法可以在传递带有自由变量的代码对象时，将自由变量的绑定传递给 eval，这可能很有用。https://bugs.python.org/issue443866
标准库
- urllib 模块应该支持需要身份验证的代理。有关信息，请参阅 SourceForge 错误 #210619
- os.rename() 应该修改为处理在不允许跨文件系统边界重命名操作的平台上出现的 EXDEV 错误，通过复制文件并删除原始文件。Linux 是一个需要这种处理的系统。
- 信号处理并不总是按预期工作。例如，如果
sys.stdin.readline()被一个（返回的）信号处理器中断，它会返回 “”。更好的做法是让它引发异常（对应于 EINTR）或重新启动。但这些更改必须应用于所有可能执行阻塞可中断 I/O 的地方。因此这是一个大项目。 - 扩展 Windows utime 以接受目录路径。
- 扩展 copy.py 以支持模块和函数类型。
- 更好地检查
marshal.load*()的错误输入。 - rfc822.py 在解析地址字段类型时应比规范更宽松。具体来说，像 “From: Amazon.com <delivers-news2@amazon.com>” 这样的无效地址应该被正确解析。
- cgi.py 的 FieldStorage 类在面对大型二进制文件上传时，在内存方面应该更加保守。
https://bugs.python.org/issue210674
这里有两个问题：首先，因为 read_lines_to_outerboundary() 使用 readline()，所以对于二进制文件上传，可能会将大量数据读入内存。这可能应该查看部分的 Content-Type 头部，如果是二进制类型，则进行分块读取。
第二个问题与 self.lines 属性有关，该属性在 cgi.py 的修订版 1.56 中已移除（另请参阅）
- urllib 应该支持仅包含主机和端口的代理定义
- urlparse 应该更新以符合RFC 2396，该规范定义了路径每个段的可选参数。
- pickle 和 cPickle 抛出的异常目前是不同的；这些应该统一（可能异常应该在由两者导入的辅助模块中定义）。[没有错误报告；我只是想到了这一点。]
- 更多标准库例程应支持 Unicode。例如，urllib.quote() 可以将 Unicode 字符串转换为 UTF-8，然后进行通常的 %HH 转换。但这并非唯一一个！
- 应该有一种方法可以表明你不介意
str()或__str__()返回 Unicode 字符串对象。或者一个不同的函数——ustr()曾被提议。或者其他什么……http://sf.net/patch/?func=detailpatch&patch_id=101527&group_id=5470
- 从另一个线程杀死一个线程。或者发送一个信号。或者抛出一个异步异常。
- 调试器 (pdb) 应该理解包。
- Jim Fulton 提出了以下建议
I wonder if it would be a good idea to have a new kind of temporary file that stored data in memory unless: - The data exceeds some size, or - Somebody asks for a fileno. Then the cgi module (and other apps) could use this thing in a uniform way.
- Jim Fulton 指出，binascii 的 b2a_base64() 函数在某些情况下不需要追加换行符，或者需要追加除换行符以外的其他内容。
提案
- 添加一个可选参数，指定要追加的分隔符字符串，默认为 “\n”
- 可能将 None 特殊处理为分隔符字符串，以避免也添加填充字节？？？
- pydoc 应该与 HTML 文档集成，或者至少能够链接到它们。
- Distutils 应该推导 .c 和 .h 文件的依赖关系。
- asynchat 在多线程环境下有 bug。
- 如果高级模块（httplib、smtplib、nntplib 等）有设置套接字超时的选项就好了。
- curses 库缺少两个重要的调用：newterm() 和 delscreen()
https://bugs.python.org/issue665572, http://bugs.debian.org/175590
- 如果内置的 SSL 套接字类型可以用于非阻塞 SSL I/O 就好了。目前，像 Twisted 这样使用 SSL 实现异步服务器的包必须要求第三方包，如 pyopenssl。
- 将 reST 作为标准库模块
- 导入锁可能需要重新设计。
- 一个更友好的 API 来打开文本文件，取代（在某些人看来）丑陋的 “U” 模式标志。有一个提议是使用一个新的内置类型 textfile(filename, mode, encoding)。（它不也应该有一个 bufsize 参数吗？）
- 支持 Tkinter 的新控件和/或参数
- 对于在另一个类中定义的类，__name__ 应该是“outer.inner”，并且 pickling 应该起作用。（GvR 不再确定这是否容易甚至正确。）
- 制定更清晰的弃用政策（尤其是针对模块），并付诸实施。
https://mail.python.org/pipermail/python-dev/2002-April/023165.html
- 为 types 模块的常见用法提供替代方案；Skip Montanaro 已为此想法发布了一份 proto-PEP
https://mail.python.org/pipermail/python-dev/2002-May/024346.html
- 对 types 和 string 模块使用待定弃用。这要求为尚未涵盖的部分（例如 string.whitespace 和 types.TracebackType）提供替代方案。看来我们无法就此达成共识。
- 延迟追踪元组？
https://mail.python.org/pipermail/python-dev/2002-May/023926.html https://bugs.python.org/issue558745
- 将 'as' 设为关键字。它作为伪关键字已经够久了。（它在 2.5 中被弃用，并将在 2.6 中成为关键字。）
C API 期望
- 添加 C API 函数，以帮助那些构建嵌入式应用程序的 Windows 用户，其中 FILE * 结构与解释器编译时使用的 FILE * 不匹配。
https://bugs.python.org/issue210821
请参阅此错误报告，其中包含一项具体建议，该建议将允许 Borland C++ builder 应用程序与使用 MSVC 构建的 python.dll 进行交互。
工具
- Python 可以使用一个 GUI 构建器。
构建和安装
- Modules/makesetup 应该确保它从各种 Setup 文件生成的“config.c”文件是有效的 C 语言。它目前接受模块名称中包含 Python 或 C 标识符中不允许的字符。
- 从源代码构建时不应尝试覆盖 Include/graminit.h 和 Parser/graminit.c 文件，至少对于下载源代码发布而不是从 Subversion 或快照工作的用户而言。有些人发现在不寻常的构建环境中这是一个问题。
- configure 脚本可能已经随着时间的推移变得有点陈旧，并且可能无法很好地跟踪 autoconf 的最新功能。应该对其进行检查并可能进行清理。
https://mail.python.org/pipermail/python-dev/2004-January/041790.html
- 使 Python 符合 FHS（文件系统层次标准）
来源：https://github.com/python/peps/blob/main/peps/pep-0042.rst