* Revamp PyType name functions to match PEP 737
PyType::name uses `tp_name`, which is not consistent.
[PEP 737](https://peps.python.org/pep-0737/) adds a new path forward,
so update PyType::name and add PyType::{module,fully_qualified_name}
to match the PEP.
* refactor conditional code to handle multiple Python versions better
* return `Bound<'py, str>`
* fixup
---------
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
* Resolve references to legacy numerical constants and use the associated constants instead
* Suppress non_local_definitions lint as we often want the non-local effects in macro code
* graalpy: recognize graalpy implementation when building
* graalpy: global Ellipse, None, NotImplemented, True, and False are only available as pointers
* graalpy: PyObject struct is opaque, use functions for everything
* graalpy: missing many of the same functions as pypy
* graalpy: do not have 128bit conversion functions
* graalpy: add functions for datetime accessor macros
* graalpy: add implementations for list macro functions
* graalpy: skip tuple macros
* graalpy: always use extern Py_CompileString function
* graalpy: disable assertion that does not apply to graalpy
* graalpy: floatobject structure is opaque on graalpy
* graalpy: ignore gc dependent test
* graalpy: add CI config
* graalpy: run rust fmt
* graalpy: add changelog entry
* graalpy: discover interpreter on PATH
* graalpy: interpreter id is not applicable to graalpy (just like pypy)
* graalpy: skip tests that cannot work on GraalPy
* graalpy: fix constructing normalized Err instances
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
* graalpy: correct capi library name, but skip rust tests due to missing symbols
* graalpy: no support for C extensions on windows in latest release
* graalpy: declare support versions
* graalpy: frame, code, method, and function objects access from C API is mostly missing
* graalpy: take care only to expose C structure that GraalPy allocates
* graalpy: Bail out if graalpy version is less than what we support
---------
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
This API is available starting in 3.11. It is not part of the Stable ABI.
PyType_GetModuleByDef searches the MRO of the given type for a module
matching the given module spec. It can be useful for users use that
`pyo3_ffi` directly and want to support multiple interpreters/per
interpreter GIL. It is useful to obtain access to the module state from
special methods like `tp_new` that can't use the METH_METHOD calling
convention.
This API is not supported on PyPy yet, but guess the symbol name for the future.
David Hewitt