diff mbox series

[PATCHv2,7/8] gdb/doc: add some notes on selecting suitable attribute names

Message ID fd6b6feb4eae79f99f9e3dddd5ba035f596c4872.1704901918.git.aburgess@redhat.com
State New
Headers
Series Python __repr__() methods and new __dict__ attributes |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 fail Testing failed
linaro-tcwg-bot/tcwg_gdb_check--master-arm fail Testing failed

Commit Message

Andrew Burgess Jan. 10, 2024, 3:54 p.m. UTC 
  In previous commits I've added Object.__dict__ support to gdb.Inferior
and gdb.InferiorThread, this is similar to the existing support for
gdb.Objfile and gdb.Progspace.

This commit extends the documentation to offer the user some guidance
on selecting good names for their custom attributes so they
can (hopefully) avoid conflicting with any future attributes that GDB
might add.

The rules I've proposed are:

  1. Don't start user attributes with a lower case letter, all the
  current GDB attributes start with a lower case letter, and I suspect
  all future attributes would also start with a lower case letter, and

  2. Don't start user attributes with a double underscore, this risks
  conflicting with Python built in attributes (e.g. __dict__) - though
  clearly the user would need to start and end with a double
  underscore, but it seemed easier just to say no double underscores.

I'm doing this as a separate commit as I've updated the docs for the
existing gdb.Objfile and gdb.Progspace so they all reference a single
paragraph on selecting attribute names.
---
 gdb/doc/python.texi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

Comments

Eli Zaretskii Jan. 10, 2024, 4:35 p.m. UTC | #1 
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: Andrew Burgess <aburgess@redhat.com>
> Date: Wed, 10 Jan 2024 15:54:44 +0000
> 
> In previous commits I've added Object.__dict__ support to gdb.Inferior
> and gdb.InferiorThread, this is similar to the existing support for
> gdb.Objfile and gdb.Progspace.
> 
> This commit extends the documentation to offer the user some guidance
> on selecting good names for their custom attributes so they
> can (hopefully) avoid conflicting with any future attributes that GDB
> might add.
> 
> The rules I've proposed are:
> 
>   1. Don't start user attributes with a lower case letter, all the
>   current GDB attributes start with a lower case letter, and I suspect
>   all future attributes would also start with a lower case letter, and
> 
>   2. Don't start user attributes with a double underscore, this risks
>   conflicting with Python built in attributes (e.g. __dict__) - though
>   clearly the user would need to start and end with a double
>   underscore, but it seemed easier just to say no double underscores.
> 
> I'm doing this as a separate commit as I've updated the docs for the
> existing gdb.Objfile and gdb.Progspace so they all reference a single
> paragraph on selecting attribute names.
> ---
>  gdb/doc/python.texi | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)

Thanks.

> +See @ref{choosing attribute names} for guidance on selecting a

Why not @xref?  And please add a comma after the right brace, there
are still old versions of Texinfo that insist on that.

> +See @ref{choosing attribute names} for guidance on selecting a
> +suitable name for new attributes.

Likewise.

> +See @ref{choosing attribute names} for guidance on selecting a
> +suitable name for new attributes.

And likewise.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Andrew Burgess Jan. 11, 2024, 10:48 a.m. UTC | #2 
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrew Burgess <aburgess@redhat.com>
>> Cc: Andrew Burgess <aburgess@redhat.com>
>> Date: Wed, 10 Jan 2024 15:54:44 +0000
>> 
>> In previous commits I've added Object.__dict__ support to gdb.Inferior
>> and gdb.InferiorThread, this is similar to the existing support for
>> gdb.Objfile and gdb.Progspace.
>> 
>> This commit extends the documentation to offer the user some guidance
>> on selecting good names for their custom attributes so they
>> can (hopefully) avoid conflicting with any future attributes that GDB
>> might add.
>> 
>> The rules I've proposed are:
>> 
>>   1. Don't start user attributes with a lower case letter, all the
>>   current GDB attributes start with a lower case letter, and I suspect
>>   all future attributes would also start with a lower case letter, and
>> 
>>   2. Don't start user attributes with a double underscore, this risks
>>   conflicting with Python built in attributes (e.g. __dict__) - though
>>   clearly the user would need to start and end with a double
>>   underscore, but it seemed easier just to say no double underscores.
>> 
>> I'm doing this as a separate commit as I've updated the docs for the
>> existing gdb.Objfile and gdb.Progspace so they all reference a single
>> paragraph on selecting attribute names.
>> ---
>>  gdb/doc/python.texi | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>
> Thanks.
>
>> +See @ref{choosing attribute names} for guidance on selecting a
>
> Why not @xref?  And please add a comma after the right brace, there
> are still old versions of Texinfo that insist on that.

We discussed this once before:

  https://inbox.sourceware.org/gdb-patches/83y1ib6j5x.fsf@gnu.org

TLDR: @xref doesn't add a 'See' prefix in info output.  Emacs works
around this when displaying an info output apparently.

But... I just don't care enough for such a detail, so I've switched to
@xref and added the missing comma.  I'll _try_ to remember to use @xref
in future.  Apologies when I inevitably forget -- but at least you know
why I keep reverting back now!

Updated patch is below.

Thanks,
Andrew

>
>> +See @ref{choosing attribute names} for guidance on selecting a
>> +suitable name for new attributes.
>
> Likewise.
>
>> +See @ref{choosing attribute names} for guidance on selecting a
>> +suitable name for new attributes.
>
> And likewise.
>
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>


---

commit 5c78b7b7f1cb9476c168f904b11883df29557a0b
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Wed Jan 10 15:42:55 2024 +0000

    gdb/doc: add some notes on selecting suitable attribute names
    
    In previous commits I've added Object.__dict__ support to gdb.Inferior
    and gdb.InferiorThread, this is similar to the existing support for
    gdb.Objfile and gdb.Progspace.
    
    This commit extends the documentation to offer the user some guidance
    on selecting good names for their custom attributes so they
    can (hopefully) avoid conflicting with any future attributes that GDB
    might add.
    
    The rules I've proposed are:
    
      1. Don't start user attributes with a lower case letter, all the
      current GDB attributes start with a lower case letter, and I suspect
      all future attributes would also start with a lower case letter, and
    
      2. Don't start user attributes with a double underscore, this risks
      conflicting with Python built in attributes (e.g. __dict__) - though
      clearly the user would need to start and end with a double
      underscore, but it seemed easier just to say no double underscores.
    
    I'm doing this as a separate commit as I've updated the docs for the
    existing gdb.Objfile and gdb.Progspace so they all reference a single
    paragraph on selecting attribute names.
    
    Reviewed-By: Eli Zaretskii <eliz@gnu.org>

diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 2eed332fe59..71ae012ee1c 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -3671,6 +3671,13 @@
 usual Python way.  This is useful if, for example, one needs to do
 some extra record keeping associated with the inferior.
 
+@anchor{choosing attribute names}
+When selecting a name for a new attribute, avoid starting the new
+attribute name with a lower case letter; future attributes added by
+@value{GDBN} will start with a lower case letter.  Additionally, avoid
+starting attribute names with two underscore characters, as these
+could clash with Python builtin attribute names.
+
 In this contrived example we record the time when an inferior last
 stopped:
 
@@ -4181,6 +4188,9 @@
 in the usual Python way.  This is useful if, for example, one needs to
 do some extra record keeping associated with the thread.
 
+@xref{choosing attribute names}, for guidance on selecting a suitable
+name for new attributes.
+
 In this contrived example we record the time when a thread last
 stopped:
 
@@ -5396,6 +5406,9 @@
 This is useful if, for example, one needs to do some extra record keeping
 associated with the program space.
 
+@xref{choosing attribute names}, for guidance on selecting a suitable
+name for new attributes.
+
 In this contrived example, we want to perform some processing when
 an objfile with a certain symbol is loaded, but we only want to do
 this once because it is expensive.  To achieve this we record the results
@@ -5556,6 +5569,9 @@
 This is useful if, for example, one needs to do some extra record keeping
 associated with the objfile.
 
+@xref{choosing attribute names}, for guidance on selecting a suitable
+name for new attributes.
+
 In this contrived example we record the time when @value{GDBN}
 loaded the objfile.
Eli Zaretskii Jan. 11, 2024, 10:56 a.m. UTC | #3 
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Thu, 11 Jan 2024 10:48:43 +0000
> 
> But... I just don't care enough for such a detail, so I've switched to
> @xref and added the missing comma.  I'll _try_ to remember to use @xref
> in future.  Apologies when I inevitably forget -- but at least you know
> why I keep reverting back now!
> 
> Updated patch is below.

Thanks.  As these are mechanical changes, the result must be okay.
diff mbox series

Patch

diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 2eed332fe59..40803274a27 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -3671,6 +3671,13 @@ 
 usual Python way.  This is useful if, for example, one needs to do
 some extra record keeping associated with the inferior.
 
+@anchor{choosing attribute names}
+When selecting a name for a new attribute, avoid starting the new
+attribute name with a lower case letter; future attributes added by
+@value{GDBN} will start with a lower case letter.  Additionally, avoid
+starting attribute names with two underscore characters, as these
+could clash with Python builtin attribute names.
+
 In this contrived example we record the time when an inferior last
 stopped:
 
@@ -4181,6 +4188,9 @@ 
 in the usual Python way.  This is useful if, for example, one needs to
 do some extra record keeping associated with the thread.
 
+See @ref{choosing attribute names} for guidance on selecting a
+suitable name for new attributes.
+
 In this contrived example we record the time when a thread last
 stopped:
 
@@ -5396,6 +5406,9 @@ 
 This is useful if, for example, one needs to do some extra record keeping
 associated with the program space.
 
+See @ref{choosing attribute names} for guidance on selecting a
+suitable name for new attributes.
+
 In this contrived example, we want to perform some processing when
 an objfile with a certain symbol is loaded, but we only want to do
 this once because it is expensive.  To achieve this we record the results
@@ -5556,6 +5569,9 @@ 
 This is useful if, for example, one needs to do some extra record keeping
 associated with the objfile.
 
+See @ref{choosing attribute names} for guidance on selecting a
+suitable name for new attributes.
+
 In this contrived example we record the time when @value{GDBN}
 loaded the objfile.