Feature request: String-inferred names

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sat Nov 28 22:39:56 EST 2009


On Sat, 28 Nov 2009 17:22:27 -0800, The Music Guy wrote:

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

Removing code redundancy is all very well, but beware of turning into an 
architecture astronaut:

http://www.joelonsoftware.com/articles/fog0000000018.html

There is such a thing as over-generalisation -- if you're having to 
struggle to get the abstract code working abstractly enough, you're 
probably over-generalising. 


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

That's good evidence that you've over-generalised.



-- 
Steven



More information about the Python-list mailing list