PyFormat – Using % and .format() for great good(pyformat.info)
pyformat.info
PyFormat – Using % and .format() for great good
http://pyformat.info/
4 comments
> 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.
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
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")
"%s for some reason I'm going to repeat this %s" % (vars[var], vars[var])
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)
"{cond} failed for {var}".format(**vars)> 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.
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.
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.
"%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.
Sure, with old syntax you can do it as well:
>>> print('%(language)s has %(number)03d quote types.' %
... {'language': "Python", "number": 2})
>>> print('%(language)s has %(number)03d quote types.' %
... {'language': "Python", "number": 2})
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.
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.
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.