Skip to content

py::cast<T> where T is a subclass of py::object is unchecked #1108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ezyang opened this issue Sep 22, 2017 · 4 comments
Closed

py::cast<T> where T is a subclass of py::object is unchecked #1108

ezyang opened this issue Sep 22, 2017 · 4 comments

Comments

@ezyang
Copy link

ezyang commented Sep 22, 2017

Issue description

I expect something like py::cast<py::bytes>(x) to check if the py::object x is actually bytes. It does not.

Reproducible example code

#include <pybind11/pybind11.h>
#include <iostream>
namespace py = pybind11;
int main() {
  Py_Initialize();
  auto gil = PyGILState_Ensure();
  PyObject *l = PyFloat_FromDouble(3.14);
  //PyObject *l = PyBytes_FromString("foo");
  auto n = py::cast<py::bytes>(l);
  std::cerr << "No problem yet...\n";
  std::cerr << static_cast<std::string>(n);
  PyGILState_Release(gil);
  return 0;
}
@bstaletic
Copy link
Collaborator

For the record, Boost.Python behaves the same. Boost expects you to run n.check() before using n. Pybind instead provides py::isinstance<py::bytes>(n).

@YannickJadoul
Copy link
Collaborator

It can be considered as unexpected though. I'd vote for thinking this over, at least. I still get lost on when to use the constructor of such a subclass, or py::cast, or py::isinstance and a conversion method, or ...

@bstaletic
Copy link
Collaborator

This has been fixed in 2.6.0.

@YannickJadoul
Copy link
Collaborator

Should be #2349 that fixed this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants