robot-name approach: fix typos, minor rephasing/improvements

[petrem]

• Fixed a few typos.
• Rephrased here and there where I subjectively thought it useful. Please let me know if they're undesirable.
• Expanded some contractions - this might help non-native speakers.
• When another approach is mentioned, added link to it - hopefully this is useful rather than an distraction
• I thought the explanation about the alternative to using the walrus operator was not clear, so rephrased and added a code snippet. I hope this is useful.

Additionally, the phrase

We call `reset` from `__init__` - it is syntactically valid to do it the other way around, but it is not considered good practice to call [dunder methods][dunder-methods] directly.

seems misleading to me: calling __init__ from other methods seems to me significantly worse than calling other dunder methods, as it may lead to future bugs.
Arguably, for tooling support, we should assign to self.name in __init__() explicitly:

def __init__(self):
    self.name = self._get_new_name()
def reset(self):
    self.name = self._get_new_name()
def _get_new_name(self):
     ...  # what reset() did

but this looks ugly and confusing.

[BethanyG]

A few nits (some contractions you missed), and a few rewordings that came to mind as I reviewed. Overall, though -- this is great! This is certainly within what I had in mind, and I wouldn't mind if you had more to add or more edits (at least for the approaches I wrote 😄 ). Let me know if you prefer comments or "request changes". I typically do comments or approval and leave you to take my suggestions ... or not.

[kotp]

Great start... a couple of nits for style.

[kotp]

Style suggestion:

Blank line after headings (currently missing).

Tend to trailing white space, there are two occurrences where this happens... I will mention in review here.

[petrem]

Would it be OK if I also added blank lines before/after the code snippets in the markdowns? It should not make a difference when rendered, but I find it easier to read and edit the markdown that way -- is that something that works for everybody or just my personal quirk?

[BethanyG]

Would it be OK if I also added blank lines before/after the code snippets in the markdowns?

Please do. Not just your quirk: mine as well. Didn't do it on my first pass, because I didn't want to bog things down. But absolutely!

[kotp]

Suggested change

	def __init__(self):
	self.reset()
	def __init__(self):
	self.reset()

There is at least one other trailing white space lurking that is similar to the above...

[petrem]

Thanks, I dealt with trailing whitespace and lines after headings in one commit.

[petrem]

Thanks everyone for comments and suggestions!

A few nits (some contractions you missed), and a few rewordings that came to mind as I reviewed.

Thanks!

There still are a few contractions. I find some of the more common ones, like "isn't" or "won't", to be useful. They "roll down well", and make the tone a bit of a less formal.

But please let me know if the agreed style/wisdom is to not use contractions at all, or seldom, or ...

While looking at the text again, I found this one that might not be grammatically correct, but as I didn't study grammar I'm not sure:

ensure that it's not been previously used 

I think this should read, perhaps, "ensure that it hasn't been ...".

Overall, though -- this is great! This is certainly within what I had in mind, and I wouldn't mind if you had more to add or more edits (at least for the approaches I wrote 😄 ).

Thanks :-)

Let me know if you prefer comments or "request changes". I typically do comments or approval and leave you to take my suggestions ... or not.

This may sound strange, but I don't think I actually know the difference. I'm not too familiar with github core reviews. I worked a lot with bitbucket and just very occasionally with github and gitlab. In general, please do as you think it is more appropriate or whatever is more convenient.

[BNAndras]

ensure that it's not been previously used
“it’s” can be short for “it is” or “it has” since both end in s. The reader would need additional context to pick “it has” which is provided by “been” so the action occurred at an unspecified time in the past. Contracting “has not” instead of “it has” would make that a bit clearer up front.

[petrem]

“it’s” can be short for “it is” or “it has” since both end in s.

oh, 'tis right, only I'd stopped for a second and thunk..

[BethanyG]

@petrem - than you so much for taking this on! Give a head's up when you are "done done", and I can give things a quick once-over and then merge. 😄

[petrem]

@BethanyG thank you for reviewing, I'm done (unless new evidence to the contrary is surfaced).

[kotp]

On 25/12/21 03:26AM, PetreM wrote: @petrem commented on this pull request. > @@ -1,5 +1,5 @@ Would it be OK if I also added blank lines before/after the code snippets in the markdowns? It should not make a difference when rendered, but I find it easier to read and edit the markdown that way -- is that something that works for everybody or just my personal quirk?

Not only OK, it would be preferred.

[kotp]

On 25/12/21 03:50AM, PetreM wrote: @petrem commented on this pull request. > def __init__(self): self.reset() Thanks, I dealt with trailing whitespace and lines after headings in one commit.

Thanks!