dulwich-users team mailing list archive
-
dulwich-users team
-
Mailing list archive
-
Message #00245
Tree.items()
>
> diff --git a/dulwich/objects.py b/dulwich/objects.py
index 8fa4ffa..ea69ec1 100644 (file)
--- a/dulwich/objects.py
+++ b/dulwich/objects.py
@@ -811,7 +811,12 @@ class Tree(ShaFile):
self._needs_serialization = True
def entries(self):
- """Return a list of tuples describing the tree entries"""
+ """Return a list of tuples describing the tree entries.
+
+ :note: The order of the tuples that are returned is different from
> that
+ returned by the items and iteritems methods. This function will
> be
+ deprecated in the future.
+ """
self._ensure_parsed()
# The order of this is different from iteritems() for historical
# reasons
@@ -826,6 +831,13 @@ class Tree(ShaFile):
self._ensure_parsed()
return sorted_tree_items(self._entries)
+ def items(self):
+ """Return the sorted entries in this tree.
+
+ :return: List with (name, mode, sha) tuples
+ """
+ return list(self.iteritems())
+
We certainly don't want to copy the list when the result from
sorted_tree_items is already a list, which it is in the C implementation.
In practice, there's no way to implement iteritems() without creating a list
first, since we have to sort it.* In Python, we create the sorted list, then
yield from it. In C, we create the list, sort it in place, and return it.
Given that, I don't see the point of having two separate methods, one that
returns an iterator and one that returns a list. I'd be just as happy to
rewrite sorted_tree_items to always return a list and leave iteritems() as a
deprecated synonym for items().
However, since at this point we're talking about creating and/or deprecating
lots of methods, perhaps we should consider this a bit further...
* - That's not quite true; we could store entries in the order we parse
them, but that's a bigger code change with more performance implications.
> def _deserialize(self, chunks):
"""Grab the entries in the tree"""
try: