From: Don A. <do...@gr...> - 2008-02-20 16:57:14
|
On Wed, 2008-02-20 at 16:46 +0000, Richard Taylor wrote: > Hi Don!, I had to read back through the ML archive to discover where you > had gone. I hope that all is well with you and the family. Yeah, I had to back off. After 6.5 years, the daily work was getting to be too much for me. Add to that a new job that is consuming a lot of time, and I had to step down. Fortunately, the project is doing just fine (actually, probably better) without me. > > > > If the answer is Yes (which I hope it is), then we need to take a more > > serious look at things - and not just for this particular problem. The > > real issue is reducing the intermingling of these classes. > > > > I hope so too, but I would understand entirely if the current developers > felt otherwise. There is always some overhead in supporting other > projects with shared code. In my personal opinion, writing code this way is almost always the right thing to do. It just leads to cleaner, easier to maintain code. > > > Richard's suggestion is a cool python trick that allows him to use the > > Date module even if the Config module fails to import. However, if we > > are designing reusable modules, then this is really only a hack. > > Reusable modules should have as few dependencies between them as > > possible, and should not require funky hacks. > > > > Ouch, I think that hurt :-) But I do agree, I was just looking for a > quick fix that would scratch my itch. A considered policy decision is a > much better approach. > Please don't take it as an insult. The solution as brilliant, and I actually learned more about python by looking at the example. For what you were trying to do (impact the project as little as possible, yet make it work for you and possibly others), it was really cool. The point I was trying to make is that I would recommend that the project take a step back and consciously try to solve the problem from an architectural view instead of using a specific workaround. Don |