Vinay Sajip wrote:
> Both of these approaches will also work for {}-formatting. The present thread
> really started out with a view to suggesting that the stdlib start adopting
> {}-format as "native", rather than %-format.
>
> Would it be helpful if I added a section to the Python docs about how
Barry Warsaw wrote:
> I also don't think this is a case of anti-TOOWTDI. For most situations
> {}-strings are great (IMO), but in the specific translation domain, I
> suspect $-strings are still better.
I agree that keeping string.Template around is valid due to its focus on
being very simple to
Nick Coghlan gmail.com> writes:
> Oh, I see what you meant now - you were pointing out that lazy
> formatting APIs (such as logging) already don't work properly for
> alternative formatting mechanisms (such as string.Template).
>
Logging doesn't work automatically with string.Template as it pre
On Oct 5, 2009, at 4:41 PM, Nick Coghlan wrote:
Oh, I see what you meant now - you were pointing out that lazy
formatting APIs (such as logging) already don't work properly for
alternative formatting mechanisms (such as string.Template).
Yep.
(Although printing to a String IO doesn't seem ne
Barry Warsaw wrote:
> On Oct 4, 2009, at 4:11 AM, Nick Coghlan wrote:
>
>> Barry Warsaw wrote:
>>> I also don't think this is a case of anti-TOOWTDI. For most situations
>>> {}-strings are great (IMO), but in the specific translation domain, I
>>> suspect $-strings are still better.
>>
>> I agree
On Oct 4, 2009, at 4:11 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I also don't think this is a case of anti-TOOWTDI. For most
situations
{}-strings are great (IMO), but in the specific translation domain, I
suspect $-strings are still better.
I agree that keeping string.Template around i
Brett Cannon wrote:
> No one is saying we should deprecate % any time soon on strings
> themselves or anywhere. This discussion is purely in regards to
> argparse and logging to transition *their* APIs over to {} formatting
> which would most likely involve some deprecation for *using* %
> formatti
Antoine Pitrou wrote:
> If we can't find a way to make things almost transparent, we should IMO
> abandon
> the whole idea of a transition.
Yep - this is the reason some attempts at actual format translation
implementations started up as a result of the previous discussion.
Without that, I suspec
Terry Reedy wrote:
Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
definitely
The basic problem is that many APIs in the standard library and
elsewhere support only %-
Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
definitely
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {
Brett Cannon python.org> writes:
> No one is saying we should deprecate % any time soon on strings
> themselves or anywhere. This discussion is purely in regards to
> argparse and logging to transition *their* APIs over to {} formatting
> which would most likely involve some deprecation for *usin
Antoine Pitrou wrote:
MRAB mrabarnett.plus.com> writes:
Another possibility:
A StringFormat class with subclasses PercentStringFormat,
BraceStringFormat, and perhaps DollarStringFormat.
Or:
A StringFormat class with methods parse_percent_format,
parse_brace_format, and parse_dollar_format
On Sat, Oct 3, 2009 at 11:01, Steven D'Aprano wrote:
> On Sun, 4 Oct 2009 01:41:36 am Steven Bethard wrote:
>> I thought it might be useful for those who don't have time to read a
>> million posts to have a summary of what's happened in the formatting
>> discussion.
>>
>> The basic problem is that
On Sun, 4 Oct 2009 01:41:36 am Steven Bethard wrote:
> I thought it might be useful for those who don't have time to read a
> million posts to have a summary of what's happened in the formatting
> discussion.
>
> The basic problem is that many APIs in the standard library and
> elsewhere support on
MRAB mrabarnett.plus.com> writes:
>
> Another possibility:
>
> A StringFormat class with subclasses PercentStringFormat,
> BraceStringFormat, and perhaps DollarStringFormat.
>
> Or:
>
> A StringFormat class with methods parse_percent_format,
> parse_brace_format, and parse_dollar_format. Ther
Mark Dickinson wrote:
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
Definitely useful. Thanks for the summary!
[...]
* Add a parame
Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {}-formatting, e
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard wrote:
> I thought it might be useful for those who don't have time to read a
> million posts to have a summary of what's happened in the formatting
> discussion.
Definitely useful. Thanks for the summary!
[...]
> * Add a parameter which declares
On Oct 3, 2009, at 11:41 AM, Steven Bethard wrote:
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-forma
> Define "fails":
>
> >>> "{a} {b} c" % {'a':12}
> '{a} {b} c'
>
> That didn't fail...
Ah, my bad. I had completely overlooked that formatting was laxist when
faced with unused named parameters.
Then we need something smarter, like counting the number of unescaped
"%" characters, the number of
On Sat, 3 Oct 2009 at 17:08, Paul Moore wrote:
2009/10/3 Antoine Pitrou :
Steven Bethard gmail.com> writes:
? If %-formatting is to be deprecated, the transition strategy here
? is trivial. However, no one has yet written translators, and it is
? not clear what heuristics should be used, e.g.
2009/10/3 Antoine Pitrou :
> Steven Bethard gmail.com> writes:
>>
>> If %-formatting is to be deprecated, the transition strategy here
>> is trivial. However, no one has yet written translators, and it is
>> not clear what heuristics should be used, e.g. should the method
>> just try %-for
Steven Bethard gmail.com> writes:
>
> If %-formatting is to be deprecated, the transition strategy here
> is trivial. However, no one has yet written translators, and it is
> not clear what heuristics should be used, e.g. should the method
> just try %-formatting first and then {}-formatt
23 matches
Mail list logo
