indexed property? Can it be done?

Charles Hixson charleshixsn at earthlink.net
Tue May 8 12:30:11 EDT 2012


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




More information about the Python-list mailing list