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

[steve-lorimer]

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.

[steve-lorimer]

Where in the docs please?

[wjakob]

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

[steve-lorimer]

How do I get support / ask questions?

[steve-lorimer]

@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).

[steve-lorimer]

@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)

[steve-lorimer]

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?