Issue 6081: format string using mapping rather than kwargs
Hello everyone, I was told to bring this issue to python-dev, but I was reluctant to do this until I was confident I can solve the problem. I have managed to provide the patch that works, so now I can talk about how this should be done, just as Eric told me. Here is the link to the ticket: http://bugs.python.org/issue6081. In the issue Raymond Hettinger proposed adding method to string, that would allow to explicitly pass subscriptable object, from which formatting of a string would be done. Two questions arise: 1) whether add such functionality at all? 2) how the method should be called? Should formatting options based on *args be kept (like using {0} in formatted string) or not and how argument should be passed. Eric suggested passing only mapping and only adding *args, if that is found useful by users; I have though about having both mapping and *args, which would keep it similar to the old formatting. Another option is to have *args and one keyword with the mapping (instead of kwargs). I would appreciate any advice on this topic, even if this ticket would be dismissed altogether, as I would like to learn as much as possible on practices on developing Python. -- Filip Gruszczyński
Filip Gruszczyński wrote:
I would appreciate any advice on this topic, even if this ticket would be dismissed altogether, as I would like to learn as much as possible on practices on developing Python.
Raymond's use case is valid, but the currently proposed method name is way too long to be usable and the use of *args is a definite misfeature. I suggest approaching the issue with the exact spec needed to cover the problem Raymond described: Add a method to strings that allows a format string to be applied to an existing mapping without implicitly converting the mapping to a dict first.
From that spec, a straightforward API falls out:
def format_mapping(self, kwds): # Method body actually written in C, so it can # easily invoke the internal formatting operation return do_string_format(self, NULL, kwds) Sure, you can't mix positional and keyword arguments the way you can with .format(), but you can't mix and match those with mod-formatting either. *If* support for a sequence were to be added (and that's a big if), it should be added as an explicit second argument, not as a *args argument. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
From that spec, a straightforward API falls out:
def format_mapping(self, kwds): # Method body actually written in C, so it can # easily invoke the internal formatting operation return do_string_format(self, NULL, kwds)
Thanks a lot for the advice, I'll provide according patch hopefully in the few days. -- Filip Gruszczyński
Filip Gruszczyński wrote:
From that spec, a straightforward API falls out:
def format_mapping(self, kwds): # Method body actually written in C, so it can # easily invoke the internal formatting operation return do_string_format(self, NULL, kwds)
Thanks a lot for the advice, I'll provide according patch hopefully in the few days.
I think this is basically my patch, with the method renamed, and needing tests.
Nick Coghlan wrote:
Filip Gruszczyński wrote:
I would appreciate any advice on this topic, even if this ticket would be dismissed altogether, as I would like to learn as much as possible on practices on developing Python.
Raymond's use case is valid, but the currently proposed method name is way too long to be usable and the use of *args is a definite misfeature.
I suggest approaching the issue with the exact spec needed to cover the problem Raymond described:
Add a method to strings that allows a format string to be applied to an existing mapping without implicitly converting the mapping to a dict first.
It occurs to me that Raymond's use case could be satisfied using existing Python, by slightly changing the format string. After all, str.format() supports mapping lookup already: $ ./python.exe Python 2.6.5+ (release26-maint:79421, Mar 25 2010, 08:51:39) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin Type "help", "copyright", "credits" or "license" for more information.
class Default(dict): ... def __missing__(self, key): ... return key ... s = '{m[name]} was born in {m[country]}' s.format(m=Default(name='Guido')) 'Guido was born in country'
Considering that, maybe the best thing is to do nothing. I'll update the issue with this note. -- Eric.
Eric Smith wrote:
Considering that, maybe the best thing is to do nothing. I'll update the issue with this note.
I agree this slightly weakens the case for change, but it's not really the same thing. Adding a "format_mapping" method allows an arbitrary mapping to be used with any keyword-based format string. Crafting a special format string in order to use an arbitrary mapping means that the same format string can no longer be used with an ordinary keyword based call - you have to do "format(m=dict(name=y, country=z))" instead. Moving the decision of "how am I going to be called" to the time of writing the format string is a bit odd. On the other hand, the specially crafted format string does have the virtue of travelling far more easily through any APIs that wrap the basic format() method (since it doesn't need special treatment to make its way through the wrapping code). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
Moving the decision of "how am I going to be called" to the time of writing the format string is a bit odd.
On the other hand, the specially crafted format string does have the virtue of travelling far more easily through any APIs that wrap the basic format() method (since it doesn't need special treatment to make its way through the wrapping code).
Completely agree on all points. Now we're just left with "is it worth expanding the str api for this?". I don't feel strongly either way. -- Eric.
Eric Smith wrote:
Nick Coghlan wrote:
Moving the decision of "how am I going to be called" to the time of writing the format string is a bit odd.
On the other hand, the specially crafted format string does have the virtue of travelling far more easily through any APIs that wrap the basic format() method (since it doesn't need special treatment to make its way through the wrapping code).
Completely agree on all points. Now we're just left with "is it worth expanding the str api for this?". I don't feel strongly either way.
For something as core as the string API, we better feel darn strongly about it before we mess with it :) I'm inclined to leave it alone unless/until Raymond or somebody else steps up to really champion it. Cheers, Nick. P.S. There's also the language moratorium to consider - since this idea affect the methods of a builtin type, I believe the moratorium applies. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan <ncoghlan <at> gmail.com> writes:
For something as core as the string API, we better feel darn strongly about it before we mess with it :)
Having two very similar methods with different names and subtly different APIs sounds bad IMHO. Also, the use case doesn't look very strong to me.
P.S. There's also the language moratorium to consider - since this idea affect the methods of a builtin type, I believe the moratorium applies.
So do I. Regards Antoine.
Nick Coghlan wrote:
Completely agree on all points. Now we're just left with "is it worth expanding the str api for this?". I don't feel strongly either way.
For something as core as the string API, we better feel darn strongly about it before we mess with it :)
I'm inclined to leave it alone unless/until Raymond or somebody else steps up to really champion it.
I'm okay with that.
P.S. There's also the language moratorium to consider - since this idea affect the methods of a builtin type, I believe the moratorium applies.
I don't think there's any effort to get this in before the moratorium expires. Eric.
I'm inclined to leave it alone unless/until Raymond or somebody else steps up to really champion it.
I'm okay with that.
And I am looking for another bug, that I could get some python-fu from ;-) -- Filip Gruszczyński
participants (4)
-
Antoine Pitrou -
Eric Smith -
Filip Gruszczyński -
Nick Coghlan