possible attribute-oriented class

Ken Newton krnewton at gmail.com
Sat Sep 5 07:51:39 CEST 2009

On Fri, Sep 4, 2009 at 9:49 PM, Steven
D'Aprano<steve at remove-this-cybersource.com.au> wrote:
>> The old discussion, the above link points to, shows that such a
>> dot-accessible dict-like class is something that many people need and
>> repeatedly implemet it (more or less perfectly) for themselves.
> I think it's something which people copy from other languages because
> that's what they're used to, not because they need it.
> It's just a change in syntax. Whether you write x.key or x['key'] is a
> matter of convenience. Attribute access is optimized for when you know
> the key names at compile time, key access is optimized for when you don't
> know the names until runtime. Compare:
> # You know the key when you write the code.
> x.key versus x['key']
> # You don't know the key until runtime.
> s = get_key()
> getattr(x, s) versus x[s]

I would think this is much more than just copy from other language styles or
'just' a syntax change -- the apparent widespread use would hint at a deeper
need.  For my use, the need is the significant simplification in interactive use
(less and easier typing for x.key than x['key']).  Even for the cases where
my anticipated users will save lines of code in a script or module, they will
do this in a context where they do generally know the keys when they write
their code. ...And they will appreciate the simpler semantics of the attribute
access.  In my case also, execution speed will not be critical. This class will
be used as a set of configuration parameters that will generally not be applied
in time critical loops, but in occasional use generation of parameterized
method sequences to control a main application coded in C/C++.

The C interface is a reason that it would be nice to see this as a
basic type rather
than an add-on module.  Having an API pre-defined on the C side for this would
also be directly useful in my case.


More information about the Python-list mailing list