On Sat, Feb 25, 2012 at 10:20 AM, <mar...@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 | 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
