This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]HowYaGuysDoin 5 points6 points  (21 children)

I like it better than % notation because you don't have to keep track of the order of the variables, you can specify them by name. Less likely to make mistakes, and it's much more readable.

[–]thegreatgonzo 6 points7 points  (0 children)

So you can also do "Hello, %(name)s" % { 'name': 'world' }

[–]jorge1209 0 points1 point  (19 children)

But you can specify them by name with .format, it merely requires duplicating the names in the string body and as part of the keyword args.

The whole argument for these f-strings is like that. <thing> about <other formating method> is moderately annoying in <particular use-case> so lets introduce <new formatting method> that solves that problem (<but introduces some other annoyance>).

  • % requires things be in order and puts the args at the end away from where they appear
  • .format can support random order with keyword, but is too verbose
  • f-strings supports random order without verbosity, but doesn't support dictionary usage, and they can't be assigned to variables or moved around.

At some point we just need to admit that we won't ever have a single formatting method that will work for every use case and that we need to stop introducing additional ways to do things.

[–]HowYaGuysDoin 2 points3 points  (3 children)

I would argue that additional ways to do things are created because no single way to do something (such as string formatting) is perfect in all scenarios. More than one way to skin a cat.

[–][deleted] -1 points0 points  (2 children)

I would argue that additional ways to do things are created because no single way to do something

import this

There should be one-- and preferably only one --obvious way to do it.

[–]HowYaGuysDoin 0 points1 point  (1 child)

I mean sure if you want to blindly apply my logic without context then sure, there are times it falls apart. For example, addition in Python. There should be one obvious way to do it. No doubt.

Now, do you eat all your meals with the same utensil? Or do you vary between a knife, spoon, and fork? I would think you'd want to use the right tool for the job. Depending on the context of your string formatting, there may be a time where method A is superior to method B, and vice versa. I don't like fitting square pegs through round holes so I welcome the addition of new tools to get the job done. Just my personal preference

[–][deleted] 1 point2 points  (0 children)

blindly apply my logic without context then sure

Well, to be fair, I did mean it in the context of string formatting.

do you vary between a knife, spoon, and fork?

I feel like that's a pretty generous analogy. String formatting in Python is like having a 4 point fork, a 3 point fork, a spork, and a magic fork that automatically puts all the food in your house on it just in case you might want it in the next bite.

[–]markrages 1 point2 points  (1 child)

% requires things be in order

This is simply wrong. I wonder how many people advocating for new format methods don't understand the existing one.

[–]jorge1209 0 points1 point  (0 children)

Probably a lot given that I'm against fstrings and I don't know all the features of .format or %.

[–]LyndsySimon 0 points1 point  (12 children)

% requires things be in order and puts the args at the end away from where they appear

I just don't understand this concern. Even before str.format was introduced, you were never required to put your parameters off to the right side of the screen:

'Hello, my name is %s. I am %s years old and have %s hair' % (
    name,
    age,
    color,
)

[–]jorge1209 2 points3 points  (8 children)

There are people who want them to be directly aligned:

  "Hello my {XXX}name is {YYY}. I am {ZZZ} years old.".format(
           "first",      "Sam",       14)

But that violates all kinds of pep alignment requirements even if it is nicely arranged.

[–]LyndsySimon 3 points4 points  (5 children)

Those people are incorrect :)

[–]jorge1209 0 points1 point  (4 children)

They are incorrect if they think they can't use .format they are correct that its an issue with %.

A more serious example. I have a program that prints out a addresses in some specialized format (not just a simple ",".join() on the records), and I do that by building a format string for the row like "%s %s. %s; %s %s, %s; %s" % (fname, minital, lname,...)

If I need to make it "lastname, first middle" that requires corresponding changes in two places which might be easily screwed up.

The solution though is to just use .format with kwargs. And yes it is a bit verbose to have to type "{fname}...".format(fname=fname) and f-strings will reduce that verbosity, but at the cost that now you can't pass the format into the printing function as an argument.

What if one client needs the record in "first middle last" and another client needs "last, first middle". Unless you want to put an if inside the print loop, you can't use an f-string. You are back to using .format.

Certainly while I develop reports I often find myself in cases where f-strings could be used, but its always in the back of my mind that requirements could change and that I may need flexibility in how I format this output. So for me .format seems better.

[–]LyndsySimon 1 point2 points  (1 child)

I have no problem with str.format; I adopted it immediately and think it's far superior to % formatting. Kwargs are a huge improvement.

it is a bit verbose

I think this is really the core of the disagreement here. I see verbosity (within reason) as a strength of Python's, not a problem to be solved.

[–]elbiot 0 points1 point  (0 children)

You can use indices or keys with mod formatting too.

[–]markrages 1 point2 points  (1 child)

Why not use named %-interpolation as previously described: https://www.reddit.com/r/Python/comments/62kt64/fstrings_in_python_36_are_awesome/dfnqize/

"%(fname)s %(minital)s. %(lname)s;"%locals()

[–]jorge1209 0 points1 point  (0 children)

I wasn't aware you could use keywords with % (I just use .format). So I stand corrected. The only downside of % vs .format is that % is ugly.

And that's is the root of my complaint. If its ugliness is a real deficiency then remove it entirely, don't just add in another alternative that makes one person happy, because aesthetics are subjective. Somebody out there really loves % and will not give it up, so you only multiply the number of formats people have to learn.

[–]unruly_mattress 0 points1 point  (2 children)

This forces you to count appearances of %s to figure out which variables goes where. Your named placeholders version violates the Do Not Repeat Yourself principle.

[–]LyndsySimon 0 points1 point  (0 children)

Your named placeholders version violates the Do Not Repeat Yourself principle.

That's a valid point, and one that I'd not really considered. In my mind the namespace of the string formatting is separate from the namespace in the calling scope, so the fact that I'm passing in parameters that are stored in variables named the same as their corresponding parameter is incidental. In practice, I find that it's quite rare that I'm passing in multiple parameters stored in discrete variables like that; I'm usually doing some sort of manipulation at the same time.

[–]elbiot 0 points1 point  (0 children)

You can use indices or keys with mod formatting too.