A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-October/092464.html below:

[Python-Dev] transitioning from % to {} formatting

[Python-Dev] transitioning from % to {} formattingJames Y Knight foom at fuhm.net
Fri Oct 2 00:03:47 CEST 2009
On Oct 1, 2009, at 5:54 PM, Nick Coghlan wrote:
> 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. (Naming
> the three major string formatting techniques by the key symbols  
> involved
> is a really good idea though)
>
> 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__).

Using containment instead of inheritance makes sure none of the  
*other* operations people do on strings will appear to work, at least  
(substring, contains, etc). I bet explicitly calling str() on a format  
string is even more rare than attempting to do those things.

> 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')

True, but I don't think there's many such cases in the first place,  
and such places can be fixed to not do that as they're found.

Until they are fixed, fmt_braces will loudly fail when used with that  
API (assuming fmt_braces is not a subclass of str).

James
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4