by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:10
    colombojrj opened #2276
  • 20:43
    fstuck123 commented #1628
  • 13:40
    cdyson37 commented #1566
  • 07:10
    kyamagu synchronize #2223
  • 06:23
    kyamagu synchronize #2223
  • 01:18
    rlake closed #2235
  • 01:18
    rlake commented #2235
  • 01:09
    kyamagu commented #2223
  • Jul 01 16:00
    bstaletic commented #2024
  • Jul 01 13:10
    wjakob commented #2223
  • Jul 01 01:44
    henryiii closed #2072
  • Jul 01 01:44
    henryiii commented #2072
  • Jul 01 01:04
    kyamagu commented #2223
  • Jul 01 00:42
    EricCousineau-TRI closed #2160
  • Jul 01 00:42
    EricCousineau-TRI commented #2160
  • Jul 01 00:34
    wjakob commented #2160
  • Jul 01 00:31
    EricCousineau-TRI commented #2160
  • Jun 30 23:53
    wjakob closed #1260
  • Jun 30 23:52
    wjakob commented #1260
  • Jun 30 23:37
    wjakob commented #1566
Yannick Jadoul
@YannickJadoul
Something returned from a function?
Jean-Baptiste Lespiau
@jblespiau
Yes. The function I am wrapping is f(const Nested<Obj*>& input) -> Nested<std::unique_ptr<Obj>>
Yannick Jadoul
@YannickJadoul
Since you have a custom caster that basically unwraps the Nested, it should work the same way as returning a pointer normally in pybind11, no?
Jean-Baptiste Lespiau
@jblespiau
(Sorry for not being that clear initially, and thanks for the help).
Yannick Jadoul
@YannickJadoul

Yes. The function I am wrapping is f(const Nested<Obj*>& input) -> Nested<std::unique_ptr<Obj>>

But what are the ownership semantics?

It's a new pointer you create in there?
Jean-Baptiste Lespiau
@jblespiau
I guess it would work with f(const Nested<Obj*>& input) -> Nested<Obj>?
Yes it's new
Yannick Jadoul
@YannickJadoul
Then I think this is fine, no?
You custom type_caster<...>::cast will take of the Nested part, probably, then recursively invoke the type caster of the thing inside Nested
So if that's a std::unique_ptr, pybind11 knows to take ownership, and give it to the create Python object?
Or am I still misunderstanding the problem?
Jean-Baptiste Lespiau
@jblespiau
I am trying something. I think it is just because my type_caster assumes a copyable T. Thus, when called with unique_ptr, it fails. it may simply be it.
Yannick Jadoul
@YannickJadoul
Because of here?
        for (const auto& item : nested.map()) {
          dict[pybind11::str(item.first.data())] = cast(item.second, policy, h);
        }
Jean-Baptiste Lespiau
@jblespiau
yes, and other places. I should likely move item.second
Yannick Jadoul
@YannickJadoul
Ah, yes
You can have a look at how some of the type_casters in cast.h work
Jean-Baptiste Lespiau
@jblespiau
Thanks, and sorry for taking your time, I will try to fix that.
Yannick Jadoul
@YannickJadoul
Things like the type_casters for tuples, etc also need to be able to handle move-only things, no?
Also, another option to avoid all this caster business would be to do it in two steps. First transform your C++ Nested type to C++ maps and vectors
Then just include stl.h and have pybind11 do the conversion to Python for you?
A bit more copying, probably, but the code will be simpler
Boris Staletic
@bstaletic
Or make everything a py::class_ so that you can avoid stl.h.
Kazunari Kudo
@kazunarikudo
Dear contributors, may I ask you a question? Does pybind11 support enum.IntEnum or enum.Enum?
Boris Staletic
@bstaletic

That's a question with a lot of history. You can get it to work manually, but that is pretty involved.

pybind/pybind11#781
pybind/pybind11#530

Kazunari Kudo
@kazunarikudo
@bstaletic Hi, Boris. Thank you for your reply. Would that mean it is technically possible to support them but it is not simple as it works in Python? I would appreciate it if you could tell me what the officials suggest to people who want to port enums to Python. Of course, I would assume a case where the way does not appear as either enum.Enum or enum.IntEnum but it is just a class that offers us its attributes as enum entries.
Boris Staletic
@bstaletic

Would that mean it is technically possible to support them but it is not simple as it works in Python?

That's right. There's a weird mix of backwards compatibility and feature parity with the current enum support that made the support for enum.IntEnum difficult.

what the officials suggest to people who want to port enums to Python.

There's a quite good support for that. Search the docs for py::enum_. The thing is that on the python side these won't be enum.Enum (or enum.IntEnum), but a pybind invented type.

Kazunari Kudo
@kazunarikudo
@bstaletic Thank you very much, Boris!
Marco Diers
@m-diers
i must call the function py::exec() several times at runtime. is there an example how i have to use the interpreter, locals and globals to avoid getting error messages like ImportError: generic_type: type "MyTuple" is already registered! ?
Yannick Jadoul
@YannickJadoul
Huh, is ImportError: generic_type: type "MyTuple" is already registered! thrown from inside a py::exec? That seems impossible, because it's an error coming from pybind11/C++
Boris Staletic
@bstaletic
Unless exec() is trying to register something? Or copy a registered py::class_ object.
Yannick Jadoul
@YannickJadoul
How could exec register something? It would be in Python? So it could only register something when calling back into a different part of C++, right?
(The copy is a distinct possibility, yes. But I'd first like to get some context/example before making any claim ;-) )
Marco Diers
@m-diers
oh thank you for the quick answers, i will make a small example
Marco Diers
@m-diers
this behavior doesn't occur in my example. i will now analyze...
Marco Diers
@m-diers
The PYBIND11_EMBEDDED_MODULE is implemented in a shared library, which can be reloaded several times at runtime. this is where the error comes from. is there a solution for this special case?
Boris Staletic
@bstaletic
Can you provide a minimal repro?
Yannick Jadoul
@YannickJadoul
@m-diers I still don't really get that, though
Normally, shared libraries are just loaded once
Boris Staletic
@bstaletic
You can do dynamic unloading, which is often problematic.
Yannick Jadoul
@YannickJadoul
Sure, but I'd expect it would be mentioned that that's happening, then
Marco Diers
@m-diers
yes there is also an unload
Yannick Jadoul
@YannickJadoul
Ah, well ...
Make sure you don't construct the same py::class_ twice. There's not much more we can say, I think
Marco Diers
@m-diers
thank you i will create an example, will contact you within the next days
harishes
@harishes

In my C++ project i have tested embedding the interpreter and running basic py::print() and py::import() commands from one my C++ class member functions. Next, I tried to add a simple embedded module, but ran into a duplicate definition error from linker. The following is the embedded module added to my header called MyAlgo2.hpp where a member function imports the embedded module.

#pragma once

#include <pybind11/embed.h>
namespace py = pybind11;

PYBIND11_EMBEDDED_MODULE(tcmb, m) {
    m.def("tcmbadd", [](int i, int j) { return i + j; });
}

namespace Algos
{

Below is error thrown from linker. There is the #pragma once defined in MyAlgo2.hpp. And main.cpp does not directly include MyAlgo2.hpp but through another header Algos.hpp which includes MyAlgo2.hpp.

[build] main.cpp.obj : error LNK2005: pybind11_init_impl_tcmb already defined in Algos.cpp.obj
[build] main.cpp.obj : error LNK2005: "struct pybind11::detail::embedded_module tcmb" (?tcmb@@3Uembedded_module@detail@pybind11@@A) already defined in Algos.cpp.obj

Any idea what could be wrong?

Boris Staletic
@bstaletic
Why are you defining the module in the header?
harishes
@harishes
@bstaletic at the very beginning of the header , before namespace and class definitions
crimsoncor
@crimsoncor
so that header is getting compiled into multiple objects
which is why linking is failing. Put the pybind11 code into a cpp file