Easier (and more performant?) way to create strings

[PlasmaHH]

It seems that rich is heavily geared towards just outputting something directly at the place where we want to create it.

I have several projects that use coloured output (using ansi color sequences) and thinking about enhancing it and using a library like rich.

The code works mostly by assembling strings and colour information from various sources from multiple sources into one. Often __str__ is used for that too. The code could look for a simple case of (configurable) colouor output of an object like:

def __str__( self ):
    return color(f"{self.xxx}",self.get_xxx_color() )

# and later use it like
return color(f"xxx = {xxx}","#456")

A lot of these strings will be cached for performance reasons.

Now with rich, this is not as simple anymore. As per https://rich.readthedocs.io/en/stable/console.html#capturing-output one could capture the output that is printed.

One could possibly write a function like

def eval_rich( s, console = None ):
    if( console is None ):
        console = rich.console.Console()
    with console.capture() as capture:
        console.print(s,end="")
    ret = capture.get()
    return ret

But that seems to be overly complicated and slow. It feels like in the end rich itself will anyways generate a string ( or multiple ones ) and pass that to whatever is necessary for output.

An alternative way that has been proposed to me was that one could just pass around all the formatting (bbcode like) strings instead of print( s, style=xxx ) string results, but in that case at the point where I want to get the string I have to do the above anyways, plus it has to parse the string which costs more than just passing around strings containing the ansi codes already.

The speed is already noticeably impacted for cases where there are tens of thousands of tiny strings in the current approach and I really don't want to slow it down even more.

TL;DR

So is there an easier and possibly more performant way to get just the string than to go the roundabout way to capture the output?

[willmcgugan]

https://rich.readthedocs.io/en/stable/text.html

[willmcgugan]

Most of those things, you wouldn't want to send ansi codes to, which might suggest you don't need Rich there.

If you do, and you have a file-like object you can pass that to the Console constructor. Rich will remove ansi codes if it isn't writing to a tty.

[willmcgugan]

https://label.dev/articles/xy-problem/

[PlasmaHH]

I specifically listed examples where I need to do that in certain circumstances. To elaborate more on a few: I have features where you connect to something like a console via network, serial, pipe etc. and the output to there, the other end is expected to support ansi color codes.
At another place I have at the step before I output the strings a grep like filter.
In another project I pass strings to gui components that undertand ansi codes and display it as something like an internal console.

All of these have APIs that expect pure strings.

[willmcgugan]

Capturing prints likely isn't a performance issue. It's the rest of the work that Rich does that has the largest impact. You can disable highlighting, word-wrapping, whatever you don't need. And avoid reconstructing a Console object.

And if you can write a file-like object that writes to the network, serial, pipe, you won't need to capture.

Hope that helps. I can only give general advice without knowing the specifics.

[PlasmaHH]

Yes, its hard to tell specifics without being allowed to show source :/ anyways the APIs that I have to deal with are not file-like objects but get strings, so no way to make console deal with them as if its a file.

What I do for performance reasons is to prepare (and cache) strings that I concatenate together using the ansicolors package. Would I do that with the rich bbcode syntax then each time it would need to be reparsed...

I think I will put that aside and try doing it in my personal project first where I can share source code, maybe thats a better path. Be prepared for some weird questions ;)