08-09-2009 o 02:15:10 Steven D'Aprano <st...@pearwood.info> wrote:
On Mon, 7 Sep 2009 09:37:35 am Jan Kaliszewski wrote:
06-09-2009 o 20:20:21 Ethan Furman <et...@stoneleaf.us> 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) <z...@chopin.edu.pl>
--
http://mail.python.org/mailman/listinfo/python-list
