On 05/08/2012 12:50 AM, Peter Otten wrote:
Charles Hixson wrote:
class Node:
def __init__(self, nodeId, key, value, downRight, downLeft,
parent):
dirty = True
dlu = utcnow()
self.node = [nodeId, downLeft, [key], [value],
[downRight], parent, dirty, dlu]
Note that node[3] is a list of keys (initially 1) and node[3] is a list
of values, etc.
What I'd like to do is to be able to address them thusly:
k = node.key[2]
v = node.value[2]
but if there's a way to do this, I haven't been able to figure it out.
Any suggestions?
I don't see the problem:
class Node(object):
... def __init__(self, key):
... self.node = ["foo", "bar", [key], "baz"]
... @property
... def key(self):
... return self.node[2]
...
node = Node(42)
node.key
[42]
node.key[0]
42
node.key.append(7)
node.key
[42, 7]
del node.key[0]
node.key[:] = [3, 2, 1]
node.key
[3, 2, 1]
node.key = "foo"
Traceback (most recent call last):
File "<stdin>", line 1, in<module>
AttributeError: can't set attribute
But the design proposed by Dan Sommers really is the way to go...
That depends on what you're doing. For many, perhaps most, purposes I
would agree. Not for this one. And I couldn't use an internal dict, as
the order in which the items of the sub-lists occur is significant. The
sub-lists need to be lists, though they could be separated out as named
variables (which would be lists).
The approach of returning the entire list would, indeed, work, but it
exposes things that I would prefer to keep internal to the class (i.e.,
all the, e.g., keys that aren't currently being addressed). I suppose
it isn't too inefficient, as IIUC, all you're really passing back and
forth are pointers, but it doesn't *feel* like the right answer. So I
can handle it by using getter and setter functions that recognize
indicies, but it's less elegant than using indexing to access them. So
I thought I'd ask.
The ActiveState recipe *might* do what I want. I honestly can't tell
after a brief study. But it's much too complex to be a worthwhile
choice. I was hoping that I'd just overlooked one of the standard
features of Python.
To be truthful, the main benefit I see from using a class rather than a
naked list structure is that I can readily test the type of the data. A
secondary benefit would be the nicer syntax, as with the list all
manipulation would be done via specialized functions, and for some of
the terms indexed access would be syntactically nicer. But it looks
like that isn't one of the possibilities. Using a native list structure
and manipulatory functions is nicer except in two ways:
1) There's no data hiding, so discipline must substitute for language
structure.
2) There's excess names apparent at an upper level. I wouldn't exactly
call it namespace pollution, but it's certainly an increase in the
higher-level namespace background noise level, even though it's all
functional.
--
Charles Hixson
--
http://mail.python.org/mailman/listinfo/python-list
