Re: [Python-Dev] summary of transitioning from % to {} formatting
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 to use
alternative formatting systems with logging?
That would probably be a good idea.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 that keeping string.Template around is valid due to its focus on
being very simple to use (especially for non-coders producing
translation templates)
However, string.Template is already set up to work for the relevant APIs
in that domain so I don't think it will really be affected by any
changes to the underlying language and library support for brace
formatting.
What if you wanted to translate log messages? Printing to a StringIO
first really isn't a very good solution.
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).
(Although printing to a String IO doesn't seem necessary - simply
pre-formatting the message seems like it should work, just as
preformatting brace formatted messages already works today).
The idea of adding an optional fmt_style callable to these APIs
(defaulting to None, which would imply the use of the mod operator) is
becoming more appealing...
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 necessary - simply pre-formatting the message seems like it should work, just as preformatting brace formatted messages already works today). Yep. :) The idea of adding an optional fmt_style callable to these APIs (defaulting to None, which would imply the use of the mod operator) is becoming more appealing... -Barry PGP.sig Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] summary of transitioning from % to { } formatting
Nick Coghlan ncoghlan at 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-dates
string.Template, but it can be made to work without too much trouble:
(a) Subclass Formatter to use $-formatting instead of %-formatting for e.g. the
lines written to log files, and
(b) Use a class like DollarMessage which I mentioned elsewhere in this thread,
to format logging call format strings and arguments.
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 to use
alternative formatting systems with logging?
Regards,
Vinay Sajip
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 use (especially for non-coders producing
translation templates)
However, string.Template is already set up to work for the relevant APIs
in that domain so I don't think it will really be affected by any
changes to the underlying language and library support for brace formatting.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 suspect any API transitions are going to be too much hassle to be worthwhile. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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* %
formatting in those APIs. But % formatting on strings themselves is
not directly being discussed here.
Actually, I think percent formatting and brace formatting should remain
fully supported peers for the life of 3.x (including in APIs such as
argparse and logging).
No matter how much we might like the new formatting system (and I
certainly prefer it), there's a long period of evangelisation and
performance improvements that needs to happen before we can
realistically start to deprecate percent formatting based APIs in any
way shape or form.
Until that happens, then users do have the right to dig in their heels
and say look, the limitations on percent formatting really don't bother
us, certainly not enough to switch to a new formatting system.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
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
[Python-Dev] summary of transitioning from % to {} formatting
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.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__({asctime} - {name}))
The API code wouldn't have to change at all at first, as applying
% to brace_fmt objects would call .format() instead. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring brace_fmt strings, and
then allowing plain strings again but assuming they are {}-format
strings.
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt={asctime} - {name}.format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring callables, and then
allowing plain strings again but assuming they are {}-format
strings
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
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 {}-formatting if it fails?
I don't think there is consensus yet on which of these proposals
should be the blessed one.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
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
Re: [Python-Dev] summary of transitioning from % to { } formatting
Steven Bethard steven.bethard at 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 {}-formatting if it fails?
This would be a reasonable heuristic. It should be done only on the first call,
though, and then the result remembered (for both performance reasons and
consistency).
The cases where a format string would function in both formatting styles and
expect the same parameters must be very rare in the real world.
Regards
Antoine.
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
2009/10/3 Antoine Pitrou solip...@pitrou.net:
Steven Bethard steven.bethard at 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 {}-formatting if it fails?
This would be a reasonable heuristic. It should be done only on the first
call,
though, and then the result remembered (for both performance reasons and
consistency).
The cases where a format string would function in both formatting styles and
expect the same parameters must be very rare in the real world.
Define fails:
{a} {b} c % {'a':12}
'{a} {b} c'
That didn't fail...
Paul.
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
On Sat, 3 Oct 2009 at 17:08, Paul Moore wrote:
2009/10/3 Antoine Pitrou solip...@pitrou.net:
Steven Bethard steven.bethard at 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 {}-formatting if it fails?
This would be a reasonable heuristic. It should be done only on the first call,
though, and then the result remembered (for both performance reasons and
consistency).
The cases where a format string would function in both formatting styles and
expect the same parameters must be very rare in the real world.
Define fails:
{a} {b} c % {'a':12}
'{a} {b} c'
That didn't fail...
Also, what if both fail? Which failure's error message gets printed?
--David (RDM)___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 pairs of braces, and try first the
formatting style expecting the greatest number of parameters. It can
either be done cheaply in Python, or more rigourously by providing an
extra API to the existing C parsing routines.
This might look fragile, but we should not forget that we are talking
about uses - logging, etc. - which will most of time involve very simple
format strings, such that making an automatic decision is not too
difficult. In the more undecideable cases, the heuristic might decide to
raise an exception and require the developer to specify the formatting
style explicitly (by adding e.g. style='%' or style='{}' to the method
call).
Regards
Antoine.
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
I'd like to at least keep in mind $-strings. I don't have any
experience with {}-strings w.r.t. i18n translators, but I'm very
confident that $-strings are better for translators than %-strings.
OT1H {}-strings don't suffer from the #1 problem of %-strings: leaving
off the trailing 's' or whatever. OTOH, I suspect that $-strings are
still easier for the simple substitution case; for example, it's
conceivable that translators may forget the trailing close brace.
Since we're likely to have multiple formatting styles at least for
Python 3's lifetime, I'd like any solution we come up with to at least
not preclude the use of $-strings.
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.
-Barry
PGP.sig
Description: This is a digitally signed message part
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard steven.beth...@gmail.com 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 the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
+1.
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__({asctime} - {name}))
The API code wouldn't have to change at all at first, as applying
% to brace_fmt objects would call .format() instead. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring brace_fmt strings, and
then allowing plain strings again but assuming they are {}-format
strings.
Uurgh. This just feels... icky. A badly-rationalized -1 from me.
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt={asctime} - {name}.format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring callables, and then
allowing plain strings again but assuming they are {}-format
strings
+0.5. Seems like it could work, but the first solution feels
cleaner.
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
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 {}-formatting if it fails?
I'm reserving judgement on this one until it becomes clear how
feasible it is. Without having thought about it too hard, this sounds
potentially tricky and bug-prone.
Mark
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__({asctime} - {name}))
The API code wouldn't have to change at all at first, as applying
% to brace_fmt objects would call .format() instead. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring brace_fmt strings, and
then allowing plain strings again but assuming they are {}-format
strings.
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt={asctime} - {name}.format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring callables, and then
allowing plain strings again but assuming they are {}-format
strings
I'm not keen on deprecating strings in favour of callables and then
callables in favour of strings.
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
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 {}-formatting if it fails?
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. There could also be a
format-guesser method.
I don't think there is consensus yet on which of these proposals
should be the blessed one.
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
Mark Dickinson wrote:
On Sat, Oct 3, 2009 at 4:41 PM, Steven Bethard steven.beth...@gmail.com 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 the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
+1.
[snip]
'fmt' (which is an abbreviation for 'format') and 'format'? Maybe 'fmt'
and 'style' instead?
___
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
Re: [Python-Dev] summary of transitioning from % to { } formatting
MRAB python at 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. There could also be a format-guesser method. I'm sorry to say this, but I think these suggestions are getting foolish. We core developers might have an interest in transitioning users from one formatting style to another, but the users mostly don't care and don't want to bother. Imposing on users the explicit use of such wrapper classes, moreover with such awfully long-winded names, is not helpful to them at all, and it will earn Python the reputation of a language which imposes silly constructs in the name of purity. If we can't find a way to make things almost transparent, we should IMO abandon the whole idea of a transition. Regards Antoine. ___ 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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 only %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
Why is this a problem? Is it because the APIs require extra
functionality that only {} formatting can provide? Possibly, but I
doubt it -- I expect that the reason is:
(1) Some people would like to deprecate % formatting, and they can't
while the std lib uses % internally.
(2) Some APIs in the std lib are tightly coupled to their internal
implementation, and so you can't change their implementation without
changing the API as well.
Remove either of these issues, and the problem becomes a non-problem,
and no action is needed. Personally, I'd like to see no further talk
about deprecating % until at least Python 3.2, that is, the *earliest*
we would need to solve this issue would be 3.3. As the Zen
says, Although never is often better than *right* now.
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4).
-1 on that. Time will tell if I change my mind in a couple of years, but
I suspect not -- for simple formatting, I far prefer %. Judging by the
reaction on comp.lang.python when this has been discussed in the past,
I think a large (or at least loud) proportion of Python programmers
agree with me.
There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
+0.5
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__({asctime} - {name}))
There are a few problems with this approach:
- Nobody has yet demonstrated that this brace_fmt class is even
possible. It should be easy to handle a restricted set of simple
templates (e.g. of the form %(name)s only), but what of the full
range of behaviour supported by % formatting?
- Even if it is doable, it is a wrapper class, which means the module
will suffer a performance hit on every call. At this time, we have no
idea what the magnitude of that hit will be, but .format() is already
slower than % so it will likely be significant.
- It strikes me as hideously ugly. I for one would delay using it as
long as possible, no matter how many DepreciationWarnings I got. I'd
drag my feet and avoid changing and complain loudly and then become
sullen and resentful when I couldn't avoid making the change. I'd much
rather go straight from %-based templates to {} in a single step than
have this Frankenstein monster intermediate.
[...]
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt={asctime} - {name}.format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string.
+0.5
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
+1, assuming such translators are even possible. Being optimistic, such
translators would have one additional benefit: they would enable
modules to completely decouple the API they offer from their internal
implementation, without paying a runtime cost on every call, just a
single once-off translation at initialisation time.
In theory, this could mean that modules could, if they choose, continue
to offer an API based on % long after str.__mod__ is removed from the
language.
--
Steven D'Aprano
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
On Sat, Oct 3, 2009 at 11:01, Steven D'Aprano st...@pearwood.info 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 many APIs in the standard library and
elsewhere support only %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
Why is this a problem? Is it because the APIs require extra
functionality that only {} formatting can provide? Possibly, but I
doubt it -- I expect that the reason is:
(1) Some people would like to deprecate % formatting, and they can't
while the std lib uses % internally.
(2) Some APIs in the std lib are tightly coupled to their internal
implementation, and so you can't change their implementation without
changing the API as well.
Remove either of these issues, and the problem becomes a non-problem,
and no action is needed. Personally, I'd like to see no further talk
about deprecating % until at least Python 3.2, that is, the *earliest*
we would need to solve this issue would be 3.3. As the Zen
says, Although never is often better than *right* now.
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* %
formatting in those APIs. But % formatting on strings themselves is
not directly being discussed here.
-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
Re: [Python-Dev] summary of transitioning from % to {} formatting
Antoine Pitrou wrote: MRAB python at 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. There could also be a format-guesser method. I'm sorry to say this, but I think these suggestions are getting foolish. We core developers might have an interest in transitioning users from one formatting style to another, but the users mostly don't care and don't want to bother. Imposing on users the explicit use of such wrapper classes, moreover with such awfully long-winded names, is not helpful to them at all, and it will earn Python the reputation of a language which imposes silly constructs in the name of purity. Fair enough. The purpose of the post was really just so that we cover as many possibilities as we can so that if at some time in the future someone asks why we didn't consider such-and-such then we won't be saying Oh, never thought of that!. :-) If we can't find a way to make things almost transparent, we should IMO abandon the whole idea of a transition. ___ 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
Re: [Python-Dev] summary of transitioning from % to { } formatting
Brett Cannon brett at 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 *using* %
formatting in those APIs. But % formatting on strings themselves is
not directly being discussed here.
While I have no problem with supporting {}-formatting in logging if we find a
good way of doing it, one thing that bothers me about transitioning the logging
API to deprecate or otherwise de-emphasise %-formatting is the question of
performance. Now, str.format is more flexible than str.__mod__ and so some
performance loss may be tolerable in many scenarios. However, in the feedback I
regularly get about logging, people are concerned about performance. No-one ever
comes up with any hard numbers, but logging is often bashed as slow (see e.g.
Andrii Mishkovskyi's LoggingPackage page on the Python wiki). I don't especially
want to add fuel to the fire, as any performance degradation caused by
supporting {}-formatting will likely just result in more finger-pointing at
logging in general.
Regards,
Vinay Sajip
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
...
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
How about combining these two. Add an optional form or style=xxx
parameter -- which could also allow DOLLARS for $-formats -- for
resolving ambiguities. If not present, make a reasonable guess. IE, if
string has no '%' and multiple {} pairs, or no {} pairs and multiple %s,
the guess is at least .999 sure. which is to not, not hardly a guess.
The extra arg can be supplied if and when needed.
The machinery for this should be not be logging specific, so it can be
used through throughout the library, and exposed so that others can use it.
Terry Jan Reedy
___
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
Re: [Python-Dev] summary of transitioning from % to {} formatting
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 %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt=%(asctime)s - %(name)s)
but not::
logging.Formatter(fmt={asctime} - {name})
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt={asctime} - {name}, format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
...
* Create translators between %-format and {}-format::
assert to_braces(%(asctime)s) == {asctime}
assert to_percents({asctime}) == %(asctime)s
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents({asctime} - {name}))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt={asctime} - {name})
How about combining these two. Add an optional form or style=xxx
parameter -- which could also allow DOLLARS for $-formats -- for
resolving ambiguities. If not present, make a reasonable guess. IE, if
string has no '%' and multiple {} pairs, or no {} pairs and multiple %s,
the guess is at least .999 sure. which is to not, not hardly a guess.
The extra arg can be supplied if and when needed.
Maybe if the style is a callable then that's the formatting function?
(Or is that asking for trouble? :-))
In that case the style could default to a function which guesses which
style is being used and then the appropriate function.
The machinery for this should be not be logging specific, so it can be
used through throughout the library, and exposed so that others can use it.
___
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
