Eric Smith wrote: > I like approach 2 in general. I'll give some thought to other, similar > schemes which would allow "8," or "8,d" to work. I think people will > write "8," and expect " 1,234", not an error.
Given that PEP 3101 deliberately exposed the underlying Formatter class to support more flexible expansions to formatting, I think trying to build that level of flexibility into the formatting mini-language itself would be a mistake. So step 1 would be to add the "," or "'" to the format string to indicate the use of separators. While both violate the rule of syntax not looking like grit on Tim's monitor, the latter has the virtues of not only being harder to confuse with a period, but also being consistent with the printf() grouping flag as defined in the Single Unix Specification v2 (as noted by JYK earlier in the thread and described in more detail at [1]). Then step 2 (if deemed appropriate) would be to expose the mini-language parser in a way that makes it easier to write a custom format_field() method in a Formatter subclass without having to completely duplicate the existing parser's functionality. Step 1 makes sense even if step 2 is never taken. Step 2 also makes sense even if step 1 is never taken. So I don't think the fact that step 2 is probably a good idea should be used to hold up PEP 378, nor do I think PEP 378 should be complicated by locale related issues that are better handled by making it easier to write a custom format_field() method in a Formatter subclass. Cheers, Nick. [1] http://linux.die.net/man/3/printf P.S. This post is really just an elaboration of this comment from JYK: """I'm not against Raymond's proposal, just against doing a *bad* job of making it work in multiple locales. Locale conventions can be complex, and are going to be best represented outside the format string.""" -- 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