[Python-ideas] possible attribute-oriented class

Jim Jewett jimjjewett at gmail.com
Tue Sep 8 16:53:57 CEST 2009


On Mon, Sep 7, 2009 at 9:02 PM, Jan Kaliszewski<zuo at chopin.edu.pl> wrote:
> 08-09-2009 o 02:15:10 Steven D'Aprano <steve at pearwood.info> wrote:

>> ... what's wrong with this?

> a['xyz'] = something['blablabla'] + somethingelse['foobar']
> b['ababababa'] += afun(bobo['dodo']['kookoo'] * pofopofo['gh'][0]['a'])
> cupu['abc'] = (kukumunu['bo'], kukumunu['kuu'].mbmbmb['lalala'])

> a.xyz = something.blablabla + somethingelse.foobar
> b.ababababa += afun(bobo.dodo.kookoo * pofopofo.gh[0].a)
> cupu.abc = (kukumunu.bo, kukumunu.kuu.mbmbmb.lalala)

> For me the latter is definitely easier to read and understand.

I would describe it as "less difficult" rather than "easier".  My
biggest problem is that at that stage, I'm still typing raw, and
inclined to make typos.

The difference between fname and fnam won't be caught either way, but
field access at least keeps me from forgetting quotes, or forgetting
them at one end.

>> ... I often change field names two or three times
>> before I settle in on the final version.

And often because of an ambiguity with another field that I hadn't
originally thought to name.  Neither solution fixes this, but
attribute access is slightly easier to change.

>> [recipe to simplify attr-access]

> I think it depends how often people need to
> implement such boiler-plate code for themselves.

Attribute access is clearly better -- except for one thing.

While I'm doing this, I'm still in exploratory mode, and I *will* need
to clean up the API if I ever want better than quick-and-dirty.  If
the quick-and-dirty is already using attribute access, that makes the
transition a bit trickier.  If the quick-and-dirty is using dict
access, at least I have a clear marker.

-jJ



More information about the Python-list mailing list