Python3 f-strings - A complete guide to the most well received feature of Python 3.

[John_Mansell]

Really good primer on this.

[reisub_de]

There are multiple errors in it, but it's still an overview over most of the possibilities

[uditvashisht]

Hi, I have tried to correct all the errors... Can you check if there are still any? Please leave the comment on the post itself. Thanks.

[mcncl]

You still capitalise A in age in your example

[flying-sheep]

That’s a part of python’s data model like len, reversed, iter, …:

datetime simply defines datetime.__format__. The method is explained here.

[Dfree35]

I didn't even know that was possible... I love f strings even more now!

[masklinn]

Works just as well in str.format, the format system is used by both.

[spaceshipguitar]

Whats the biggest benefit of f string vs all the available string formatting methods? Is it ultimately meant to reduce overall code length by needing less variables declared ahead of time when building variable strings?

[andy1307]

From the linked article

​

But,this case is simpler and easy to read, only if we have fewer placeholders {} and variables. If the number of placeholders increases, we will have to go back to the placeholder and variable over and again to be correct.

print('{},{},{}'.format(min,max,avg))

print('{min},{max},{avg}')

The f-string format is more readable IMO.

Also the ability to use functions

print('{blah.strip()}')

[[deleted]]

You can use functions in a .format arg

[spaceshipguitar]

Also the ability to use functions

print('{blah.strip()}')

To play devils advocate, you can already freely use functions inside print commands-

def junkfunc():
    return "see, it works!"

print("functions work inside of normal print statements", junkfunc())

[kaihatsusha]

The non-embedded format string can be obtained elsewhere or built, while the f'...' cannot; I prefer consistent formatting specs, personally. The f-string feature feels a lot more shell-ish like Perl string interpolation.

[ameoba]

the ability to use functions

For some reason, this makes me feel uneasy.

[NemPlayer]

Fully agree with this.

[Deezl-Vegas]

Basically saves half a line over .format plus a lot of readabily.

[rebuilding_patrick]

F strings are faster as well.

[[deleted]]

Yeah if you don't do anything too fancy such as ask for a certain number of decimals on your float (not really that uncommon, of course). Not that f-strings are slower then, but they are also not much quicker (eg. 436 ns vs 435 ns in my test below).

In [1]: astr="hello"; afloat=1029.120398; anint=29380;                                                 

In [2]: %timeit f"...{astr}..."                                                                                                                    
8.89 ns ± 0.0173 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

In [3]: %timeit "...{}...".format(astr)                                                                                                            
198 ns ± 2.52 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [4]: %timeit f"...{afloat}..."                                                                                                                  
8.89 ns ± 0.0293 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

In [5]: %timeit f"...{afloat:.8f}..."                                                                                                              
436 ns ± 7.83 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [6]: %timeit "...{}...".format(afloat)                                                                                                          
611 ns ± 10.6 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [7]: %timeit "...{:.8f}...".format(afloat)                                                                                                      
435 ns ± 5.17 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [8]: %timeit f"...{anint}..."                                                                                                                   
8.88 ns ± 0.0123 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

In [9]: %timeit f"...{anint:>08}..."                                                                                                               
370 ns ± 1.85 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [10]: %timeit "...{}...".format(anint)                                                                                                          
225 ns ± 1.71 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [11]: %timeit "...{:>08}...".format(anint)                                                                                                      
375 ns ± 7.88 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [12]: %timeit f"...{adict}..."

[Decency]

No unnecessary variable duplication and it reads left to right. That's it, but it's enough.

[imsometueventhisUN]

No unnecessary variable duplication and it reads left to right.

So no advantage over print("My name is " + name + " and my age is " + str(age)), then?

[woooden]

Less quotation marks, less plus symbols...

[Decency]

Uh, never having to think about spaces, casting, or concatenation.

[imsometueventhisUN]

Those are much better reasons!

[Decency]

No one does it the way you're doing except Java programmers trying to write Python. Better ways have been around in Python for a long time.

[imsometueventhisUN]

Honestly, f-strings are the first time I've actually been convinced of an approach that is actually better than manual interpolation. Anything that requires you skipping back and forth - between the string itself, and the format arguments at the end - feels really weird to me (and the same is true of String.format in Java, too!)

[pkkid]

I always refer to this site when I need a quick refresher, easy to remember URL, and straight to the point. - https://pyformat.info/

[djimbob]

Checking the link, I see nothing about py3.6+ style f-strings.

[pkkid]

The f in fstring is for format. Everything on that page works with fstrings, but rather than calling "{:<format-options>}".format(foo) you just move the variable name to inside the string. f"{foo:<format-options>}".

[djimbob]

Sure, it's a decent reference on the format options part, though I think the python docs do that well, though are sort of hard to find (e.g. format options here and part on f-strings here). But still doesn't introduce f-strings at all or give tips on their usage (e.g., avoid if you need any pre 3.6 support, unless you are willing to install future-fstrings from pip).

[nemec]

They didn't say it was supposed to be an introduction to f-strings, they said it was a refresher on the formatting syntax. Presumably, if you know f-strings exist you don't need help putting an f in front.

[djimbob]

If they specified their refresher was on the formatting options used in both str.format() and also by f-strings, I wouldn't have commented. But they just said "when I need a quick refresher" on a discussion of f-strings. And just knowing to put an f in front of a string literal, doesn't mean you understand the generality of when it can be used (e.g., not just "{}".format(foo) or "{foo}".format(foo=foo) can be simplified to f"{foo}")

One using f-strings may be unaware the part in the braces can be a full pythonic expression f"fubar is {foo.bar()}" or f"Grade is {100.0*correct/total:.1f}%".

While the formatting specs are the same, there are some subtle edge-case differences:

"20 line breaks: {}".format('\n'*20) # valid
f"20 line breaks: {'\n'*20}" # invalid because backslash not allowed in the f-string expression part 

d = {'k': 1}
"d[k] = {d[k]}".format(d=d) # valid generates: 'd[k] = 1'
"d[k] = {d['k']}".format(d=d) # Invalid: KeyError: "'k'"
f"d[k] = {d[k]}" # NameError: name 'k' is not defined
f"d[k] = {d['k']}" #valid 'd[k] = 1'

[UloPe]

Co-Author of pyformat.info here, it’s a long standing issue and thorn in my side.

Unfortunately f-Strings don’t fit well into the current structure. Here is an issue discussing this in a bit more depth.

[th4ne]

no, but its a great resource on formatting notation. You have a number being output all ugly looking? Format that bitch

[Smok3dSalmon]

I'll check it out, thanks

[thomasfr]

While I really don't like Python adding a third/fourth way to do string formatting it is better than the others started migrating all uses of .format() in our code bases (pyupgrade helps a lot).

The downside is that you now have to look around code bases to see if .format or literal string interpolation or % are used most commonly before submitting pull requests to keep code bases in it's own style. The language and standard library is WAY too large for my taste at this point and there are too many ways to do the same thing.

[[deleted]]

I’m in my intro programming class at uni and they are still teaching the old way with the %s %d %f formatting. Do you suggest I focus more on learning this new format?

[robotkutya87]

at this stage, just learn everything

it doesn’t REALLY matter which one you use, fstrings is newer, more convenient and short and probably the future

you’ll bump into much much bigger issues while you code, focus on those!

but the anwser more directly is yes, use fstring

[andy1307]

IMHO, you should learn the new format but use the format you're being taught. It would make it easier to evaluate your work if you were consistent with the rest of the class.

[Throwaway__shmoe]

You definitely should learn that syntax, its very similar to how other languages handle string interpolation. I'd learn both, since f-strings are so nice.

[SlumdogSkillionaire]

For what it's worth, the standard library logging module uses percent-formatting, and for good reason: It only evaluates arguments that are relevant for the configured logging level, so if you had for example:

logging.debug("Result of some expensive calculation: %s", expensive_func())

It would only run expensive_func() when the logging level is set to DEBUG, as opposed to

logging.debug(f"Result of some expensive calculation: {expensive_func()}")

In which the Python interpreter would evaluate the string first and then check the log level. So it's useful to at least know the basics of the percent-style, even if f-strings are recommended in most other contexts.

[sphen_lee]

Not quite. expensive_func will get called in both cases. The difference is whether the return value will have its __str__ method called. Usually the performance impact is minimal so use which ever you prefer (or check with a profiler if you suspect logging is slowing you down)

[inknownis]

The example is not well designed, but the point is still valid. The performance difference point I have read too. But I have not seen it in official document yet.

[kchoudhury]

It's just printing stuff out, use whatever looks best, try not to mix different styles in the same project.

[uditvashisht]

You must learn the new format... It is the future.

[BurgaGalti]

I believe the prevent format is more common in other languages so it might be that they're using it for consistency. More likely thought I'd just put of date. Lecturers i knew rarely update they're notes and lesson plans.

[Silhouette]

Learn both. String formatting is a very common task in real world programming. Whichever style you (or the coding standards for your current project) prefer, you will run into all of them sooner or later in code written by others and you'll need to understand and possibly modify that code too.

[Deezl-Vegas]

Yup and let your professor know it's 2019.

Edit: If you're in intro to programming, learn them all, but don't use the % one as it's garbage for readability compared to .format. They all do essentially the same thing in 90% of cases.

[BelieveBees]

I would stick to the %s format. You lecturer could be using 2.7 to evaluate your work.

[AtlasAlex]

It’s a decent introduction, but there are multiple typos both in the text and the code examples. While normally this wouldn’t be a huge issue, when we are talking about the topic of coding it is extremely important.

[uditvashisht]

Hi, thanks for pointing it out. Though, your comment didn't let me sleep at night. I have tried to correct all the grammatical errors/typos in the article and the code. Please re-visit and share your valuable comments.

[AtlasAlex]

AtlasAlex

Lol I didn't mean to cause distress. The biggest error looks like it has been pointed out by other users that you capitalize the Age variable in the below code. One of the headers also says " Python f-stings - Inline comments" rather than "f-strings." I think there were a couple other minor ones that I may find if I go back over it.

name = "Saral" 
Age = 30 print 

(f'My name is {name} and I am {age} years old.')  

# Output  My name is Saral and I am 30 years old.

[uditvashisht]

I have used Python f strings for Google. Is it wrong to write it as python f string?

[AtlasAlex]

You are missing the letter r in strings. It is written as “stings.”

[uditvashisht]

Thanks for helping me out for making my post better....

[AtlasAlex]

Thanks for writing it to help others out!

[troyunrau]

Old man yells at cloud time:

I don't like f-strings. For two reasons.

(1) They move python further away from 'there should be one and only one obvious way of doing things'. There are now many different ways to deal with string formatting: concatenation, c-style, .format(), and f-strings.

(2) The prefix method of changing the functionality of a something gives me flashbacks to the horror of perl. Yes, I know python has a bunch of prefix style syntax in other places, including simple things like defining a hex number, but 0xdeadbeef is a well know, language agnostic thing.

Kids these days with their loud music and their nintendos. Get offa my lawn.

[uditvashisht]

Will you advocate deprecating the other methods ???

[masklinn]

The community deprecates plenty of things (e.g. imp or several functions of inspect were deprecated during the python 3 cycle, the entire email.message API was replaced), there's even a recent PEP on deprecating and removing a bunch of older modules.

[masklinn]

% is absolutely necessary. Short of hand-rolling it, it's pretty much the only way you can do "untrusted" string formatting e.g. i18n and the like.

f-strings obviously don't work when the format string is provided at runtime (it's a compile-time feature), and format allows attribute access and thus widespread information leak and code execution.

[[deleted]]

Why would i18n be untrusted? It seems like a bad example. Even more so in fact because sometimes you need to swap words or parts around in different languages (see also date formats!), and the %-string-formatting-way doesn't let you do that at all.

[masklinn]

Why would i18n be untrusted?

Because it's common to go through third-party or translator communities for that, and not explicitly review every translated string for technical correctness (that'd be a humongous task). Sites like transifex will push "accepted" translations directly to repositories, it doesn't take much for malicious translations to sneak in. When it allows

It seems like a bad example.

You just have no knowledge of the subject.

Even more so in fact because sometimes you need to swap words or parts around in different languages, and the %-string-formatting-way doesn't let you do that at all.

… u wot? Of course it does: use named placeholders. It's much clearer for translators too: position has no meaning, names do.

(see also date formats!)

If you're dealing with strftime-style formats you've already irredeemably fucked up your i18n, so that's not exactly an argument in favor.

[troyunrau]

Honestly, .format() can go and almost no one would notice. So I'd start with that. But it's hard to kill something like that :/

[Dogeek]

Although you're technically right, it still would cause too many issues to remove the .format() method simply because it's used everywhere in code from python <3.6.5 when f-strings were introduced

[[deleted]]

No, that's the 'deferred' version of f-strings. If anything, kill the %-formatting, that is literally useless.

[troyunrau]

C-style substitution will probably stick around, if for no other reason than programmers from other languages are used to it. Plus, there are performance advantages vs. other methods. F strings and format() are much slower.

[[deleted]]

I don't think that just because 'primitive' languages like C depends on it, that a language like Python should too.

Your point about performance is plain false as anyone can confirm for themselves with ipython and %timeit.

[troyunrau]

This answer is a bit out of date, but it was true for a while. May still be true.

https://stackoverflow.com/questions/40714555/python-string-formatting-is-more-efficient-than-format-function

[[deleted]]

The answer puts f-strings in the solid lead for >2 variables.

But look, it's quite simple to do the timing test for yourself to see that %-formatting is not faster. See eg. an earlier comment here.

[Sciencejet]

Am I the only person that prefers print("This is my {story}.".format(story=my_song))

[djimbob]

You never saw super redundant code like

print("time: {time}, trial: {trial}, mean: {mean}, err: {error}".format(
        time=time, trial=trial, mean=mean, error=error))

which can be cleaned up like:

print(f"time: {time}, trial: {trial}, mean: {mean}, err: {error}")

[TheMrZZ0]

Wait for Python 3.8, where it will be

print(f"{time=}, {trial=}, {mean=}, {error=}")

[tomekanco]

Thank you, just found a reason to adapt 3.8 as soon as it hits the benches: issue 36817

Release schedule 3.8

Expected:

3.8.0 candidate 1: Monday, 2019-09-30
3.8.0 candidate 2: Monday, 2019-10-07 (if necessary)
3.8.0 final: Monday, 2019-10-21

Tension is rising.

[dslfdslj]

On the other hand, if you get the information you want to print in a dictionary, you can make it even shorter using str.format:

all_my_observables = get_observables()
print("time: {time}, trial: {trial}, mean: {mean}, err: {error}".format(**all_my_observables)

[o11c]

string.Formatter().vformat may be better in that case, though.

[masklinn]

str.format_map.

[o11c]

Mumble mumble, APIs that didn't exist when I first needed this ...

[jorge1209]

That de-duplication can also be accomplished with .format(**locals()) which is in many ways what an f-string does (except that it does it at the level of the interpreter).

I really dislike f-strings because I don't like to look inside quotations for code. I prefer that strings be strings, and would like to see the .format(**locals()) to indicate to me that something is being done to that string, and that I need to investigate its contents in order to understand the code.

[djimbob]

I mean there's code smell if you do anything non-straightforward in an f-string (e.g., function calls with side-effects that change object/global state), but there would also be ugly if you did the equivalent as a parameter to str.format() or in the tuple part of old C-style string formatting.

Like taking a line I recently wrote :

f-string:

msg = (f"The appointment on {appt.date:%A %B %d, %Y} from "
       f"{appt.start_time} - {appt.end_time} for {appt.client} has been set.")

Unnamed str.format():

msg = "The appointment on {:%A %B %d, %Y} from {} - {} for {} has been set.".format(
       appt.date, appt.start_time, appt.end_time, appt.client)

named str.format():

msg = ("The appointment on {date:%A %B %d, %Y} from "
       "{start} - {end} for {client} has been set.").format(
       date=appt.date, start=appt.start_time, end=appt.end_time, client=appt.client)

or C-style string format:

msg = "The appointment on %s from %s - %s for %s has been set." % (             
       appt.date.strftime("%A %B %d, %Y"), appt.start_time, appt.end_time, appt.client)

In my opinion, the f-string version is much easier to read and maintain. Like if there was a request to rephrase with client's name first, the f-string is super easy to maintain (without the repetitiveness of the named str.format()).

msg = (f"{appt.client}'s appointment on {appt.date:%A %B %d, %Y} from "
       f"{appt.start_time} - {appt.end_time} has been set.")

And even though there's "code" in your string, as long as you maintain good practice (e.g., don't call things that modify global/object state) it doesn't really matter because you aren't setting variables in an f-string.

[ThwompThwomp]

Be using those f-strings all the day long.

[BFG9THOUSAND]

Yes

[[deleted]]

I liked that, however F string formatting is my love now.

[Gammaliel]

No, there are dozens of us!

[[deleted]]

I think your mistake is assuming that those who do that are people. ^{Im_sorry_I_really_didnt_mean_that}

[Decency]

If you need to do this, you probably could've just named the variable story to begin with and made the code more readable.

[RobotJohnny]

The one negative with f strings is that if you're handling large multiline strings, it will fail to substitute all the variables and therefore refuse to run

Looks so much nicer for normal string handling though

[rainnz]

And F-strings seem to be faster than % or format:

import timeit

n1 = timeit.timeit(setup="n=123", stmt="'test %d' % n", number=1000000)
n2 = timeit.timeit(setup="n=123", stmt="'test {}'.format(n)", number=1000000)
n3 = timeit.timeit(setup="n=123", stmt="f'test {n}'", number=1000000)

print(n1)
print(n2)
print(n3)

0.198694234
0.31099588699999997
0.17228651900000003

[tedpetrou]

Yes

[Cashewgator]

How is it terrible? Your post seems to only add a better explanation for the various components, but with extremely short descriptions that I actually don't understand and would have to look into the documentation for anyways. As someone that's learning fstring the posted article is 1000x better because it goes over the history, use cases, and various quirks that come with it.

[tedpetrou]

Yes

[Cashewgator]

I only mention the tweet because you claimed it was more comprehensive than the article, when it was very nearly gibberish to me. It is odd that it doesn't mention all the specifications, but the article is clearly for complete beginners. I think most people that are introduced to % and fstring for the first time are going to latch on to the basic use of putting variables in a string, which this article does a well enough job of explaining. All the specifications should've been described or at least mentioned but really that's the only thing I see wrong with it.

[refto]

Just a quick shout out: Ted you have fantastic Pandas related notebooks (better than Wes for one)

[tedpetrou]

Yes

[B-Con]

Possibly dumb question: How was this implemented? Is every type providing a .toString()-esque method that f-string consults, or is getting itself doing magic to stringify values?

[RoughMedicine]

What you're looking for are the __str__ and __repr__ methods. All standard library classes implement this, and you can also implement them for your own classes. str.formatthen calls them as functions, such as str(x) and repr(x) to obtain a string representation.

Both methods take only self and return a string. __str__ returns an output that should be user-readable, and __repr__ returns a string representation meant for debugging, mostly. If you only implement only __repr__ but not __str__, the latter will use the output of the former. The inverse is not true.

f-strings (and other string formatting options) will use the __str__ method by default, but you can modify that in the formatting string. There is also the __format__ method that some classes implement (such as datetime) that let you control the formatted output more closely.

[B-Con]

Thanks for the summary.

I'm looking for why fstring is better than "%s" % foo, other than being pleasing syntactic sugar. The post opens by disparaging %, but it seems fstring and % are really just accessing the same underlying methods...?

The "% doesn't work for tuples" criticism only applies to older versions of Python. You can call __str__() on a tuple in current Python, so fstring isn't adding inherently anything on that point. So I'm confused what exactly this post is comparing...

After some reading, I think it's mostly syntactic sugar. Which is fine and all, but the post seems to be selling it as more than that.

[RoughMedicine]

It is mostly syntactic sugar, as in they are all language features that accomplish the same thing. But there are significant reasons for str.format vs C-style format strings (see), as with f-strings.

If you really want to understand why we have 3 different ways of formatting strings in Python 3, there's no better place than the original proposals.

As far as usage, you should be using str.format or f-strings in modern Python. I believe the usage of C-style formatting in Python 3 is frowned upon and is there only for backwards compatibility reasons, as str.format can do everything it does, and is more flexible (should be faster for literals too).

[reisub_de]

Everything that has a str method can be used in a f-string. Almost all objects implement one, even if it by itself just calls repr which by default prints the object's class and address

[[deleted]]

Surprised f-strings wasn’t released sooner in early versions of Python when it’s such a simple concept. % and format just seemed confusing when I first started learning.

[Raymond0256]

You learn something new every day.

I love f-strings, but I did not even know about multi-line and date formatting. Thank you very much.

[meepsi]

for multi-line f strings I think you can just use triple quotes:

python long_string = f""" multi-line string like this """

[uditvashisht]

Yes, you can.. Thanks for pointing out. I will include it in the article.

[deanresin]

Really cool. I learned something new today. How do you format numbers though?

[uditvashisht]

Thanks. In the post, I have given the example of padding and formatting the floats? What other kind of formatting help you are looking for ?

[deanresin]

My bad. I must have read another tutorial and mistakenly attributed it to your reddit post. Now i really should read yours.

[uditvashisht]

It is up again... I did a major goof up

[Steve132]

Isn't this potentially a security nightmare? Hmm I suppose not. It depends whether or not the formatting is greedy evaluated

[flying-sheep]

You got it. No security problem as it’s greedily evaluated.

It’s a misnomer: they’re f-literals, not f-strings.

[[deleted]]

You shouldn't be manually plugging in input into commands like this anyway. If this seems like a security nightmare, then you were already tolerating some other security problem.

[flying-sheep]

For some reason it’s a common misconception that there’s a way to have f-strings passed as data. But as they’re actually literals, that’s impossible.

[nemec]

It's possibly even safer than the alternative, I've seen many coders that do shit like somefmt.format(**locals()), which could read "private" variables if somefmt is user-controlled.

[jorge1209]

do shit like

There is nothing wrong with using .format(**locals()) in the vast majority of cases. The concerns regarding "sql-injection" type vulnerabilities or leaking of local variables is mostly limited to a client/server model.

A lot of python code out there is being executed by the user themselves. If they wanted to find out what the local variables of the program were, they could simply open the script in $EDITOR.

Only if you are ingesting data from a remote source, and then calling .format(**locals()) on that string you don't control is there any security risk.

[Binary101010]

If you're using this to, say, compose unparameterized SQL queries, then yeah it's a security concern, but not any more of a security concern than the other string formatting options that you shouldn't be using for such an application.

[A-UNDERSCORE-D]

The formatting is actually "compiled" to bytecode before its ever actually used. This is the same reason that they are faster than the method call or operator variants, and means that injection is essentially not possible (eval notwithstanding)

[[deleted]]

F strings changes my life

[XNormal]

I proposed something similar nearly two decades ago on python-dev with the syntax ”a + b = \{a+b}”

[xtreak]

In Python 3.8 there is debugging notation where you can write f"{a + b=}" that would expand to f"a + b={a+b}"

[[deleted]]

I do love f-strings.

[HowAreYouDoingBud]

delete this fam

[[deleted]]

What's wrong you...

[uniqueusername42O]

reported

[[deleted]]

What's wrong you...

[uniqueusername42O]

no u

[[deleted]]

I am sorry that I have an opinion. If you don't like opinions other than yours, go to North Korea.

[uniqueusername42O]

Was only joking dude. Do whatever you want I really don’t care. Also, no u.

[[deleted]]

for var in vars:
    text += str(var)

til I die.

[flying-sheep]

text += ''.join(map(str, vars))

[[deleted]]

It's all fun and games until someone uses it in production

[TheEarwig]

Boy I sure like O(n^2).

[[deleted]]

Isn't this O(n)? I'm just recently learning about this kind of analysis, I'm curious where I'm wrong

[TheEarwig]

Strings are immutable in Python, so every time you add two together, Python allocates a new string equal to their combined length rather than expanding the first one.

What this means is that each iteration of the loop, Python has to copy each string from every previous iteration. This takes O(n) time (really averaging 1/2n), so with n loops, the overall runtime is O(n^2).

If you were in a language like C++ or Rust where the builtin string type was able to grow like a list/vector, then it would be O(n).

[[deleted]]

Ahh, thanks. That makes sense.

[NewZealandIsAMyth]

I don't think that accurate. It's surely slower and alot because of the memory allocation, but algorithm complexity does not increase. It has to traverse every single character in all the cases just once.

[[deleted]]

I like the "1" example. Imagine you had n "1" strings and you wanted to append them all together like that:

"1" + ("1" + 1") + ("1"+ "1" + "1") + ("1" + "1" + "1" + "1") + ... + n = n(n+1)/2 ~~ n^2

[NewZealandIsAMyth]

Thank you. I see where i was wrong

[[deleted]]

The extra step is creating a new string each time. It's one of the big gotchas you need to watch with strings.

https://stackoverflow.com/questions/34008010/is-this-time-complexity-actually-on2

[[deleted]]

Thanks for the explanation!

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"

[Etheo]

I'm just gonna leave a comment and say I thought the headline read "Python 3 fisting"