M.-A. Lemburg writes: > Shouldn't 'in' be a slot of the sequence methods ? I'd suggest > creating a new tp_flag bit and then extending tp_as_sequence Only if we want to restrict set-like behavior to sequences, and I don't think that's clear, though it does mirror the current situation. Regardless of the location of the slot, why should a flag be needed? Testing the slot for NULL is necessary to avoid core dumps anyway. > plus of course add an abstract function to abstract.c: > > PySequence_Contain(PyObject *container, PyObject *element) There's already PySequence_In(...); see: http://www.python.org/doc/current/api/sequence.html#l2h-135 I'm inclined to add PyObject_In(...) (or ..._Contains(); I like Contains better than In, but there's precedence for In and that's more important) and define the new slot on the Object using one of the reserved spaces. That allows a clean interface for "pure" sets that don't have to "look like" sequences or mappings. > which uses the above slot after testing the tp_flag setting. > Python instances, lists, tuples should then support this new > slot. We could even sneak in support for dictionaries once we > decide whether semantics whould be Bait! -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
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