On Thu, Oct 1, 2009 at 14:54, Nick Coghlan <ncogh...@gmail.com> wrote:
> Vinay Sajip wrote:
>> So there's no need to change modules like logging to explicitly
>> provide support for {}-formatting? What's not to like? ;-) Something
>> like this perhaps should have been added in at the same time as
>> str.format went in.
>
> I believe classes like fmt_braces/fmt_dollar/fmt_percent will be part of
> a solution, but they aren't a complete solution on their own.
I agree. I view them more as a band-aid over APIs that only accept %
formatting but the user of the library wants to use {} formatting.
> (Naming
> the three major string formatting techniques by the key symbols involved
> is a really good idea though)
>
> The two major problems with them:
>
> 1. It's easy to inadvertently convert them back to normal strings. If a
> formatting API even calls "str" on the format string then we end up with
> a problem (and switching to containment instead of inheritance doesn't
> really help, since all objects implement __str__).
>
Well, you can override the methods on str to always return the proper
thing, e.g. ``def __str__(self): return self``. Do the same for
__add__() and all other methods on strings that return a string
themselves. It should be possible to prevent Python code from
stripping off the class.
> 2. They don't help with APIs that expect a percent-formatted string and
> do more with it than just pass it to str.__mod__ (e.g. inspecting it for
> particular values such as '%(asctime)s')
>
Nope, they don't and people would need to be warned against this.
> Still, it's worth considering adding the three fmt_* classes to the
> string module to see how far they can get us in adapting the formats for
> different APIs.
>
> Note that I don't think these concepts are fully baked yet, so we
> shouldn't do anything in a hurry - and anything that does happen should
> be via a PEP so we can flush out more issues.
Having a PEP that lays out how we think people should consider
transitioning their code would be good.
-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
