>
> compatibility, but worrying about unlikely uses of v._bodyString may be
> overly cautious. Would reopening #366 help you?
>
It can be implemented as one-way property. Assigning to lines maybe
disabled or it may immediately assign to _bodyString. Reading lines will
check if _bodyString has changed meanwhile just by comparing it with cached
version, and return cached tuple if it is still valid. For example:
def _get_lines(self):
if self._old_bodyString == self._bodyString:
return self._lines
else:
self._old_bodyString = self._bodyString
self._lines = tuple(g.splitLines(self._bodyString))
return sefl._lines
lines = property(_get_lines)
It will merely make code more readable. It is not requirement for the new
read/write/line_numbering code. That code uses its own caching to achieve
the same effect, but it turned out that even without caching performance is
good. Because new code makes only one pass through all nodes and lines and
it makes little difference if lines were cached or not.
But even without speed gains I would like to use v.lines for readability
although vlines(p) is almost the same and function implementation of vlines
is trivial even with caching. The only drawback is that it should be
re-implemented in all scripts that use it.
Vitalije
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
