[Numpy-discussion] Proposed record array behavior: the rest of the story: updated
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
> - 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
That pretty much sums up my opinion. :)
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