Movatterモバイル変換
[0]ホーム
[Python-Dev] Status regarding Old vs. Advanced String Formating
Nick Coghlanncoghlan at gmail.com
Sat Feb 25 07:21:56 CET 2012
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 haveto worry if: fmt % argshould 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-styleformatting), and most of the rest are either using field references orjust {:number_spec} (where the number formatting is the same as thatin printf-style) the complexity of the full mini-language doesn'treally come into play (although I did find use recently for several ofthe features in order to emit nicely formatted data from a commandline utility).Another *very* handy trick is "{0.attr} {0.attr2}" for conciseattribute formatting.Really, what the new-style formatting is most lacking is a tutorial orcookbook 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 thesame argument more than once ("{0}")- here's how to name your fields so you can use keyword arguments orformat_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() onlocals() 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 strftimeAnd in a more advanced section:- here's how to use __format__() to customise the formatting optionsfor your own class- here's how to use string.StringFormatter to create a customformatting variant (e.g. one that invokes shlex.quote() oninterpolated variables by default)Currently we point them directly at the relevant section of the*language spec*, which is written for people trying to createcompliant formatting implementations, not anyone that just wants to*use* the thing.However, while I'm personally a fan of the new format() methods andgreatly prefer them to the old way of doing things, I agree it wouldbe a bad idea to try to *force* people to switch if they're used toprintf-style formatting and don't have any issues with it(particularly given the current expert-friendly state of thedocumentation). It's not like printf-style formatting is a securityrisk or poses some kind of huge maintenance burden. I see it assimilar to the getopt/optparse/argparse situation. getopt() has valuefor consistency with C's getopt() API, argparse is the currentrecommended best practice, while optparse is kept around because it isso prevalent that it isn't worth trying to remove it. Similarly,printf-style formatting has value for its consistency with C anddeserves to be kept around due to both that and its currentprevalence.Cheers,Nick.-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭