Hi, Vinay Sajip wrote: > Care to stop waving your arms about over general principles like > "shared state", and get down to specifics about logging? I was pointing out that a similar problem exists elsewhere. And you will never bring me to a point where I say something along the lines of "shared state is okay because we cannot avoid it".
> It *is* an attribute of the LogRecord, and always has been - not sure where > you get your "facts" ;-). s/attribute/property/ > I don't know, without knowing your problem in more detail, if you could have > avoided copying and changing code from LogRecord and Formatter. Obviously > I've tried to provide enough hooks so that people can subclass and override > methods for specific requirements, such as adding to a Trac ticket. If you > describe the problem in more detail, I may be able to indicate a better > solution. If it turns out that I need to provide more hooks where people can > override functionality, I'm open to doing that. It's in the standard library, modifications are not that useful. If I could pull an updated version from an external URL that adds these hooks, fine. But until then I can't use any of the modifications done in there because it has to be compatible Python 2.4. > So your complaint is really just a philosophical diatribe against shared > state? It's not philosophical, it's practical. > Then you're really saying something roughly like "It's Not Invented Here, so > I don't like it. The only way it could be better is if I had thought of it. > Period." I really don't know how to reply to that... > *cough* *cough*. I've already read that post, as I referred to it earlier in > this thread. Since sys.modules is shared state at a much more fundamental > level than logging's logger registry, why not focus your energies on getting > that changed first? If you're successful at pulling it off, it'll no doubt > lead to a whole slew of changes in the Python ecosystem, of which logging is > just a tiny part. I think you're missing something: I do not intent do change it. I complain about both logging and sys.modules because in my opinion those are broken by design. However there is also no way we could possibly change those, so I don't even try to think about solutions. Please acknowledge that. > There you go. Is Jinja2 "broken by design", then? For many people it certainly is. Also there are design decisions I made in Jinja2 early on that are certainly broken, such as the scoping and I try to fix those by adding deprecation warning for edge cases. However, you cannot do that in the standard library, different rules apply there. > Aso, I prefer Python to Ruby. Should I say "Ruby? Broken, by design"? I will just ignore that. > What, sarcasm now? From "broken by design" to "paragon of virtue, exemplar > to the world"? Please. I've been around the block a few times, no longer the > new kid, and my skin is reasonably thick. I'm not crying. But keep it > constructive (i.e. with improvement as a goal), that's all I'm asking. That was not sarcastic. > My point was not about whether Graham's plan was or was not the best. It's > that he wants to get *something* reasonable out there, knows the issues and > is frustrated with the constant back-and-forth between conflicting opinions. > We could be waiting forever for a resolution, what good is that to anybody? What good is a broken specification. It's not about changing the specification, it's about fixing it. And there is a lot of things that have to be thought through. I love Graham's efforts in changing it, but just deciding on one the proposals without thinking about the consequences it has is not very wise. Regards, Armin _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
