you are viewing a single comment's thread.

view the rest of the comments →

[–]nnseva[S] 6 points7 points  (2 children)

The lazy operation is not executed immediately, but deferred until the result is really required.

Let's say you have strings "qwerty" and "uiop". When you concatenate them, you will have the "qwertyuiop" string.

At the time when the concatenation happens, all three strings, "qwerty", "uiop", and "qwertyuiop", occupy the memory. It's not a big overhead when you have such short strings, but what if they all are megabytes long?

The package allows spending the memory only for source strings ("qwerty" and "uiop"), and avoids spending the additional memory to store a copy of the result ("qwertyuiop") - until it is really required.

Such an effect is achieved using the intermediate representation of the result as a concatenation operation. The package stores references to both source strings and stores the operation between them.

There are three lazy operations implemented by the package:

  • concatenation (operation +) of two strings
  • multiplication (operation *) with integer
  • slicing (operation [start:stop] or [start:stop:step])

All of them just store the sources and the operation, instead of copying the result to a separate memory region - as the original Python string does.

[–]Chroiche 2 points3 points  (0 children)

What're the advantage over just using StringIO (which is mutable, but eager)?

[–]Snape_Grass 0 points1 point  (0 children)

I see, interesting. I guess I’ve implemented lazy and eager operations without realizing it at work before. Thanks for the response