[7/15] What is a tuple? What is this error saying?


Right now I have

def reverse(text):
  i = len(text)
  word = ()
  while i > 0:
    word += text[i - 1]
    i -= 1
  return word

And it’s saying

“Traceback (most recent call last):
File “python”, line 9, in
File “python”, line 5, in reverse
TypeError: can only concatenate tuple (not “str”) to tuple”


Your error kinda says it all


So then a tuple is a string at an index?


a tuple is a immutable list, its another data type (besides the ones you already learned like string, dictionary and list)


Well, + for sequences typically means concatenate (create a new value as opposed to append/extend)

It’s just doing stuff between types where it isn’t supported (like the error says)


So if I turn “tuples” into strings, then I can concatenate it and solve this?


IDK, depends on what you meant in the first place. You wrote (), what did you mean?
() is certainly a thing, but you’re probably not familiar with tuples (despite already using them, but they kind of meld in with the language, you’re not using them as data structures) – and if you’re not familiar with them then you probably didn’t mean to use them, so what did you mean, and what does that look like?


Thanks for the hints. I meant strings, and I thought that by saying (), I was putting down an empty string. But err… if I remember correctly, an empty string is “”.


as you might have guessed by now, () created a tuple.


And with that out of the way I want to point out that if you keep creating a new string for each letter that you append, how many strings will you have created for a large piece of text, like a book? How many characters will you have processed in total by doing that?

Now, CPython (the implementation of python most use) will cheat and see that there’s only ONE reference to that string, so it will actually not create a new string, it will resize the existing one. This isn’t something that the language itself promises to you though, so you shouldn’t write it that way

(Strings are immutable and can’t change, but if nobody is looking, who’s to say that it did change? – That’s what allows CPython to cheat in this particular case)


That’s all way over my head right now, but I think I get what you’re saying (my code is horribly inefficient).


It is horribly efficient for large text.

If you know that the text will be small, then it might not even be possible to measure the difference, and then it’s fine. But you should know it does this, and you should prefer to write what you meant (append, not create new)

For example, you might use + when doing string literals like so:

('Once upon a ' +
'time there was ' +
'a ' +

Wow. I should not write books, that was horrible.
(also, the +'s aren’t even needed there)

… + is totally fine, you should know what it does, that’s all.


I originally tried using append but got frustrated with errors so I split it up into other things that I knew how to do with a higher degree of confidence (making new variables).

Like, is word.append(text[i]) syntactically correct?


Right, list better matches what you mean. But you’d only want to change at the end, if you wanted to change at the front as well you would want a doubly linked list (deque)

Doubly linked lists contain references to previous and next value, so they don’t need to be in order in memory, meaning that nothing needs to be moved when adding anywhere. On the other hand, you can’t immediately know where for example the 5th element is, you have to start from either end and work yourself to that location in the list


I’m so sorry, it’s hard to follow you because I’m dumb =(

linked… lists…


See the picture here: https://en.wikipedia.org/wiki/Linked_list
That’s a singly linked list (can only go from the front and traverse to following elements)

Each value knows where the next one is. Insertion is just a matter of changing what the next one is, no need to move anything.

You won’t need or even find them useful for what you’re doing, because you probably just need to append at the end, and python’s list does that just fine.
There are other ways of storing data that makes other operations possible (while trading away other properties)

Dicts have fast lookup, insertion, deletion. But they don’t represent order

Lists represent order, you can get things immediately by location, and you can change things quickly at the end. Replacing values is fast anywhere, because everything else stays in the same place. Adding or removing anywhere else means moving which is slow

Linked lists can change at the ends, and can insert anywhere quickly. But finding something that isn’t at the ends requires starting at one of the ends and moving towards your element (so 6 steps to find element number 6)

…and so on, arranging the data in different ways allows for doing different things with them.


You can ignore linked lists. You should know what makes sense to do with lists and dicts and strings.

Don’t call yourself dumb, it’s new stuff thrown at you in a way that doesn’t necessarily make sense with what you already know so far.

We’re free to use memory any way we want, and if we can think of a way to arrange data in a way that lets us do something, then we can do just that. Lists and dicts are just the tip of the iceberg when it comes to ways of arranging data.


A post was split to a new topic: Python


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.