[Numpy-discussion] Proposed record array behavior: the rest of the story: updated
Colin J. Williams
cjw at sympatico.ca
Mon Jul 26 14:42:01 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.
Russell, I hope that you will elaborate this distinction between design
and usage. On the face of it, I would have though that the two should
be closely related.
> 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
> - 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.
There is merit to this suggestion. It would expose the proposal to
> 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
Perry Greefield summarized:
Will all work for a field named "home address"
This is good, it gives the desired functionality.
One minor suggestion. We have Rarr.X.home_address, I believe
that, in earlier posting, someone suggested that X.home_address
really identifies a column rather than a field.
Suppose that home_address is field number 6 in the record,
Would Rarr.field be equivalent to the above? This may appear
redundant, but it gives a method for selecting a group of columns,
Finally, would Rarr.field.home_address.city or
As Russell Owen pointed out, at the end of the day Perry Greenfield will
judgement as to the best arrangement and we will all live with it.
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion