From: Tom Tromey <tom@tromey.com>
To: Matthieu Longo <matthieu.longo@arm.com>
Cc: <gdb-patches@sourceware.org>, Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH v2 4/9] gdb: add new helpers for retrieving a type's fully qualified name
Date: Tue, 03 Mar 2026 11:59:07 -0700 [thread overview]
Message-ID: <877brsrb7o.fsf@tromey.com> (raw)
In-Reply-To: <20260303161659.397427-5-matthieu.longo@arm.com> (Matthieu Longo's message of "Tue, 3 Mar 2026 16:16:54 +0000")
>>>>> Matthieu Longo <matthieu.longo@arm.com> writes:
> +/* Return the type's fully qualified name from a PyTypeObject. */
> +const char *
> +gdb_py_tp_name (PyTypeObject *py_type) noexcept
> +{
> +#if PY_VERSION_HEX >= 0x030d0000
...
> +#elif ! defined (Py_LIMITED_API)
...
> +#else
> + #error "The version of Python you are using does not expose " \
> + "PyType_GetFullyQualifiedName() as a part of the limited C API."
> +#endif
I think this case can't actually be hit... can it?
My reasoning is that the very first case is taken if either the limited
API is in use (which requires 0x030e0000 as of this patch) or if Python
is new enough.
So, all other cases fall into the non-limited case.
It would be better IMO to remove it if it cannot ever happen.
> +#else
> + #error "The version of Python you are using does not expose Py_TYPE() "\
> + "as a part of the limited C API."
I'd prefer that #error not be indented here.
> +++ b/gdb/python/py-obj-type.h
> @@ -0,0 +1,31 @@
> +/* Helpers related to Python object type
> +
> +/* Return the type's fully qualified name from a PyTypeObject. */
> +extern const char *
> +gdb_py_tp_name (PyTypeObject *py_type) noexcept;
> +
> +/* Return the type's fully qualified name from a PyObject. */
> +extern const char *
> +gdbpy_py_obj_tp_name (PyObject *self) noexcept;
Declarations in gdb don't have a newline after the return type.
thanks,
Tom
next prev parent reply other threads:[~2026-03-03 18:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 16:16 [PATCH v2 0/9] gdb: more fixes for Python limited C API support Matthieu Longo
2026-03-03 16:16 ` [PATCH v2 1/9] gdb: switch tuple object helpers to Python limited API equivalents Matthieu Longo
2026-03-03 18:09 ` Tom Tromey
2026-03-03 16:16 ` [PATCH v2 2/9] gdb: introduce rgb_color type to simplify existing code Matthieu Longo
2026-03-03 18:16 ` Tom Tromey
2026-03-04 16:30 ` Matthieu Longo
2026-03-03 16:16 ` [PATCH v2 3/9] gdb: switch bytes object helpers to Python limited API equivalents Matthieu Longo
2026-03-03 18:03 ` Tom Tromey
2026-03-03 16:16 ` [PATCH v2 4/9] gdb: add new helpers for retrieving a type's fully qualified name Matthieu Longo
2026-03-03 18:59 ` Tom Tromey [this message]
2026-03-06 17:49 ` Matthieu Longo
2026-03-06 19:45 ` Tom Tromey
2026-03-03 16:16 ` [PATCH v2 5/9] gdb/python: allow ref_ptr<T, Policy>::new_reference to accept subclasses of T Matthieu Longo
2026-03-03 18:18 ` Tom Tromey
2026-03-04 16:56 ` Matthieu Longo
2026-03-04 18:55 ` Tom Tromey
2026-03-06 11:37 ` Matthieu Longo
2026-03-06 11:43 ` Matthieu Longo
2026-03-06 16:47 ` Tom Tromey
2026-03-09 11:38 ` Matthieu Longo
2026-03-03 16:16 ` [PATCH v2 6/9] gdb/python: flatten functions calling PyObject_New and use gdbpy_ref Matthieu Longo
2026-03-03 18:22 ` Tom Tromey
2026-03-09 11:41 ` Matthieu Longo
2026-03-03 18:22 ` Tom Tromey
2026-03-03 16:16 ` [PATCH v2 7/9] gdb/python: accept gdbpy_ref in init helpers and return bool Matthieu Longo
2026-03-03 18:24 ` Tom Tromey
2026-03-09 13:25 ` Matthieu Longo
2026-03-03 16:16 ` [PATCH v2 8/9] gdb/python: add gdbpy_dict_wrapper:allocate_dict helper Matthieu Longo
2026-03-03 18:30 ` Tom Tromey
2026-03-06 12:03 ` Matthieu Longo
2026-03-03 16:16 ` [PATCH v2 9/9] gdb/python: add accessor helpers for __dict__ in Python extension objects Matthieu Longo
2026-03-03 19:02 ` Tom Tromey
2026-03-06 14:33 ` Matthieu Longo
2026-03-06 16:04 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877brsrb7o.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=matthieu.longo@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox