Skip to content

Conversation

@rruuaanng
Copy link
Contributor

@rruuaanng rruuaanng commented Nov 2, 2024

Similar to #92262. I think we should fix this (by setting tp_iter to None) but only on the main branch in case people rely on calling next() on a pointer object.

cc @JelleZijlstra

Since it is implemented in an extension, I added an exception when getting it. Do you think?


📚 Documentation preview 📚: https://cpython-previews--126318.org.readthedocs.build/

@rruuaanng rruuaanng changed the title gh-92347: Error when adding convert gh-92347: Throw a warning when converting a pointer to an iterator Nov 2, 2024
@rruuaanng
Copy link
Contributor Author

rruuaanng commented Nov 2, 2024

It actually kind of overwhelmed me, the added exception also caused the CI to fail.

from test_ctypes/test_values.py

        class struct_frozen(Structure):
            _fields_ = [("name", c_char_p),
                        ("code", POINTER(c_ubyte)),
                        ("size", c_int),
                        ("is_package", c_int),
                        ]
        FrozenTable = POINTER(struct_frozen)

        modules = []
        for group in ["Bootstrap", "Stdlib", "Test"]:
            ft = FrozenTable.in_dll(pythonapi, f"_PyImport_Frozen{group}")
            # ft is a pointer to the struct_frozen entries:
            for entry in ft:
                # This is dangerous. We *can* iterate over a pointer, but
                # the loop will not terminate (maybe with an access
                # violation;-) because the pointer instance has no size.
                if entry.name is None:
                    break

Do note that indexed access to pointer objects is a documented (and useful) behavior. It would be quite surprising to have a sequence-like object raise an exception when used in a for loop, typing constructs notwithstanding.
Perhaps a note in the Pointers section mentioning the unbounded behavior when iterating aka an infinite generator.

Maybe we can just change the document.

@erlend-aasland
Copy link
Contributor

Please do not propose PRs prematurely like this. Moreover, test your changes locally before proposing the fix. If you are uncertain how the CI will react, test your changes using a PR on your own fork first.

@rruuaanng rruuaanng deleted the gh92347 branch November 5, 2024 10:20
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

Successfully merging this pull request may close these issues.

2 participants