[stdlib-sig] Evolving the Standard Library

[Armin Ronacher]

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