Following system colour scheme - Python 增强提案 Selected dark colour scheme - Python 增强提案 Selected light colour scheme - Python 增强提案

Python 增强提案

PEP 258 – Docutils设计规范

作者:
David Goodger <goodger at python.org>
讨论至:
Doc-SIG 邮件列表
状态:
已拒绝
类型:
标准跟踪
要求:
256, 257
创建日期:
2001年5月31日
发布历史:
2001 年 6 月 13 日

目录

拒绝通知

虽然这可能成为现在独立的docutils的一个有趣的设计文档,但它已不再计划包含在标准库中。

摘要

本PEP文档记录了Docutils(一个Python文档字符串处理系统(DPS))的设计问题和实现细节。DPS的原理和高级概念记录在PEP 256,“文档字符串处理系统框架”中。另请参阅PEP 256,了解“文档字符串PEP路线图”。

Docutils采用模块化设计,因此其任何组件都可以轻松替换。此外,Docutils不限于处理Python文档字符串;它还在多种上下文中处理独立文档。

本PEP不要求对核心Python语言进行任何更改。其交付物包括一个用于标准库的包及其文档。

规范

Docutils项目模型

项目组件和数据流

                 +---------------------------+
                 |        Docutils:          |
                 | docutils.core.Publisher,  |
                 | docutils.core.publish_*() |
                 +---------------------------+
                  /            |            \
                 /             |             \
        1,3,5   /        6     |              \ 7
       +--------+       +-------------+       +--------+
       | READER | ----> | TRANSFORMER | ====> | WRITER |
       +--------+       +-------------+       +--------+
        /     \\                                  |
       /       \\                                 |
 2    /      4  \\                             8  |
+-------+   +--------+                        +--------+
| INPUT |   | PARSER |                        | OUTPUT |
+-------+   +--------+                        +--------+

每个组件上方的数字表示文档数据的路径。阅读器和解析器之间以及转换器和写入器之间的双宽度线表示沿这些路径发送的数据应该是标准的(纯粹且未扩展的)Docutils文档树。单宽度线表示内部树扩展或完全不相关的表示是可能的,但它们必须在两端都得到支持。

发布者

docutils.core模块包含一个“Publisher”门面类和几个便利函数:“publish_cmdline()”(用于命令行前端)、“publish_file()”(用于文件类I/O的编程使用)和“publish_string()”(用于字符串I/O的编程使用)。Publisher类封装了Docutils系统的高级逻辑。Publisher类通过Publisher.publish()方法对处理负总责。

  1. 设置内部设置(可能包括配置文件和命令行选项)和I/O对象。
  2. 调用阅读器对象从源输入对象读取数据,并使用解析器对象解析数据。返回一个文档对象。
  3. 通过附加到文档的转换器对象设置并应用转换。
  4. 调用写入器对象,它将文档转换为最终输出格式并将格式化数据写入目标输出对象。根据输出对象,输出可能从写入器返回,然后从publish()方法返回。

使用组件名称调用“publish”函数(或实例化“Publisher”对象)将导致默认行为。对于自定义行为(自定义组件设置),请首先创建自定义组件对象,并将*它们*传递给Publisher或publish_*便利函数。

阅读器

阅读器理解输入上下文(数据来自何处),将整个输入或离散的“块”发送给解析器,并提供将这些块绑定回一个连贯整体的上下文。

每个阅读器都是一个模块或包,导出具有“read”方法的“Reader”类。基本“Reader”类可以在docutils/readers/__init__.py模块中找到。

大多数阅读器必须被告知使用哪个解析器。到目前为止(请参阅下面的示例列表),只有Python源阅读器(“PySource”;仍不完整)能够自行确定解析器。

职责

  • 从源I/O获取输入文本。
  • 将输入文本连同新的文档树根传递给解析器。

示例

  • 独立(原始/纯文本):只需读取文本文件并进行处理。阅读器需要被告知使用哪个解析器。

    “独立阅读器”已在模块docutils.readers.standalone中实现。

  • Python源:请参阅下面的Python源阅读器。此阅读器目前正在Docutils沙盒中开发。
  • 电子邮件:RFC 822标头、引用摘录、签名、MIME部分。
  • PEP:RFC 822标头,“PEP xxxx”和“RFC xxxx”转换为URI。“PEP阅读器”已在模块docutils.readers.pep中实现;请参阅PEP 287PEP 12
  • 维基:将“维基链接”的全局引用查找整合到转换中。(只允许驼峰命名法还是无限制?)惰性缩进?
  • 网页:作为独立页面,但识别元字段作为元标签。支持某种模板吗?(在<body>之后,在</body>之前?)
  • 常见问题:结构化的“问题与答案”构造。
  • 复合文档:将章节合并成一本书。主清单文件?

解析器

解析器分析其输入并生成Docutils文档树。它们对数据的来源或目的地一无所知,也毫不关心。

每个输入解析器都是一个模块或包,导出具有“parse”方法的“Parser”类。基本“Parser”类可以在docutils/parsers/__init__.py模块中找到。

职责:给定原始输入文本和文档树根节点,通过解析输入文本来填充文档树。

示例:到目前为止,唯一实现的解析器是reStructuredText标记语言。它在docutils/parsers/rst/包中实现。

鼓励开发和集成其他解析器。

转换器

docutils/transforms/__init__.py中的Transformer类存储转换并将其应用于文档。每个新的文档树都附加一个转换器对象。发布者调用Transformer.apply_transforms()将所有存储的转换应用于文档树。转换将文档树从一种形式更改为另一种形式,添加到树中,或修剪它。转换解析引用和脚注编号,处理解释的文本,并执行其他上下文敏感的处理。

某些转换特定于组件(阅读器、解析器、写入器、输入、输出)。标准组件特定转换在组件类的default_transforms属性中指定。阅读器完成处理后,发布者调用Transformer.populate_from_components(),其中包含组件列表,并存储所有默认转换。

每个转换都是docutils/transforms/包中模块中的一个类,是docutils.transforms.Transform的子类。转换类都有一个default_priority属性,转换器使用该属性按顺序(从低到高)应用转换。将转换添加到Transformer对象时,可以覆盖默认优先级。

转换器职责

  • 按优先级顺序将转换应用于文档树。
  • 存储组件类型名称(“reader”、“writer”等)到组件对象的映射。这些被某些转换(如“components.Filter”)用于确定适用性。

转换职责

  • 就地修改文档树,纯粹将一种结构转换为另一种结构,或根据文档树和/或外部数据添加新结构。

转换示例(在docutils/transforms/包中)

  • frontmatter.DocInfo:文档元数据(书目信息)的转换。
  • references.AnonymousHyperlinks:匿名引用到相应目标的解析。
  • parts.Contents:为文档生成目录。
  • document.Merger:将多个已填充的文档树合并为一个。(尚未实现或完全理解。)
  • document.Splitter:将文档拆分为子文档的树形结构,可能按章节。它必须适当地转换引用。(既未实现也未远程理解。)
  • components.Filter:包含或排除依赖于特定Docutils组件的元素。

写入器

写入器生成最终输出(HTML、XML、TeX等)。写入器将内部文档树结构转换为最终数据格式,可能首先运行写入器特定的转换

当文档到达写入器时,它应该处于最终形式。写入器的工作只是(且仅是)将Docutils文档树结构转换为目标格式。可能需要一些小的转换,但它们应该是本地的且特定于格式的。

每个写入器都是一个模块或包,导出具有“write”方法的“Writer”类。基本“Writer”类可以在docutils/writers/__init__.py模块中找到。

职责

  • 将文档树转换为特定的输出格式。
    • 将引用转换为格式原生形式。
  • 将翻译后的输出写入目标I/O。

示例

  • XML:各种形式,例如
    • Docutils XML(内部文档树的表达式,实现为docutils.writers.docutils_xml)。
    • DocBook(正在Docutils沙盒中实现)。
  • HTML(XHTML实现为docutils.writers.html4css1)。
  • PDF(正在Docutils沙盒中开发ReportLabs接口)。
  • TeX(正在沙盒中实现LaTeX写入器)。
  • Docutils原生伪XML(实现为docutils.writers.pseudoxml,用于测试)。
  • 纯文本
  • reStructuredText?

输入/输出

I/O类为低级输入和输出提供统一的API。将存在用于各种输入/输出机制的子类。然而,它们可以被视为实现细节。大多数应用程序应满足于使用与Publisher关联的便利函数之一。

I/O类目前处于初步阶段;还有很多工作要做。问题

  • 如何在API中表示多文件输入(文件和目录)?
  • 如何表示多文件输出?也许是“写入器”变体,每种输出分发类型一个?或者带有相关转换的输出对象?

职责

  • 从输入源读取数据(输入对象)或将数据写入输出目的地(输出对象)。

输入源示例

  • 磁盘上的单个文件或流(实现为docutils.io.FileInput)。
  • 磁盘上的多个文件(MultiFileInput?)。
  • Python源文件:模块和包。
  • 从客户端应用程序接收的Python字符串(实现为docutils.io.StringInput)。

输出目的地示例

  • 磁盘上的单个文件或流(实现为docutils.io.FileOutput)。
  • 磁盘上的目录和文件树。
  • 返回给客户端应用程序的Python字符串(实现为docutils.io.StringOutput)。
  • 无输出;对于只使用部分正常输出的编程应用程序很有用(实现为docutils.io.NullOutput)。
  • 内存中的单个树形数据结构。
  • 内存中的其他一组数据结构。

Docutils包结构

  • 包“docutils”。
    • 模块“__init__.py”包含:类“Component”,Docutils组件的基类;类“SettingsSpec”,用于指定运行时设置的基类(由docutils.frontend使用);以及类“TransformSpec”,用于指定转换的基类。
    • 模块“docutils.core”包含门面类“Publisher”和便利函数。请参阅上面的Publisher
    • 模块“docutils.frontend”提供运行时设置支持,用于编程使用和前端工具(包括配置文件支持以及命令行参数和选项处理)。
    • 模块“docutils.io”为低级输入和输出提供统一的API。请参阅上面的输入/输出
    • 模块“docutils.nodes”包含Docutils文档树元素类库以及树遍历访问者模式基类。请参阅下面的文档树
    • 模块“docutils.statemachine”包含一个专门用于基于正则表达式的文本过滤器和解析器的有限状态机。reStructuredText解析器实现基于此模块。
    • 模块“docutils.urischemes”包含已知URI方案(“http”、“ftp”、“mail”等)的映射。
    • 模块“docutils.utils”包含实用函数和类,包括一个日志记录器类(“Reporter”;请参阅下面的错误处理)。
    • 包“docutils.parsers”:标记解析器
      • 函数“get_parser_class(parser_name)”按名称返回解析器模块。类“Parser”是特定解析器的基类。(docutils/parsers/__init__.py
      • 包“docutils.parsers.rst”:reStructuredText解析器。
      • 可以添加其他标记解析器。

      请参阅上面的解析器

    • 包“docutils.readers”:上下文感知输入阅读器。
      • 函数“get_reader_class(reader_name)”按名称或别名返回阅读器模块。类“Reader”是特定阅读器的基类。(docutils/readers/__init__.py
      • 模块“docutils.readers.standalone”读取独立文档文件。
      • 模块“docutils.readers.pep”读取PEP(Python增强提案)。
      • 要添加的阅读器:Python源代码(结构和文档字符串)、电子邮件、FAQ,可能还有维基和其他。

      请参阅上面的阅读器

    • 包“docutils.writers”:输出格式写入器。
      • 函数“get_writer_class(writer_name)”按名称返回写入器模块。类“Writer”是特定写入器的基类。(docutils/writers/__init__.py
      • 模块“docutils.writers.html4css1”是一个用于HTML 4.01和CSS1的简单超文本标记语言文档树写入器。
      • 模块“docutils.writers.docutils_xml”以XML形式写入内部文档树。
      • 模块“docutils.writers.pseudoxml”是一个简单的内部文档树写入器;它写入缩进的伪XML。
      • 要添加的写入器:HTML 3.2或4.01-loose、XML(各种形式,如DocBook)、PDF、TeX、纯文本、reStructuredText,可能还有其他。

      请参阅上面的写入器

    • 包“docutils.transforms”:树转换类。
      • 类“Transformer”存储转换并将其应用于文档树。(docutils/transforms/__init__.py
      • 类“Transform”是特定转换的基类。(docutils/transforms/__init__.py
      • 每个模块包含相关的转换类。

      请参阅上面的转换

    • 包“docutils.languages”:语言模块包含依赖于语言的字符串和映射。它们以其语言标识符命名(如下面文档字符串格式的选择中定义),将破折号转换为下划线。
      • 函数“get_language(language_code)”,返回匹配的语言模块。(docutils/languages/__init__.py
      • 模块:en.py(英语)、de.py(德语)、fr.py(法语)、it.py(意大利语)、sk.py(斯洛伐克语)、sv.py(瑞典语)。
      • 将添加其他语言。
  • 第三方模块:“extras”目录。这些模块仅在Python安装中尚不存在时才安装。
    • extras/optparse.pyextras/textwrap.py提供选项解析和命令行帮助;来自Greg Ward的http://optik.sf.net/项目,为方便起见而包含。
    • extras/roman.py包含罗马数字转换例程。

前端工具

tools/目录包含几个用于常见Docutils处理的前端。有关详细信息,请参阅Docutils前端工具

文档树

Docutils内部在组件之间使用一个单一的中间数据结构;它在docutils.nodes模块中定义。组件不要求*内部*使用此数据结构,只需在组件*之间*使用,如上面Docutils项目模型图所示。

允许自定义节点类型,前提是 (a) 在它们到达写入器之前,转换将其转换为标准 Docutils 节点,或者 (b) 自定义节点明确受某些写入器支持,并封装在经过筛选的“挂起”节点中。条件 (a) 的一个示例是Python 源阅读器(见下文),其中“样式化”转换将自定义节点转换为标准 Docutils 节点。HTML <meta> 标签是条件 (b) 的一个示例;它受 HTML 写入器支持,但不受其他写入器支持。reStructuredText 的“meta”指令创建一个“挂起”节点,其中包含有关嵌入的“meta”节点只能由 HTML 兼容写入器处理的信息。“挂起”节点由docutils.transforms.components.Filter转换解析,该转换检查调用写入器是否支持 HTML;如果不支持,则从文档中删除“挂起”节点(和封闭的“meta”节点)。

文档树数据结构类似于DOM树,但使用特定的节点名称(类)而不是DOM的通用节点。该模式在XML DTD(可扩展标记语言文档类型定义)中记录,它包含两部分

DTD定义了一组丰富的元素,适用于许多输入和输出格式。DTD保留了重建原始输入文本或其合理副本所需的所有信息。

有关详细信息,请参阅Docutils文档树(不完整)。

错误处理

当解析器在标记中遇到错误时,它会插入一条系统消息(DTD元素“system_message”)。系统消息有五个级别

  • 级别0,“DEBUG”:内部报告问题。对处理没有影响。级别0系统消息与其他消息分开处理。
  • 级别1,“INFO”:可以忽略的小问题。对处理影响很小或没有影响。通常不报告级别1系统消息。
  • 级别2,“WARNING”:应解决的问题。如果忽略,输出可能会出现小问题。通常会报告级别2系统消息,但不会停止处理。
  • 级别3,“ERROR”:应解决的重大问题。如果忽略,输出将包含不可预测的错误。通常会报告级别3系统消息,但不会停止处理。
  • 级别4,“SEVERE”:必须解决的严重错误。通常将级别4系统消息转换为异常,从而停止处理。如果忽略,输出将包含严重错误。

尽管初始消息级别是独立设计的,但它们与VMS错误条件严重性级别有很强的对应关系;级别1到4的带引号的名称是从VMS借用的。错误处理此后受到了log4j项目的影响。

Python源阅读器

Python源阅读器(“PySource”)是Docutils组件,它读取Python源文件,在上下文中提取文档字符串,然后解析、链接并将文档字符串组合成一个连贯的整体。它是一个主要且非平凡的组件,目前正在Docutils沙盒中进行实验性开发。此处介绍高级设计问题。

处理模型

这个模型将随着时间的推移而演变,整合经验和发现。

  1. PySource阅读器使用Input类将Python包和模块读入字符串树。
  2. 解析Python模块,将字符串树转换为带文档字符串节点的抽象语法树。
  3. 抽象语法树转换为包/模块的内部表示。提取文档字符串以及代码结构细节。请参阅下面的AST挖掘。为步骤6中的查找构建命名空间。
  4. 文档字符串逐个解析,生成标准Docutils文档树。
  5. PySource将所有单个文档字符串的文档树组装成一个与包/模块/类结构并行的Python特定自定义Docutils树;这是一个自定义的阅读器特定内部表示(参见Docutils Python源DTD)。命名空间必须合并:Python标识符、超链接目标。
  6. 根据Python命名空间查找规则,解析文档字符串(解释文本)到Python标识符的交叉引用。请参阅下面的标识符交叉引用
  7. 样式转换器(由转换器)应用于自定义文档树,使用标准节点作为基元渲染自定义节点,并发出标准文档树。请参阅下面的样式转换
  8. 其他转换由转换器应用于标准文档树。
  9. 标准文档树发送给写入器,写入器将文档转换为具体格式(HTML、PDF等)。
  10. 写入器使用Output类将结果数据写入其目的地(磁盘文件、目录和文件等)。

AST挖掘

将编写(或改编)抽象语法树挖掘代码,该代码扫描已解析的Python模块,并返回一个有序树,其中包含以下所有对象的名称、文档字符串(包括属性和附加文档字符串;见下文)和附加信息(括号中)

  • 模块
  • 模块属性(+ 初始值)
  • 类(+ 继承)
  • 类属性(+ 初始值)
  • 实例属性(+ 初始值)
  • 方法(+ 参数和默认值)
  • 函数(+ 参数和默认值)

(也提取注释吗?例如,模块开头的注释将是书目字段列表的好地方。)

为了评估解释文本交叉引用,还需要上述每个的命名空间。

请参阅python-dev/docstring-develop线程“AST mining”,始于2001-08-14。

文档字符串提取规则

  1. 检查什么
    1. 如果被文档化的模块中存在“__all__”变量,则只检查“__all__”中列出的标识符以获取文档字符串。
    2. 在没有“__all__”的情况下,检查所有标识符,除了那些名称为私有的标识符(名称以“_”开头但不是以“__”开头和结尾的标识符)。
    3. 1a和1b可以通过运行时设置覆盖。
  2. 其中

    文档字符串是字符串字面量表达式,并在Python模块中的以下位置识别

    1. 在模块、函数定义、类定义或方法定义的开头,在任何注释之后。这是Python __doc__属性的标准。
    2. 紧随模块、类定义或__init__方法定义的顶层的简单赋值之后,在任何注释之后。请参阅下面的属性文档字符串
    3. 紧接在(a)和(b)中的文档字符串之后发现的其他字符串字面量将被识别、提取和连接。请参阅下面的附加文档字符串
    4. @@@ 2.2风格的“属性”带有属性文档字符串?等待语法?
  3. 如何

    尽可能地,Python模块应该由Docutils解析,而不是导入。有几个原因

    • 导入不受信任的代码本质上是不安全的。
    • 使用内省检查导入模块时,源中的信息会丢失,例如注释和定义顺序。
    • 文档字符串将在字节码编译器忽略字符串字面量表达式的位置被识别(上面的2b和2c),这意味着导入模块将丢失这些文档字符串。

    当然,应该使用标准的Python解析工具,例如“parser”库模块。

    当模块的Python源代码不可用时(即只有.pyc文件存在)或对于C扩展模块,要访问文档字符串,只能导入模块,并且必须忍受任何限制。

由于属性文档字符串和附加文档字符串被Python字节码编译器忽略,因此它们的使用不会导致命名空间污染或运行时膨胀。它们不会被分配给__doc__或任何其他属性。模块的初始解析可能会略微影响性能。

属性文档字符串

(这是PEP 224的简化版本。)

紧随赋值语句之后的字符串字面量被文档字符串提取机制解释为赋值语句目标的文档字符串,在以下条件下

  1. 赋值必须在以下上下文之一中
    1. 在模块的顶层(即,不嵌套在复合语句中,如循环或条件语句内):一个模块属性。
    2. 在类定义的顶层:一个类属性。
    3. 在类“__init__”方法定义的顶层:一个实例属性。在其他方法中赋值的实例属性被认为是实现细节。(@@@ __new__方法?)
    4. 在模块或类定义的顶层的函数属性赋值。

    由于上述每个上下文都在顶层(即,在定义的外部套件中),因此可能需要为有条件地或在循环中赋值的属性放置虚拟赋值。

  2. 赋值必须针对单个目标,而不是目标列表或元组。
  3. 目标的形式
    1. 对于上面的上下文1a和1b,目标必须是一个简单的标识符(不是点状标识符、下标表达式或切片表达式)。
    2. 对于上面的上下文1c,目标必须是“self.attrib”的形式,其中“self”与“__init__”方法的第一个参数(实例参数)匹配,“attrib”是一个简单的标识符,如3a。
    3. 对于上面的上下文1d,目标必须是“name.attrib”的形式,其中“name”与已定义的函数或方法名称匹配,“attrib”是一个简单的标识符,如3a。

属性文档字符串后可以使用空行来强调赋值和文档字符串之间的连接。

示例

g = 'module attribute (module-global variable)'
"""This is g's docstring."""

class AClass:

    c = 'class attribute'
    """This is AClass.c's docstring."""

    def __init__(self):
        """Method __init__'s docstring."""

        self.i = 'instance attribute'
        """This is self.i's docstring."""

def f(x):
    """Function f's docstring."""
    return x**2

f.a = 1
"""Function attribute f.a's docstring."""
附加文档字符串

(这个想法改编自PEP 216。)

许多程序员希望广泛使用文档字符串进行API文档。然而,文档字符串确实占用运行程序的空间,因此一些程序员不愿“膨胀”他们的代码。此外,并非所有API文档都适用于交互式环境,在交互式环境中会显示__doc__

Docutils的文档字符串提取工具将连接出现在定义开头或简单赋值之后的所有字符串字面量表达式。只有定义中的第一个字符串可作为__doc__,并可用于适合交互式会话的简短用法文本;后续的字符串字面量和所有属性文档字符串被Python字节码编译器忽略,并且可能包含更广泛的API信息。

示例

def function(arg):
    """This is __doc__, function's docstring."""
    """
    This is an additional docstring, ignored by the byte-code
    compiler, but extracted by Docutils.
    """
    pass

文档字符串格式的选择

处理系统允许使用多种输入格式,而不是强迫每个人使用单一的文档字符串格式。一个特殊变量__docformat__可以在模块的顶层出现在任何函数或类定义之前。随着时间的推移或通过规定,应该会出现一种标准格式或一组格式。

模块的__docformat__变量仅适用于模块文件中定义的对象。特别是,包的__init__.py文件中的__docformat__变量不适用于子包和子模块中定义的对象。

__docformat__变量是一个字符串,包含所使用的格式名称,一个不区分大小写的字符串,与输入解析器模块或包的名称(即,与“import”模块或包所需的名称相同)或注册的别名匹配。如果未指定__docformat__,则默认格式现在为“plaintext”;如果将来建立标准格式,可能会更改为标准格式。

__docformat__字符串可以包含一个可选的第二个字段,与格式名称(第一个字段)用一个空格分隔:一个不区分大小写的语言标识符,如RFC 1766中定义的。典型的语言标识符由ISO 639的2字母语言代码组成(只有在没有2字母代码时才使用3字母代码;RFC 1766目前正在修订以允许3字母代码)。如果未指定语言标识符,则默认值为“en”表示英语。语言标识符传递给解析器,可用于依赖于语言的标记功能。

标识符交叉引用

在Python文档字符串中,解释的文本用于对程序标识符进行分类和标记,例如变量、函数、类和模块的名称。如果只给出标识符,则根据Python命名空间查找规则隐式推断其作用。对于函数和方法(即使是动态赋值的),可以包含括号('()')

This function uses `another()` to do its work.

对于类、实例和模块属性,必要时使用带点标识符。例如(使用reStructuredText标记)

class Keeper(Storer):

    """
    Extend `Storer`.  Class attribute `instances` keeps track
    of the number of `Keeper` objects instantiated.
    """

    instances = 0
    """How many `Keeper` objects are there?"""

    def __init__(self):
        """
        Extend `Storer.__init__()` to keep track of instances.

        Keep count in `Keeper.instances`, data in `self.data`.
        """
        Storer.__init__(self)
        Keeper.instances += 1

        self.data = []
        """Store data in a list, most recent last."""

    def store_data(self, data):
        """
        Extend `Storer.store_data()`; append new `data` to a
        list (in `self.data`).
        """
        self.data = data

每个用反引号(“`”)引起来的标识符都将成为对标识符本身定义的引用。

样式转换

样式转换是PySource阅读器特有的专门转换。PySource阅读器不必对样式做出任何决定;它只是生成一个逻辑构建的文档树,经过解析和链接,包括自定义节点类型。样式转换理解阅读器创建的自定义节点,并将其转换为标准Docutils节点。

可以实现多个样式转换,并在运行时选择其中一个(通过“--style”或“--stylist”命令行选项)。每个样式转换实现不同的布局或样式;因此得名。它们将阅读器的上下文理解部分与处理的布局生成部分分离,从而实现更灵活和更健壮的系统。这也有助于“将样式与内容分离”,这是SGML/XML的理想。

通过使执行样式设置的代码小而模块化,人们更容易创建自己的样式。现有工具的“入门门槛”太高;提取样式设置代码将大大降低门槛。

项目网站

该项目的SourceForge项目已在http://docutils.sourceforge.net/上建立。

致谢

本文档借鉴了Python Doc-SIG档案中的想法。感谢所有过去和现在的成员。


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

上次修改:2025-02-01 08:59:27 GMT