Pybind11: Unable to store std::string in py::dict

[skebanga]

The below sample application fails to compile

#include <pybind11/pybind11.h>

namespace py = pybind11;

int main()
{
    py::dict dict;
    std::string value = "bar";
    dict["foo"] = value;

    return 0;
}

The error returned is:

main.cpp:40:14: error: no match for ‘operator=’ (operand types are \
    ‘pybind11::detail::item_accessor \
        {aka pybind11::detail::accessor<pybind11::detail::accessor_policies::generic_item>}’ \
    and ‘std::__cxx11::string \
        {aka std::__cxx11::basic_string<char>}’)
  dict["foo"] = value;

How does one store a string in a dict?

[wjakob]

You'll need to use py::cast.

[skebanga]

Where in the docs please?

[wjakob]

You'll have to look for yourself -- please reserve tracker tickets for actual bugs or issues.

[skebanga]

How do I get support / ask questions?

[skebanga]

@wjakob How can I find out if my bug is an "actual bug", and not something else, without creating an issue?

[jagerman]

@skebanga - your report feels a bit like "I tried some random thing and it didn't work, help me," which isn't particularly useful when the documentation actually talks about this (hint: read the "Python C++ interface" section).

[skebanga]

@jagerman IMHO the docs are quite difficult to grok, my apologies for not finding it before being pointed out what to look for. The documentation itself even refers to the fact it's incomplete.

The intro says "Its goals and syntax are similar to the excellent Boost.Python library by David Abrahams"

In boost python you can assign a std::string. It seems like a very basic operation, which I assumed, given it's possible in boost python, should be possible in pybind11... hence creating the issue.

[dean0x7d]

@wjakob Have you considered adding something like a Gitter room as a more informal place to ask questions?

[wjakob]

The problem I see with that is that somebody very familiar with the library (i.e. a contributor like @dean0x7d , @jagerman, @aldanor, @pschella, @SylvainCorlay, ..., or myself) needs to actively monitor the room and respond to questions. I think that users mostly pop into these sort of chat rooms to ask a question and then disappear, meaning that by default there isn't generally a big community of like-minded users that will try to respond. That's an extra strain on the developers -- as for myself, I can say that I just won't have the time for it. If others are happy to participate, then why not.

[wjakob]

(Also, it provides a quick way for users to ask questions without RTFM, which causes useless work on our end)

[skebanga]

To be fair, I would RTFM if it was better structured, like cppreference for example, but at the moment it's very difficult to find the right way to do things

[SylvainCorlay]

We use gitter a lot in the Jupyter project.

• One big advantage is to provide an easy chat between developers e.g. while we are actively discussing a PR. Also, if it is active, some users may find quick answers...

• A big disadvantage is that it is very transient, and since I am in so many rooms, I tend to miss messages, or entire discussions that could have been important to me. So people should not always expect to get an answer and anything that deserves to have some more permanent record should be on github. That is also because jupyter has a large core team and millions of users...

[SylvainCorlay]

To be fair, I would RTFM if it was better structured, like cppreference for example, but at the moment it's very difficult to find the right way to do things

Then you should ask for a refund 😉

Neither the main author (Wenzel) or the other contributors are funded to work on pybind, so it is all work from volunteers who donate their time and skills.

[jagerman]

To come back to the original issue, is there a reason we don't want to allow dict[...]'s accessor (and likewise for list and whatnot) operator= to accept non-pyobject types, which would do an implicit cast on the argument?

[jagerman]

As for gitter, I'd participate (when able). I think it might also be valuable as a source of identifying the things that need to be documented: it's tricky to know, as someone familiar with pybind, what other people need to get going.

[dean0x7d]

@wjakob said:

(Also, it provides a quick way for users to ask questions without RTFM, which causes useless work the our end)

That's a fair point and definitely a concern. On the flip side, the chat is less formal so an unanswered question isn't as big of a deal as an open issue. The informal nature may also encourage others to participate in answering questions.

@jagerman said:

I think it might also be valuable as a source of identifying the things that need to be documented: it's tricky to know, as someone familiar with pybind, what other people need to get going.

Definitely this. After spending some time with the internals, it's easy to forget what's obvious and what's not.

Some parts of the docs are plainly lacking, like the Reference page which is incomplete and also outdated. I started tinkering with autogenerated reference docs with breathe, but stalled after hitting some bugs (and was also a bit burned out on the docs after the big reorg). I'll try to dust it off and propose something soon.

[wjakob]

To come back to the original issue, is there a reason we don't want to allow dict[...]'s accessor (and likewise for list and whatnot) operator= to accept non-pyobject types, which would do an implicit cast on the argument?

This would be fine, why not.

[aldanor]

To come back to the original issue, is there a reason we don't want to allow dict[...]'s accessor (and likewise for list and whatnot) operator= to accept non-pyobject types, which would do an implicit cast on the argument?

Yea, big +1, it's probably just been overlooked.

[jagerman]

@skebanga - take a look at PR #551: with it your original code should compile with needing an explicit py::cast.

[pschella]

Mailing lists. Yes they are lame and old fashioned. But they are archived, indexed by search engines and don't require active monitoring. Just my 2ct.

[wjakob]

FWIW: I've added a link to a Gitter chat room (https://gitter.im/pybind/Lobby) on the front page.