Peter Suter <[email protected]> writes:
>> This should probably include moving the few existing unit tests in
>> `future27.py` out of the `__main__` section of that file into
>> `tests/future27.py` and having it called as part of the normal unit
>> tests.
> I'm wondering, would it be best to drop `future27.py` entirely? It
> only defines (and tests) `namedtuple`, which is only used once to
> define `Storage.RevCache`. It seems it would be easier to define:
> {{{
> class RevCache(object):
> def __init__(self, youngest_rev, oldest_rev, rev_dict, tag_set,
> srev_dict, branch_dict):
> self.youngest_rev = youngest_rev
> self.oldest_rev = oldest_rev
> self.rev_dict = rev_dict
> self.tag_set = tag_set
> self.srev_dict = srev_dict
> self.branch_dict = branch_dict
>
> def __iter__(self):
> yield self.youngest_rev
> yield self.oldest_rev
> yield self.rev_dict
> yield self.tag_set
> yield self.srev_dict
> yield self.branch_dict
> }}}
> Or is there more to it?
...one property of namedtuple() to keep in mind is that it doesn't
mutate the RevCache instance in-place but always creates a new one,
i.e. namedtuple provides a /persistent/ data-structure. Moreover,
namedtuple() also uses __slots__ internally as an optimization, which
will become noticeable the larger the revision-cache gets.
However, you could just take the Python code that namedtuple generates
(which I'm /assuming/ is not covered by the Python std-lib copyright)
and throw away the namedtuple()-code-generator... then you should be on
the safe side wrt to bug-compatibility.
hth,
hvr
--
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
