[Numpy-discussion] Proposed record array behavior: the rest of the story: updated

Russell E Owen rowen at u.washington.edu
Mon Jul 26 09:40:06 CDT 2004

At 11:43 AM -0400 2004-07-26, Perry Greenfield wrote:
>I'll try to see if I can address all the comments raised (please let me know
>if I missed something).
>...(nice proposal elided)...
>Any comments on these changes to the proposal? Are there those that are
>opposed to supporting attribute access?

Overall this sounds great.

However, I am still strongly against attribute access.

Attributes are usually meant for names that are intrinsic to the 
design of an object, not to the user's "configuration" of the object. 
The name mapping proposal isn't bad (thank you for keeping it 
simple!), but it still feels like a kludge and it adds unnecessary 

Your explanation of this limitations was clear, but still, imagine 
putting that into the manual. It's a lot of "be careful of this" 
info. That's a red flag to me. Imagine all the folks who don't read 
carefully. Also imagine those who consider attribute access "the 
right way to do it" and so want to clean up the limitations. I think 
you'll see a steady stream of:
"why can't I see my field..."
"why can't you solve the collision problems"
"why can't I use special character thus and so"

I personally feel that when a feature is hard to document or adds 
strange limitations then it probably suggests a flawed design.

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.

Before implementing attribute access I have two suggestions (which 
can be taken singly or together):
- Postpone the decision until after the rest of the proposal is 
implemented. See if folks are happy with the mechanisms that are 
available. I freely confess to hoping that momentum will then kill 
the idea.
- Discuss it on comp.lang.py. I'd like to see it aired more widely 
before being adopted. So far I've seen just a few voices for it and a 
few others against it. I realize it's not a democracy -- those who 
write the code get the final say. I also realize some folks will 
always want it, but that tension between simplicity and 
expressiveness is intrinsic to any language. If you add everything 
anybody wants you get a mess, and I want to avoid this mess while we 
still can.

I hope nobody takes offense. I certainly did not mean to imply that 
those who wish attribute access are inferior in any way. There are 
features of python I wish it had that will never occur. I honestly 
can see the appeal of attributes; I was in favor of them myself, 
early on. It adds an appealing expressiveness that makes some kind of 
code read more naturally. But I personally feel it has too many 
limitations and is unnecessary.


-- Russell

More information about the Numpy-discussion mailing list