[Python-ideas] String formatting and namedtuple

[Talin]

Some reactions:

First, let me say that PEP 3101 was always meant to be an expression of 
the python-dev consensus rather than the ideas of one specific person. 
So as far as I am concerned, the consensus rules.

That being said, I can think of two objections to your proposal, 
although I don't feel strongly about either one.

The first issue is that the character sequence '{}' isn't by itself 
suggestive of anything (except perhaps an empty dict.) The logical 
extrapolation from {ddd} to {} is a subtractive one, meaning that it 
only makes sense if you are starting from {ddd} to begin with. From a 
pedagogical perspective, I have a slight preference for language 
constructs that are naturally additive, meaning that I can teach the 
shortcut first and it makes intuitive sense. (However, there are lots of 
language features that violate that rule, which is why this argument is 
somewhat weak.)

Secondly, there is an argument to be made towards moving away from any 
syntactical pattern that requires the programmer to synchronize two 
lists, in this case the set of '%' field markers in the string and the 
sequence of replacement values. Having to maintain a correspondence 
between lists is almost never a problem when code is first written, but 
I think we can all remember instances where bugs have been introduced by 
maintainers who added a new item to one list but forgot to add the 
corresponding item to the other list.

More generally, I think that when you evaluate the goodness of either 
syntax, you should do so from the perspective of both the original code 
author as well as someone who is dealing with an existing code base that 
has undergone a large degree of churn.

Thus, a case could be made that by forcing programmers to explicitly 
state the mapping between field marker and replacement value (either 
numerically, or preferably by name) that the code becomes a fraction 
more robust as a result.

BTW, although the use of unbound methods is not mentioned in the PEP, I 
do recall discussions on the mailing list around that time that proposed 
a whole lot of different ways of wrapping format() to create various 
formatting APIs.

Terry Reedy wrote:
> Steven D'Aprano wrote:
>> Terry Reedy wrote:
>>
>>> PROPOSAL: Allow the simple case to stay simple.  Allow field names to 
>>> be omitted for all fields in a string and then default to 0, 1, ... 
>>> so that example above could be written as
>>>
>>>  >>> msg = "{} == {}".format
>>>
>>> Given that computers are glorified counting machines, it *is* a bit 
>>> annoying to be required to do the counting manually.  I think this is 
>>> at least half the objection to switching to .format.
>>
>> +1 from me. Just to make it explicit: omitting field names will be an 
>> all-or-nothing proposition: you can't omit some of them unless you 
>> omit them all. Correct?
> 
> That is my proposal.  I should have made that clearer, as I now did on 
> the tracker issue I filed.  My idea was that the function could switch 
> from current behavior to alternative behavior depending on the presence 
> or absence of anything in the first {}.  But that is up to the patch 
> writer.
> 
> tjr
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>