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