Python Forum
instructing f-string over format()
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
instructing f-string over format()
#1
f-string are awesome, but there are times when i like to continue to use format method. For example when i want to simplify the string and not pollute it with a bunch of expressions. Sometimes its nice to split them off. The string can get a little messy, i think.

However everyone instructs to use f strings over format. IF at any point format method was to become obsolete, then i would agree to get comfortable using f string all the time. But i dont think that is going to go. In that case we are going to have f strings and format method side by side.

Im just curious as to what others think? I remmeber a discussion about it when it was new, but nothing much lately.
Recommended Tutorials:
Reply
#2
i'm still looking forward to learning f-string. i can, now that i am upgraded to 3.6.8 system-wide.

i really don't understand why it was done as a data type, instead of regular strings using a function or method to produce a resulting string. or as new features for .format() with a single argument. maybe i want to read an f-string layout from a database, such as for different word order in different languages or different business markets. how can i do that? what if i am dealing with bytes (which have no .format)?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#3
My problem with f-string promotion is that f-strings are fine and dandy if you are not planning on supporting anything before 3.6.
Craig "Ichabod" O'Brien - xenomind.com
I wish you happiness.
Recommended Tutorials: BBCode, functions, classes, text adventures
Reply
#4
If I look at % then it's still around. I think that .format will also be around for foreseeable future. However there are signs that development of 'convenience' features will be targeted to f-strings.

From Python 3.8 one can do 'print debugging' with f-strings more simpler:

>>> a = 'spam'
>>> b = 'ham'
>>> print(f'{a=} and {b=}')  # instead of f'a={a} and b={b}'
a='spam' and b='ham'
If you look at controversial PEP 572 -- Assignment Expressions ('walrus operator') then one can observe that there are f-strings used as examples and no .format method. It can be interpreted subtle indication of focus of Python development.

In my opinion the promotion of f-strings is targeted to beginners. There is no reason not to learn 'the latest and greatest' features of language. Any professional setting is bound to restrictions imposed by existing codebase.
I'm not 'in'-sane. Indeed, I am so far 'out' of sane that you appear a tiny blip on the distant coast of sanity. Bucky Katt, Get Fuzzy

Da Bishop: There's a dead bishop on the landing. I don't know who keeps bringing them in here. ....but society is to blame.
Reply
#5
I do advice to use f-string,sometime i do comparisons with .foramt() and other time not.
If it not was better i would not have advice so much,but it's more readable and concise,less prone to error than other ways of formatting.
I use f-string in all i do and never .format() anymore.

ichabod801 Wrote:My problem with f-string promotion is that f-strings are fine and dandy if you are not planning on supporting anything before 3.6.
Yes if planing to support < 3.6 then drop the new stuff,also support of only 3.6+ if not a problem these days.
Eg a lot people use Black,and very few complain anymore that's it only 3.6+.
Black Wrote:Black can be installed by running pip install black. It requires Python 3.6.0+ to run but you can reformat Python 2 code with it, too.
Reply
#6
I'm used to .format() and it works for all versions of python, so I'm unlikely to move to fstrings easily. As far as I understand fstrings, they only save a little typing, but I have more important things to worry about. May be in a few years...
Reply
#7
I was wondering if anyone here just stuck with format
Good to know.
Recommended Tutorials:
Reply
#8
a lot of my scripts generate what is call "user data", which is usually a bash script to be run, for instances being launched in the AWS EC2 cloud. these have a lot of variable substitution in them. i have been using .format, but i think f-strings will do well in these. i used to code them as multi-line triple-quoted strings but that was difficult to use with .format() so i switched each line being a single call to a function named ud() with .format() in there. so instead of:
ud("#!/bin/bash")
ud("export JOB='{}'".format(job_id))
ud("mkdir '{}'".format(log_dir_name))
ud("exec &>'{}".format(log_file_name))
...
ud("aws s3 sync '{}' 's3://{}{}'".format(log_dir_name,bucket,s3_prefix))
i can do:
ud(f"""#!/bin/bash
export JOB='{job_id}'
mkdir '{log_dir_name}'
exec &>'log_file_name'
...
aws s3 sync '{log_dir_name}' 's3://{bucket}{s3_prefix}'
""")
this is one of the reasons i wanted to get 3.6 or 3.7 running system-wide on my old Ubuntu 16.04 system that had 3.5 system-wide. upgrading to a full fresh install of Xubuntu 18.04 got me several things i wanted, including f-strings for these scripts.

i do expect to still use .format() in some other situations. but i do expect to migrate to only using f-strings for locally run scripts. stuff i make for others will use .format() for a very long time.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply
#9
If you do only simple variable substitution, you can also do it with .format(**locals()), for example
>>> a = 4
>>> b = 'foo'
>>> c = 'Guido'
>>> "The longest {b} has length {a}.".format(**locals())
'The longest foo has length 4.'
Reply
#10
i have done some of that. it gets harder when globals are also involved.

Output:
>>> b = 'foo' >>> len(b) 4 >>>
i hope that never happens.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
Reply


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020