`std::string_view` adds characters to strings in Python

[jmcarcell]

Check duplicate issues.

• Checked for duplicates

Description

With cppyy 3.5.0, having a std::string_view will append [N], with N being the number of characters of the string when printing a std::string_view.

There is s.data() that will give the expected string, but that means if getting the value from a function, I need to know if it's a string or a string view, while this is not needed in C++. I would say this is unexpected, I would expect comparisons and usage of std::string_view to be similar to std::string.

This seems not be an issue from cppyy standalone: wlav/cppyy#313 (comment)

Reproducer

import cppyy
cppyy.cppdef(
"""
std::string_view s = "Hello, World!";
""")

from cppyy.gbl import s
print(s)

The answer is "Hello, World!"[13]. But then, this means I can not compare a std::string_view to a string in python, because this will not work without the [N]:

print(s == "Hello, World!")  # Should print True, prints False
print(s == "Hello, World![13]")  # Also False
print(s == '"Hello, World!"[13]')  # Also False
print(str(s) == '"Hello, World!"[13]')  # This is True
cppyy.cppdef(
"""
bool is_equal_cpp = s == "Hello, World!";
"""
)
from cppyy.gbl import is_equal_cpp
print(is_equal_cpp)  # Should print True, prints True

ROOT version

   ------------------------------------------------------------------
  | Welcome to ROOT 6.36.02                        https://root.cern |
  | (c) 1995-2025, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Jul 26 2025, 08:01:37                 |
  | From tags/v6-36-02@v6-36-02                                      |
  | With g++ (GCC) 15.1.1 20250425                                   |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |
   ------------------------------------------------------------------

Installation method

Built from source, Spack for the Key4hep stack, LCG stacks

Operating system

Linux, Alma 9, Arch Linux

Additional context

No response

[guitargeek]

Probably that's because the mechanism to implement __str__ via operator<< fails inside CPyCppyy, falling back to calling TCling::ToString() (I think it's called like that).

And in Wims fork of Cling, he patched that function to also try operator<< first, recovering the desired behavior.

So I think we should fix CPyCppyy such that it uses operator<< without falling back to TCling. I can give it a try in the next days.

@wlav, you have any thoughts on this?

[wlav]

It's actually in ROOT/meta, I haven't (yet) forked Cling. :)

I remember this. The basic problem is that old bugaboo that you can't really execute single statements in Cling b/c they become part of the transaction record and thus hold some memory until the program ends. Ie., they leak. Single transactions are also dog-slow, because it involves a full compilation step. Performance is so bad, that eg. executing 1+1 through TPython is waaaay faster than executing it on the Cling prompt (and unlike the latter, the former doesn't leak).

The original op_str was contributed from ROOT and used ROOT/meta's ToString(), which basically just uses Cling's printValue(). Looked innocent enough, so I accepted it, but after releasing it into the wild, complaints immediately started pouring in. So, I rewrote op_str to avoid calling ToString unless as a last resort. Still not good enough, so then I also rewrote ToString and there, as you can see from this last comment, I eventually threw up my hands and gave up:

// Otherwise use Cling's printValue (note: this is even slower and leakier, so no ...)
   /* std::string pv = fInterpreter->toString(type, obj);
   // can't reliably drop the last transaction here :/
   if (pv.find("@0x") == std::string::npos)
      return pv; */

(Yes, that fInterpreter->toString is the whole of ROOT's TCling::ToString() and I refuse to call it. ;) )

So that's why things are the way they are. What I don't understand then, is why operator<< fails here? My best guess would be that it's an overload resolution problem with the code as-written in CPyCppyy. (The most common reason why a reflection-based call fails where a compiled-based one succeeds.) I.e., it's the lookup that fails, not the call per se.

[wlav]

Oh actually, maybe the overload resolution fails for a known reason ... see my comment in op_str:

// TODO: the only reason this still exists, is b/c friend functions are otherwise not found

Wanting support for friends is also an ancient request.

[dpiparo]

I'd like to offer a trivial gist about jitting code and accumulate memory via LLVM bump allocator.
https://gist.github.com/dpiparo/b722347634681728de6f61fa9f63496e
There it is demonstrated that it's possible to avoid memory accumulation for value printing (TCling::ToString) by invoking the interpreter from within an ephemeral subprocess.

[wlav]

Stacked interpreters are closer to what is needed: compiler-research/CppInterOp#607

I haven't tried that new implementation, but I have an older prototype code that I wrote myself and which, in principle, works okay. My code just isn't safe enough (its use is very prescribed) to provide it through a public API (even though that's how I set it up, so I could call it from CPyCppyy and thus from Python), as side effects must be limited (it's fine to have side-effects, e.g. you could write something to stdout, just none that are related to the interpreter). But it would be usable for something like ToString().

[guitargeek]

I guess the most pragmatic and immediate solution to the problem is to pythonize std::string_view just like we're doing with std::string already. I have opened a PR for that.