08-09-2009 o 02:15:10 Steven D'Aprano wrote:

On Mon, 7 Sep 2009 09:37:35 am Jan Kaliszewski wrote:

...

06-09-2009 o 20:20:21 Ethan Furman wrote:

...

...

... I love being able to type

current_record.full_name == last_record.full_name

instead of

current_record['full_name'] == last_record['full_name']

Me too, and I suppose many people too...

The latter:

* makes your code less readable if there is high density of such expressions;

* makes typing much more strenuous/irritating -- what is not very important in case of advanced development (when time of typing is short in relation to time of thinking/reading/testing) but becomes quite important in case of scripting (which is still important area of Python usage).

If you have a large number of such expressions, 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.

FNAME = "full_name" # Define the string in one place only. current_record[FNAME] == last_record[FNAME] # Use it in many places.

Not only is it shorter to use, but it's easy to change the key "full_name" to (say) "complete_name" or "volledige_naam" with one edit, and without mistakenly changing some other string which just happens to match the key.

You are right, but it's a bit different story... I don't say that attr access is always better than key access -- but only that sometimes it is.

(I don't know about others, but when I'm first working on a piece of code, and before I settle on an API or database schema, I often change field names two or three times before I settle in on the final version.)

Me too! :)

In any case, while I accept that this is sometimes useful, I also think that it's a something which is simple enough to add to your classes when necessary with just a few lines -- all you really need are the __*attr__ methods, everything else is superfluous. If you're doing this a lot, avoid boilerplate with a class decorator. Here's an untested minimalistic version which probably does everything necessary:

def add_attr(cls): """Class decorator which adds attribute access to mappings.""" def __getattr__(self, name): return self[name] def __setattr__(self, name, value): self[name] = value def __delattr__(self, name): del self[name] for func in (__getattr__, __setattr__, __delattr__): setattr(cls, func.__name__, func) return cls

I'd add to it also dict-like iteration (__iter__(), _keys(), _values(), _items()) and __str__ adjusted to nice nested representation (like in some posts in this thread, e.g. my proposition).

Fields of an object (attributes) and keys of a mapping are generally for different purposes, and I'm not sure we should encourage people to conflate the two. I think this belongs in the cookbook, not the standard library.

I think it depends how often people need to implement such boiler-plate code for themselves. Now I see that this thread is not very popular, so indeed maybe you are right... Though it'd be nice to have OOTB such a factory in `collections` module... Cheers, *j -- Jan Kaliszewski (zuo)

Steven D'Aprano writes:

Fields of an object (attributes) and keys of a mapping are generally for different purposes, and I'm not sure we should encourage people to conflate the two.

+1 on discouraging conflation.