[Numpy-discussion] Proposed record array behavior: the rest of the story: updated
rlw at stsci.edu
Mon Jul 26 11:45:11 CDT 2004
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.
More information about the Numpy-discussion