Python ElementTree: ElementTree与根元素

Question

我对Python中的一些设计决策感到有点困惑--它们似乎有些武断，所以我想要澄清一下，这些决定是否有一些逻辑支持，或者它们或多或少是临时性的。

因此，通常有两种方法可以生成ElementTree --一种是通过某种源流，如文件或其他I/O流。这是通过parse()函数或ElementTree.parse()类方法实现的。

另一种方法是直接从string对象加载XML。这可以通过fromstring()函数来完成。

好的，很好。现在，我认为这些函数返回的内容基本相同--它们之间的区别基本上是输入的来源(一个接收文件或流对象，另一个接受普通字符串)。除了某些原因，parse()函数返回一个ElementTree对象，但是fromstring()函数返回一个Element对象。区别基本上是，Element对象是XML的根元素，而ElementTree对象则是根元素的“包装器”，这提供了一些额外的特性。您始终可以通过调用ElementTree对象从getroot()对象获取根元素。

尽管如此，我还是不明白为什么我们有这样的区别。为什么fromstring()直接返回根元素，而parse()返回ElementTree对象？这种区别背后有什么逻辑吗？

Answer 1

一个美丽的答案来自于这个古老的讨论

ElementTree的创建者Fredrik实际上并不认为它是一种设计上的“怪癖”。他认为它是为不同的用例设计的。当解析一个文件(通常包含完整的文档(在ET中表示为ElementTree对象)时，for ()，特别是“文字包装器”XML()用于解析字符串，哪一个(大多数？)通常只包含XML片段。对于片段，您通常希望继续将其插入到另一棵树中，因此几乎在所有情况下都需要顶级元素。

和：

为什么et.parse不是唯一的方法呢？为什么有XML或have字符串呢？用例。XML()是fromstring()的别名，因为编写它非常方便(而且可读性好)。 节= XML('A至Z') section.append(段落) 对于源代码中的XML文本。from string ()之所以存在，是因为当您想解析从任何源获得的字符串中的片段时，很容易用该函数来表示它，如 el =fromstring字符串(Some_string) 如果要从文件或类似文件的对象解析文档，请使用parse()。三个用例，三个功能。从字符串解析文档的第四个用例没有自己的函数，因为编写文档很简单。 tree =解析(BytesIO(Some_byte_string))

Answer 2

我的想法与注释中的same相同:解析获取文件位置或文件对象，并保留该信息，以便它能够提供额外的实用程序，这是非常有用的。如果解析没有返回ET对象，那么您必须更好地跟踪源和诸如此类的内容，以便手动将它们反馈到ET对象默认具有的助手函数中。与文件不同的是，Strings-根据定义--没有从它们附加的相同类型的信息，因此您不能为它们创建相同的实用程序(否则很可能会有一个ET.parsefromstring()方法来返回一个ET对象)。

我怀疑这也是命名为ET.fromfile()的方法背后的逻辑:我希望从from文件和feeling返回相同的对象类型，但不能说我希望从解析中得到相同的对象类型(自从我开始使用ET以来已经很长时间了，所以无法验证这一点，但这是我的感觉)。

关于在元素上放置实用方法的主题Remram，据我了解，在实现方面，元素是非常统一的。人们谈论“根元素”，但树根上的元素在类属性和方法方面与所有其他元素完全相同。据我所知，元素甚至不知道他们的父母是谁，这很可能支持这种一致性。否则，可能会有更多代码来实现"root“元素(它没有父元素)或重新父元素。在我看来，元素类的简单性极大地有利于它。因此，在我看来，最好是让元素在很大程度上不知道它们上面的任何内容(它们的父元素，它们来自的文件)，这样就不会有任何障碍涉及在同一棵树中有不同输出文件的4个元素(等等)。

当涉及到在代码中实现模块时，在我看来，脚本必须在某种程度上将输入识别为一个文件(否则它将尝试将文件从字符串传递到另一个文件)。因此，不应该出现这样一种情况，即解析的输出应该是意外的，因此假设ElementTree是一个元素并以元素的形式处理(当然，除非解析是在程序员没有检查解析做了什么的情况下实现的，这在我看来只是一个糟糕的习惯)。