On Nov 28, 6:10 am, Lie Ryan <lie.1...@gmail.com> wrote: > On 11/28/2009 10:38 PM, The Music Guy wrote: > > >> 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. :| > > <sniprant> > > ok, then what's your use case, AFAICT in the discussion here and > previous ones, nobody has yet described a realistic and compelling > situation where setattr/getattr is the best solution. That's why the > discussion tended to end with "not used frequently enough"; simply > because nobody can turn up with a use case to justify a new syntax, > especially since all the proposed syntax are ugly (the most acceptable > one, for me, is obj.[foo], still ugly but not as ugly as the others).
Alright, I'm not sure if my last message about this came through, so I'm going to assume it didn't. When I first started seeing @ show up in Python code, I said "what the heck is that? It looks so weird and _ugly_. I would never try to mess with that." But I started seeing it more and more, so I asked #python what it was. They told me about decorators, so I looked it up in the docs, and I thought the idea was interesting. It took me a while to figure out exactly how they worked--and judging from messages I've seen in #python a number of people have the same trouble understanding them. My point is that any particular syntax would look ugly to you only because you haven't seen it in use enough, and haven't used it enough yourself. But of course you haven't--it's not currently a valid syntax. However, the ugliness would seem to go away after the syntax had been in use for a while. And again, the EXACT syntax of the feature can be adjusted until its "just right". As for my specific use case, it's somewhat difficult to explain. The general idea was to isolate a pattern that I spotted repeated in several unrelated parts of my project. The pattern manifested itself as a set of 4-5 methods and/or properties on a class whose objects were designed to work in conjunction with other objects that fit a particular behavior. These other objects had methods and properties that were designed to interact with the first type of object in a similar but--how should I say--"inverted" fashion. This pattern showed up in many different classes throughout the project, and not only that, but the code was very similar. I decided to try to eliminate some of the code redundancy by creating a base class for all the classes to derive from. That didn't worked out okay for some things, but not for others. I can't remember the exact details of the problem at this point, but I believe it had to do with the keying/indexing protocol (ie. __getitem__, __setitem__, etc.). I decided to keep the base class (and have since extended it), but decided that it wasn't enough--that's when I decided to try metaclassing. After some work I managed to recreate the object-to- object relationship pattern that kept showing up everywhere, but in a generic way that allowed for the names of methods and properties that composed the pattern to vary in name and in the names that they referenced from other objects. The code worked very well, and allowed for the pattern to be added to any class by using a single, short line of code (something along the lines of __class_attr = { key: value }). Not only that, but the metaclass code itself was comprised of less than a screenful of code after docstrings and comments had been removed. However, the code was (and still is) very difficult to follow simply because of the way getters and setters had to be used to generate the methods and properties. P.s. Ben Finney, I appreciate your response, and I will get back to you, but I want to make sure I reply under the right circumstances or I'll end up putting my foot in my mouth. ^_^ -- http://mail.python.org/mailman/listinfo/python-list