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

[Colin J. Williams]

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 
> 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. 

There is merit to this suggestion.  It would expose the proposal to 
other expeiences.

>
>
> 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.
>
> Regards,
>
> -- Russell

Perry Greefield summarized:

Rarr.field.home_address
Rarr.field['home address']
Rarr.field('home address')


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[6] be equivalent to the above?  This may appear
redundant, but it gives a method for selecting a group of columns,
eg. Rarr.field[6:9]

Finally, would Rarr.field.home_address.city or
               Rarr.field.work_address.city

be legitimate?

As Russell Owen pointed out, at the end of the day Perry Greenfield will 
use his
judgement as to the best arrangement and we will all live with it.

Colin W,

>
>
> -------------------------------------------------------
> 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.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>