[Python-Dev] Status regarding Old vs. Advanced String Formating (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sat Feb 25 07:21:56 CET 2012
- Previous message: [Python-Dev] Status regarding Old vs. Advanced String Formating
- Next message: [Python-Dev] Status regarding Old vs. Advanced String Formating
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Feb 25, 2012 at 10:20 AM, <martin at v.loewis.de> wrote:
I find the .format syntax too complicated and difficult to learn. It has so many bells and whistles, making it more than just a mini language. So for my own code, I always prefer % formatting for simplicity.
Heh, I've switched almost entirely to .format() just so I never have to worry if:
fmt % arg
should actually be written as:
fmt % (arg,)
With fmt.format(arg), the question just never comes up.
Since 90%+ of the replacement field specifiers I use are just "{}" or "{!r}" (the format-style equivalents to "%s" and "%r" in printf-style formatting), and most of the rest are either using field references or just {:number_spec} (where the number formatting is the same as that in printf-style) the complexity of the full mini-language doesn't really come into play (although I did find use recently for several of the features in order to emit nicely formatted data from a command line utility).
Another very handy trick is "{0.attr} {0.attr2}" for concise attribute formatting.
Really, what the new-style formatting is most lacking is a tutorial or cookbook style reference to teach people things like:
- here's how to do basic string interpolation ("{}")
- here's how to use repr() or ascii() instead of str() ("{!r}", "{!a}")
- here's how to explicit number your fields so you can refer to the same argument more than once ("{0}")
- here's how to name your fields so you can use keyword arguments or format_map()
- here's how to access attributes of an object being formatted
- here's how to access individual items in a container being formatted
- here's how to do implicit string interpolation with format_map() on locals() or vars(obj)
- here's how to align (and/or truncate) text within a field
- here's how to format numbers
- here's how to implicitly invoke strftime
And in a more advanced section:
- here's how to use format() to customise the formatting options for your own class
- here's how to use string.StringFormatter to create a custom formatting variant (e.g. one that invokes shlex.quote() on interpolated variables by default)
Currently we point them directly at the relevant section of the language spec, which is written for people trying to create compliant formatting implementations, not anyone that just wants to use the thing.
However, while I'm personally a fan of the new format() methods and greatly prefer them to the old way of doing things, I agree it would be a bad idea to try to force people to switch if they're used to printf-style formatting and don't have any issues with it (particularly given the current expert-friendly state of the documentation). It's not like printf-style formatting is a security risk or poses some kind of huge maintenance burden. I see it as similar to the getopt/optparse/argparse situation. getopt() has value for consistency with C's getopt() API, argparse is the current recommended best practice, while optparse is kept around because it is so prevalent that it isn't worth trying to remove it. Similarly, printf-style formatting has value for its consistency with C and deserves to be kept around due to both that and its current prevalence.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Status regarding Old vs. Advanced String Formating
- Next message: [Python-Dev] Status regarding Old vs. Advanced String Formating
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]