String Comprehensions

Is there such thing as string comprehensions?

No, although you could do a list comprehension and turn the generated list into a string using .join().


Shouldn’t Python add string comprehensions as a feature? If you have a self defined class how do you enable a comprehension for that class?

I don’t quite see how string comprehension would work, though. Are you meant to write:

some_var = "i for i in some_other_iterable"

How is Python meant to differentiate that from a normal string?

List comprehensions are really just products of the way for loops work. I wouldn’t know how to enable it for self made classes, and I’m not entirely sure that it’s possible…


Maybe this, some_var = c"i for i in some_other_iterable"
It like a f string but a c string.

Perhaps. Either way, there isn’t a way (also due to the memory-intensive nature of doing something like this).

1 Like

Then should this kind of feature be added to other not memory intensive languages(maybe fast languages)? Maybe?

In most languages I know, comprehensions don’t really exist. But either way, each time you add or change a string (such as in a so-proposed string comprehension), you create an entirely new string, so whatever language you do it in, it is still going to be memory intensive.

1 Like

Why can’t the comprehension be a module like comprehensions(not a real module)?

What languages do you know? In your profile, I see Python, Javascript and Java but is there any more?

There could, but I don’t see that getting round the issue of memory…

I dabble, but I’ve also done a bit of C#, Go, Ruby, and a tad PHP…

What’s wrong with the original suggestion of "".join()? You can use any valid iterable in that case including list comprehensions or generator expressions which seems to be what you want. You could equally implement a similarly named method for any types you introduce yourself.

It’s scarcely more typing than the other comprehensions and equally readable.

some_var = "".join(i for i in some_other_iterable)

Bear in mind they’re all ‘syntactic sugar’ anyway. They make certain things easier to read/write but they don’t actually introduce any new behaviour.


The string comprehensions was a suggestion. It also looks a bit confusing of what the "".join() part changes the expression/comprehension.

What influence does "".join() have on the generator expression?
Why this:

, not this:
some_var = str(i for i in some_other_iterable)

I’m not 100% sure what you mean by changes it. You’re just concatenating a series of strings, the implementation is probably doing something clever to save processing/memory versus doing it with a regular loop (concatenating immutable sequence types is scary) but the result shouldn’t be different.

There’s no route at present for str to accept iterables (since it’s used to get the string representation of an object, including iterable objects) so the given example won’t act like you want. For your own types you could make them callable with iterables if you like that syntax, that seems perfectly reasonable.

1 Like

I mean the what the program interprets "".join() on this:

Why is it concatenating an empty string, what does that do?

Why not have a look at the docs if you want to know what the method is supposed to be doing.


To make it easier, what about you give me the link.

Learning to look things up yourself (without being given links) is both a skill and a useful thing to do in relation to programming. Who knows, on your search for the relevant Python docs, you may discover something interesting…


What about this?

Yes, now I understand.

So it just joins a string and concatenates result of the comprehension to the empty string.
But what kind of comprehension is the argument to the join() method?

In this case it either creates a tuple or other similar iterable.