wlav / cppyy

Other
384 stars 38 forks source link

String conversion different on different versions of python #205

Open sophiehourihane opened 6 months ago

sophiehourihane commented 6 months ago

I think the issue stems from different versions of python but honestly not 100% sure. My student just installed our bindings and was running into this issue.

we have this function in C++

std::map<std::string, WaveletBasis<SineGaussianWavelet>>& StandardModelCollection::getGlitchModel() {
  return glitchModel_;
}

We iterate over the output in python

    for ifoName, glitchBasis in modelCollection.getGlitchModel():
        print(type(ifoName), ifoName)

I get the output (using python 3.10), pip installed cppyy:

H1 <class cppyy.gbl.std.string at 0x7fc63e89d450>

whereas they are getting the output (using python 3.11), pip installed cppyy

 {'H', '1' } <class cppyy.gbl.std.basic_string<char,std::allocator<char>,std::allocator<char>> at 0x7f794cdf71b0> 

so definitely something has changed with how cppyy handles strings. Has anyone else run into this issue?

sophiehourihane commented 6 months ago

Using ifo = ifoName.c_str() fixed the issue, but I don't see why we should have to. They changed their environment to python 3.10 and have the same cppyy (and other cppyy dependencies) as me.

wlav commented 6 months ago

There's a bug somewhere in the backend that causes std::basic_string<char,std::char_traits<char>,std::allocator<char> > to be renamed std::basic_string<char,std::allocator<char>,std::allocator<char> >. I've never found the proximate cause, had a workaround for that for a while, and thought it was fixed with the recent update of Cling. Guess it's still kicking around somewhere.

(I do doubt that the different versions of Python matter. More likely different versions of cppyy or gcc on said systems?)