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@python.org http://mail.python.org/mailman/listinfo/python-ideas