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

Paul Barrett barrett at stsci.edu
Mon Jul 26 11:25:09 CDT 2004


Russell E Owen wrote:
> 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 clutter.
> 
> 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.

That pretty much sums up my opinion. :)

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218




More information about the Numpy-discussion mailing list