
PyFormat – Using % and .format() for great good - avinassh
http://pyformat.info/
======
majke
Call me an old timer, but I struggle to understand what's the point of the new
format. Sure, it has more features. But is it worth the transition?

The old format is:

\- pretty compatible with C

\- therefore well documented, well understood by everyone

\- therefore somewhat portable

\- and most importantly - simple

\- allows for fast implementations

For more complex stuff in python I use the dict() format, and print variables
by name in dict, not by index. I find the new .format() more confusing. Or am
I just not used to it?

Update: I didn't mean to be negative. The documentation is awesome, I just
don't understand the broader point.

~~~
lfowles
> For more complex stuff in python I use the dict() format, and print
> variables by name in dict, not by index. I find the new .format() more
> confusing. Or am I just not used to it?

So, this is just a simpler way of doing that in the batteries included stdlib
then.

    
    
        "{var} for some reason I'm going to repeat this {var}".format(var="foo")
    

vs what I assume you are using

    
    
        "%s for some reason I'm going to repeat this %s" % (vars[var], vars[var])
    

(Skimming through the linked page now....)

Reordering is also powerful. Most of my string formatting is done for awful
awful uses of printf-debugging, so I could use something like your dictionary
to do

    
    
        "{var} failed to {cond}".format(**vars)
    

and later I want to reformat it, I just change the string, but don't have to
touch the format() arguments.

    
    
        "{cond} failed for {var}".format(**vars)

~~~
qt7
> So, this is just a simpler way of doing

Exactly. A simpler way of doing something which is already not that
challenging, adding some functionality that is not so great.

It seems pretty unexciting overall and switching is not that compelling, since
it requires more typing most of the times and the old formatting is not going
anywhere any time soon.

~~~
danudey
Explicit is better than implicit. We have a lot of older format strings (from
before .format()) that look like this:

"%s %s: Caught %s in %s (%s)"

As compared to:

"{date} {processname}: Caught {except_type} in {func} ({module})"

It's more typing, sure, but it's more typing once, and it makes it extremely
obvious what the string is going to look like and what each field is without
having to read the arguments.

Then using named parameters means you can easily see what's supposed to be
what:

% (ts, proc['name'], ex.type, fn, __name__)

versus:

.format(date=ts, processname=proc['name'], except_type=ex, func=fn,
module=__name__)

Lastly, it lets you make quick modifications to strings without having to deal
with inserting it at the correct place in a format string of 10 items. You can
add in a new field in the middle, at the start, or both, and be able to just
add newfield=var at the end of the format() call without having to insert it
the correct spot, or in multiple places. Also, removing variables from the
format string and not from the parameter list which removes a class of subtle,
annoying bugs that tend to be caught after deployment.

If you're looking for some major revolution as to why this is the demonstrably
better choice and will revolutionize how you put strings together, you won't
find it. What this offers is a lot of power, convenience, readability, and
maintainability in exchange for a negligible increase in typing.

~~~
majke
Sure, with old syntax you can do it as well:

>>> print('%(language)s has %(number)03d quote types.' %

... {'language': "Python", "number": 2})

------
PythonicAlpha
Good, that somebody tries to document that stuff better!

I am also very unhappy with the current documentation of this.

The new Python format is great and you can do so many things with it, but it
also just costs to much time to read the documentation and find some relevant
examples.

------
barely_stubbell
Additionally: [https://mkaz.com/2012/10/10/python-string-
format/](https://mkaz.com/2012/10/10/python-string-format/)

------
sctb
[https://news.ycombinator.com/item?id=9382055](https://news.ycombinator.com/item?id=9382055)

