On Mon, 26 Jul 2004, Russell E Owen wrote:
Overall this sounds great.
However, I am still strongly against attribute access.
[...]
In this case there is another mechanism that is more natural, has no funny corner cases, and is much more powerful. Its only disadvantage is the need for typing for 4 extra characters. Saving 4 characters simply not sufficient reason to add this dubious feature.
I am sympathetic with Russell's point of view on this, but I do think there is more to gain than just typing 4 additional characters. When you read code that is using the dictionary version of attributes, you also are required to read and mentally parse those 4 additional characters. There is value to having clean, easily readable code that goes well beyond saving a little extra typing. If we didn't care about that, we'd probably all be using Perl. :-) Also, I like to use tab-completion during my interactive use of Python. I know how to make that work with attributes, even dynamically created attributes like those for record arrays. And it is really nice to be able to type <tab> and have it fill in a name or give a list of all the available columns. Doing that with the string/dictionary approach could be possible, I guess, but it is a lot trickier. So I do think there are some good reasons for wanting attribute access. Whether they are strong enough to counter Russell's sensible arguments about not cluttering up the interface and documentation, I'm not sure. My personal preference would be to get rid of the mapping between blanks and underscore and to do no mapping of any kind. Then if a column has a name that maps to a legal Python variable, you can access it with an attribute, and if it doesn't then you can't. That doesn't sound particular hard to understand or explain to me. Rick