On Nov 28, 3:07 am, Lie Ryan <lie.1...@gmail.com> wrote: > On 11/28/2009 3:08 PM, The Music Guy wrote: > > > As for your code, I haven't seen it, so it would be hard for me to say > > exactly how the new syntax would come into play. What I can tell you, > > however, is that the parts of your code that would use it would > > probably be easier to read and change to anyone with a firm grasp of > > the proposed syntax. > > Isn't this much easier to read and grasp? > > obj.d["my_%s" % foo] += 3 > > doesn't need new syntax as well.
Actually, that's similar to my backup solution, which is a variant of the "attrs" class that PEP 363 provides. It does make things easier to read, but a new syntax would still be better because: 1.) A new syntax would apply to _everything_ as it would be a hook to the very mechanism that gets the value of a member from an object and does not rely on an object defining the magic "d" property. I suppose you could argue that an enhancement could be made to the language that says that all objects must define the magic "d" (so the builins "object" and "type" would have to define it). That also has the added benefit of not conflicting with PEP 3003, which says it is fine to add new methods (and I would assume properties as well) to existing classes. 2.) Ben's patch for his proposed syntax generated an aproximate 1% performance hit for the interpreter overall versus a >40% increase where code that used the getattr/settattr functions was modified to use the proposed syntax. The magic "d" MIGHT have a performance increase over the getattr/setattr functions, but a syntax would still be significantly faster because there would be less function dereferencing/calling. For the purposes that I had intended for the syntax to be used, that would definitely matter. > If you use it a lot, it is likely 1) you have abused class syntax for > what should have been a dict or 2) what you need is to override > __getattr__/__getattribute__ and __setattr__ Oh boy...here we go. :| Please listen. In all the time I've spent in the coding community (that's at least 7 years) and especially since I started paying attention to the Python community (2 years), I have noticed a trend: When one coder does something that another cannot understand, frequently the other will assume the former is not only doing things wrong, but is doing them _blatantly_ wrong. I have caught myself making that very assumption many times in the past, and I've tried hard to build up an immunity against the impulse to make that assumption. At this point, I don't even believe in such a thing as a universal "wrong way" and a "right way" to code that applies to every circumstance. The way to solve a problem depends on the problem. When it comes to coding, there is not an absolute "right" way or "wrong" way--unless we're talking about, say, stealing closed source code without permission, or deliberately coding in a way that will cause problems for the end user (like causing memory clogs or buffer overflows and whatnot). All of this can be determined through common sense. And yet I continue to see the attitude of "my solution is the ONLY solution to your problem, and it doesn't matter if I don't even actually understand the problem." Not everyone does this, but it is a frequent enough occurence to be worth noting. If I had to pull a number out of my magic bag, I would say 4 out of 10 resposes have at least a hint of this attitude, and 2.5/10 where it is very obvious. But I digress. I've already gone over other possible solutions and the one I am using seems to fit the bill better than any other yet presented to me, including the ones you just suggested. In fact, I'm fairly certain that __getattr__ and friends even apply to the situation, or if they do, they're certainly inferior alternatives to the use of getattr/setattr. Not that I'm calling you inferior--I'm just saying that if you had a better understanding of the problem you would not see __getatrr__ et al. as parts of a possible solution because they don't really make logical sense given the circumstances. ...and I have one last thing to say. I feel very strongly that metaclassing is a fiercely underestimated and largely untapped source of good coding solutions. I hope that many coders will see this and help to make it more adoptable by the masses; at present it is seen as a big, scary beast that is hard to tame and even harder to drive. It is portrayed as something dangerous that should only be used in relatively rare situations. I disagree with this view. It is the view itself which makes it seem so dangerous (in other words, it is self- perpetuating). Well, that's about enough yakking for 5:30 in the morning...time to give my noggin a rest. -- Brad Harms -- http://mail.python.org/mailman/listinfo/python-list
