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