Greg Ewing wrote: > Attaching some kind of type info to a CObject and having > an easy way of checking it makes sense to me. If the > existing CObject API can't be changed, maybe a new > enhanced one could be added. I thought the entire *point* of C object was that it's an opaque box without any info whatsoever, except that which is known and shared by its creator and its consumer. If we're adding type information, then please make it a Python object rather than a C string. That way the creator and the consumer can use a richer API to query the "type", such as by calling its methods or by inspecting it in some other way. Instead of comparing strings with strcmp, it could use PyObject_RichCompareBool, which would allow a much more flexible way to define "types". Using a PyObject also ensures that the lifecycle of the attached "type" is managed by the well-understood reference-counting mechanism.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4