-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add anyset & frozenset, enable copying (cast) to std::set #3901
Changes from 8 commits
e828031
f2db7bb
ef92aa5
736f293
faf8a51
05b6147
26a29f4
0cf2cae
c63ca46
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -1784,25 +1784,37 @@ class kwargs : public dict { | |||
PYBIND11_OBJECT_DEFAULT(kwargs, dict, PyDict_Check) | ||||
}; | ||||
|
||||
class set : public object { | ||||
class anyset : public object { | ||||
protected: | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay, last concern. Why is the scope here protected? I don't see any other Pytypes doing that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Specifically, I am worried it might interfere with the static "check_" method that isinstance is suppose to be using. pybind11/include/pybind11/pytypes.h Line 483 in e8e229f
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good question, it turns out the (Note that there is an I think it's best to not get fancy here and to simply remove the
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops, yes. Removed. |
||||
PYBIND11_OBJECT(anyset, object, PyAnySet_Check) | ||||
|
||||
public: | ||||
size_t size() const { return static_cast<size_t>(PySet_Size(m_ptr)); } | ||||
bool empty() const { return size() == 0; } | ||||
template <typename T> | ||||
bool contains(T &&val) const { | ||||
return PySet_Contains(m_ptr, detail::object_or_cast(std::forward<T>(val)).ptr()) == 1; | ||||
} | ||||
}; | ||||
|
||||
class set : public anyset { | ||||
public: | ||||
PYBIND11_OBJECT_CVT(set, object, PySet_Check, PySet_New) | ||||
set() : object(PySet_New(nullptr), stolen_t{}) { | ||||
PYBIND11_OBJECT_CVT(set, anyset, PySet_Check, PySet_New) | ||||
set() : anyset(PySet_New(nullptr), stolen_t{}) { | ||||
if (!m_ptr) { | ||||
pybind11_fail("Could not allocate set object!"); | ||||
Skylion007 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||
} | ||||
} | ||||
size_t size() const { return (size_t) PySet_Size(m_ptr); } | ||||
bool empty() const { return size() == 0; } | ||||
template <typename T> | ||||
bool add(T &&val) /* py-non-const */ { | ||||
return PySet_Add(m_ptr, detail::object_or_cast(std::forward<T>(val)).ptr()) == 0; | ||||
} | ||||
void clear() /* py-non-const */ { PySet_Clear(m_ptr); } | ||||
template <typename T> | ||||
bool contains(T &&val) const { | ||||
return PySet_Contains(m_ptr, detail::object_or_cast(std::forward<T>(val)).ptr()) == 1; | ||||
} | ||||
}; | ||||
|
||||
class frozenset : public anyset { | ||||
public: | ||||
PYBIND11_OBJECT_CVT(frozenset, anyset, PyFrozenSet_Check, PyFrozenSet_New) | ||||
}; | ||||
|
||||
class function : public object { | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure about the changes on the caster: So without a default ctor, this ctor is needed on pyobject_caster? At the very least, we should have a comment about why there are necessary. I am also worried that there are edge cases where this might break when it is used in downstream applications.
Thoughts @rwgk @henryiii
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC we have a choice:
anyset
andfrozenset
default constructible.I agree but think it is not just "still safe" but actually safer: if the previously default-constructed object is accidentally used the symptoms could be highly confusing (silent failures). A noisy failure (segfault b/o nullptr) seems better.
I'll run our (Google's) global testing with this PR to see if there are breakages and report back here. I might have the results only tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No breakages! This PR is great. If anyone was previously relying on the default-constructed
value
, they will probably be glad to see that exposed as an obvious bug now.