>
> Having said that, the ivars() method is dubious, and imo should be
> replaced by explicit assignments. Like this:
>
# ( positions, nodes, attrs, levels, gnx2pos, parPos,
> # expanded, marked, selPos) = self.ivars()
> attrs = self.attrs
> gnx2pos = self.gnx2pos
> levels = self.levels
> nodes = self.nodes
> parPos = self.parPos
> positions = self.position
>
> As you can see, not all the tuple values are unpacked. That's correct:
> pyflakes will tell us exactly which ivars are, and aren't used.
>
Well, in my opinion this make code ugly. It adds much unnecessary clutter.
Every ivar is written twice and self is written many times. To read and
understand how code works this first line should be read and understood
only once. It should be the first line of all methods. Once one understands
what every variable contains, this line should be very easy to just skim
and continue reading the rest of method code. All variables are named
everywhere identically. Besides all this lists, dicts and sets have no
meaning at all if separated from each other. Only together they represent
the outline. The fact that not all methods use every item can't be a
problem.
Having pyflake complains about unused variables in this case wouldn't
really prevent any real bug. The way I see it, pyflake will force code to
be more cluttered without providing any benefit at all.
The fact you pointed out that those lists, sets and dicts are never
replaced, just altered, gave me an idea that ivars method should not be a
method but namedtuple instance and all those collections its elements:
LTMData = namedtuple('LTMData', 'positions, nodes, attrs, levels, gnx2pos,
parPos, expanded, marked')
class LeoTreeModel:
def __init__(self):
self.data = LTMData([],[],{},[],defaultdict(list),[],set(),set())
Probably names can be chosen better, but being an immutable tuple is a good
thing. It will prevent any attempt to separate core data collections in
LTM, which should keep data model safe.
All methods that currently do not start with the assignment line are
probably methods that I wrote first, before this list of data items were
fully known. In the future it may become necessary to add another item to
this collection, but no code outside LeoTreeModel should have to be changed.
miniTkLeo should be cleaned of any direct access to these collections and
perhaps some more specific getter methods added to LeoTreeModel.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
