List of minor issues and fixes for pybind 3.0

pybind / pybind11

Seamless operability between C++11 and Python

https://pybind11.readthedocs.io/

Other

15.59k stars 2.09k forks source link

List of minor issues and fixes for pybind 3.0 #2609

Open YannickJadoul opened 3 years ago

YannickJadoul commented 3 years ago

pybind 3.0 might still take a while, but it's good to start thinking what API-breaking changes we need to introduce, by that time. I've created a milestone v3.0.0, but to reduce cluttering the issues, minor things can also be commented and listed here:

[ ] Remove deprecations
- [ ] PYBIND11_PLUGIN (since 2.2)
- [ ] object::operator== (since 2.2)
- [ ] base<T>()
- [ ] error_already_set.clear() (since 2.2)
- [ ] py::object::borrowed & py::object::stolen (since 2.2)
- [ ] obj.attr(...) as bool (since 2.0)
- [ ] handle::call() (since 2.0). - really, everything listed here that was deprecated in 2.0

Suggestions and additions very welcome!

bstaletic commented 3 years ago

Should we change object::operator== to mean object::equals?

YannickJadoul commented 3 years ago

Should we change object::operator== to mean object::equals?

Or that. But that might be dangerous? I mainly just wanted to list sómething; all of this can still be dicussed ;-)

sizmailov commented 3 years ago

I wounder if #2244 has any chance to get into v3.0.

YannickJadoul commented 3 years ago

I wounder if #2244 has any chance to get into v3.0.

When it comes to changes to the API, sure. However, it seems like there were also objections by @wjakob against the complexity added by this?

sizmailov commented 3 years ago

Sorry for bringing it up once again after definitive "NO" from Jakob. I was hoping it has a bit more chances in context of v3.0.

(I believe the complexity associated with the PR is the minimum that required to deliver the feature. Namely, it's only type caster specializations + verbose explicit types (for C++-11 compatibility). If it's still too much, let be it. In this case it might (should) be read as "annotation-related features are not welcome until v4.0.")

YannickJadoul commented 3 years ago

Sorry for bringing it up once again after definitive "NO" from Jakob. I was hoping it has a bit more chances in context of v3.0.

(I believe the complexity associated with the PR is the minimum that required to deliver the feature. Namely, it's only type caster specializations + verbose explicit types (for C++-11 compatibility). If it's still too much, let be it. In this case it might (should) be read as "annotation-related features are not welcome until v4.0.")

No, don't worry. I would maybe find it interesting, but I'm just warning you that this one might be more tricky than just "Yes, bring it on, now that we can break stuff!" :-) It doesn't look all too complex to me, but then that's just me, ofc :-)