> Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> >ite is the -te form (in some uses like a gerundium) of aru
> >(to go, to walk)
>
> This form, "行って", is written with two "t", as "itte",
> in many transcriptions to convey the gemination (っ) of
> the "t". There is, however, "ite", "居て", the -te form of
> "居る" ("iru" - "to be"), which usually is transcribed "ite".

I stand corrected, thanks. Not the first time that ite/itte
slipped :-/

At any rate, it, eh, is rather malleable to word play.

Karsten

Names can be taken too far as the same variable may have different
connotations in one place than another.

Say I am counting how many of something and incrementing variable HowMany as
I go along and initialized to zero. Then I want to test if I have any and
instead of:

if (HowMany > 0)

I decide to be cute and depend on the truthiness of HowMany like:

if (HowMany)

The latter is a tad hard to parse for some people and if it had been named
WeHaveAny then the code would sort of make sense:

if (WeHaveAny)

Somewhere else in the code some other names might make sense and make the
program easier to read.

So, the obvious solution is to ask the language, like Python, to allow
variables that are synonyms. In languages with pointers, this can often be
done fairly easily. In some languages with some optimizations, it can be
dangerous as some copies of this kind can later be changed to an actual copy
when the underlying data changes.

So, since at the moment you might not be able to do this:

HowMany = 0
alias HowMany WeHaveAny

Then if this feature matters to you, you could cautiously write code that
declares a second variable and copies either the current value of the first
or a Boolean true/false.

I am sure many of us (meaning me) have often named a variable and later
reconsidered once we saw the role it plays in various parts of the program
and had to go back and change everything. As other have noted, it is not a
trivial task and really good names often end up being really long names
which are also a pain especially when other really long names start with the
same characters. Compilers don't care but humans reading the code may give
up!

Worse, many times the code consists of longer combinations and trying to
keep within reasonable (printable) line lengths gets hard.

MyHumoungousDictionaryContainingElectionResults[SomeCountyInSomeStateOfTheUS
] =
MyHumoungousDictionaryContainingElectionResults[SomeCountyInSomeStateOfTheUS
] + TheOfficialCertifiedVoteCountOfThisRegion

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Karsten Hilbert
Sent: Thursday, October 28, 2021 2:50 AM
Cc: python-list@python.org
Subject: Aw: Re: The task is to invent names for things

> > I don't know. A mediocre name conveys at least some information, and
> > that seems to be better than none. On the other hand it might be
> > just enough to lead the reader astray which wouldn't happen with a
> > non-sensical name.

I was thinking that a nonsensical name might lead readers to go beyond the
name when trying to understand code, and would prompt me to improve upon the
name upon reading my own code (and having acquired, likely, a better
understanding of the concept that's to be named).

Karsten

--
https://mail.python.org/mailman/listinfo/python-list

"Avi Gross" <avigross@verizon.net> writes:
>if (WeHaveAny)

|Function names should be lowercase, with words separated by
|underscores as necessary to improve readability.
|Variable names follow the same convention as function names.
PEP 8 (2019)

The name should not be "optimized" for a certain use case
(as for the use in an if expression) only. "We", "have",
and "any" carry little information. A name should pack as
much information as possible in as least characters as
possible. So, for me, it'd be something like:

if word_count:

.

>So, the obvious solution is to ask the language, like Python, to allow
>variables that are synonyms.

Programs already have too many names in them.
There is no need to add even more, especially
when they equivalent, and the average human can
only hold 7 ± 2 objects (like names) in his short-
term memory.

>really good names often end up being really long names

If they are really long, they are not really good,
/except/ when they have a really large scope.

Names for a small scope can and should be short,
names for a large scope may be longer.

Some very short names have traditional meanings
and are ok when used as such:

for i in range( 10 ):

. And, as a "golden rule" for refactoring, I'd say:
When you see:

i = 0 # word count

, then remove the comment and rename "i" to "word count"!

IMHO, I prefer really weird names.

For example if I'm not sure how to name a class that I'm coding, I name it
like XXXYYY (literally). Really ugly.

This is a way to avoid the so called "naming paralysis".

Once I finish coding the class I look back and it should be easy to see "what
it does" and from there, the correct name.

If the "what it does" results in multiple things I refactor it, splitting it
into two or more pieces and name each separately.

Some people prefer using more generic names like "Manager", "Helper",
"Service" but those names are problematic.

Yes, they fit in any place but that's the problem. If I'm coding a class and I
name it as "FooHelper", I may not realize later that the class is doing too
many things (unrelated things), because "it is a helper".

The thing gets wrong with the time; I bet that most of us saw a "Helper" class
with thousands of lines (~5000 lines was my record) that just grows over time.

On Wed, Oct 27, 2021 at 12:41:56PM +0200, Karsten Hilbert wrote:
>Am Tue, Oct 26, 2021 at 11:36:33PM +0000 schrieb Stefan Ram:
>
>> xyzzy = lambda x: 2 * x
>>
>> . Sometimes, this can even lead to "naming paralysis", where
>> one thinks excessively long about a good name. To avoid this
>> naming paralysis, one can start out with a mediocre name. In
>> the course of time, often a better name will come to one's mind.
>
>In that situation, is it preferable to choose a nonsensical
>name over a mediocre one ?
>
>Karsten
>--
>GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
>--
>https://mail.python.org/mailman/listinfo/python-list

Supersedes: <names-20211028185041@ram.dialup.fu-berlin.de>
[corrected two typos]

"Avi Gross" <avigross@verizon.net> writes:
>if (WeHaveAny)

|Function names should be lowercase, with words separated by
|underscores as necessary to improve readability.
|Variable names follow the same convention as function names.
PEP 8 (2019)

The name should not be "optimized" for a certain use case
(as for the use in an if expression) only. "We", "have",
and "any" carry little information. A name should pack as
much information as possible in as least characters as
possible. So, for me, it'd be something like:

if word_count:

.

>So, the obvious solution is to ask the language, like Python, to allow
>variables that are synonyms.

Programs already have too many names in them.
There is no need to add even more, especially
when they are equivalent, and the average human can
only hold 7 ± 2 objects (like names) in his short-
term memory.

>really good names often end up being really long names

If they are really long, they are not really good,
/except/ when they have a really large scope.

Names for a small scope can and should be short,
names for a large scope may be longer.

Some very short names have traditional meanings
and are ok when used as such:

for i in range( 10 ):

. And, as a "golden rule" for refactoring, I'd say:
When you see:

i = 0 # word count

, then remove the comment and rename "i" to "word_count"!

On Thursday, 28 October 2021 at 19:24:10 UTC+2, Avi Gross wrote:

> I am sure many of us (meaning me) have often named a variable and later
> reconsidered once we saw the role it plays in various parts of the program
> and had to go back and change everything.

The best practice is as best as reasonably possible, which does cover the above (though, should you really have to "change everything", that's again rather a "smell"). And the fact that people will rather build on top of it instead of fixing it later is a totally common fact in nowadays production.

> As other have noted, it is not a
> trivial task and really good names often end up being really long names
> which are also a pain especially when other really long names start with the
> same characters. Compilers don't care but humans reading the code may give
> up!

Very long names are *not* good names...

Julio

In comp.lang.python, Julio Di Egidio <julio@diegidio.name> wrote:
> The best practice is as best as reasonably possible, which does cover
> the above (though, should you really have to "change everything", that's
> again rather a "smell"). And the fact that people will rather build on
> top of it instead of fixing it later is a totally common fact in
> nowadays production.

That just restates the problem. "The best practice is to do a good job."

> On Thursday, 28 October 2021 at 19:24:10 UTC+2, Avi Gross wrote:
>> As other have noted, it is not a
>> trivial task and really good names often end up being really long names
>> which are also a pain especially when other really long names start with the
>> same characters.

I'm usually not thrown by starting with the same string, but start
and end with the same string, with different things in the middle,
then it begins to trip me up.

>> Compilers don't care but humans reading the code may give up!

Modern compilers don't care. I've certainly come across code written
with "must be unique in the first N characters" for N somewhere in
8 to 32.

> Very long names are *not* good names...

I remember that book.

https://en.wikipedia.org/wiki/Tikki_Tikki_Tembo

Hard to recommend it now since it takes a Japanese story, puts it in
China, but uses English nonsense for the name instead of Chinese (or
Japanese) syllables.

Elijah
------
not to be confused with Kipling's mongoose story

On Thursday, 28 October 2021 at 21:55:10 UTC+2, Eli the Bearded wrote:
> In comp.lang.python, Julio Di Egidio <ju...@diegidio.name> wrote:
> > The best practice is as best as reasonably possible, which does cover
> > the above (though, should you really have to "change everything", that's
> > again rather a "smell"). And the fact that people will rather build on
> > top of it instead of fixing it later is a totally common fact in
> > nowadays production.
>
> That just restates the problem. "The best practice is to do a good job."

No, it doesn't, you just miss the context and the point. I initially said:

"Take your time and do choose a proper name in any case (the best you can)"

and that is totally general and a best practice, period. As the rest of what I said.

> > Very long names are *not* good names...
>
> I remember that book.

I could actually explain it technically. Just not today, not to those who can't even actually read.

Have fun,

Julio

Stefan,

I choose not to get involved in a discussion about arbitrary naming rules as many languages and programmers have their own ideas and preferences and rules.

My examples were EXAMPLES and the actual names are irrelevant. Feel free not to use them and I assure you I have no plans to either.

My POINT was that people choose names as being descriptive in many ways, often unique to themselves or to their organizations. A name that may be considered quite useful and explanatory in one context is not in another. Specifically, names chosen using American English may mean little if looked at by programmers elsewhere or if they are chosen with a sense of humor or the like, may not make sense to those who are not in on the ideas involved. Naming a variable PINK (in any combination of upper or lower case you feel like may make you think it fits when using it to count Breast Cancer patients but many will have no idea why you chose that.

I strenuously disagree with many things you quote as being obviously true. Nonsense! Programs need whatever number of variables they need. There is no reason you must reuse the same variable of "i" or "index" for every loop nor why it must be different every time. Nor must names lengths be determined by the length of scopes. You are quoting, presumably, from some document outlining what a corporation or University or such are doing to try to get a consistency across their programmers. Fine, I have seen multiple CONTRADICTORY such declarations and it is often a matter of taste. In some languages I use periods in longer variable names and in others I use underscores and many times I use camelCase, Hungarian notation and others. The compiler and interpreter generally do NOT care.

To bring this back to python, does it have any serious rules or informal ones as compared to others? I have seen places that suggest constants be all CAPS and Classes should be capitalized and regular variables never capitalized and endless variations on such themes. I have seen places they suggest adding parts to names such as the units so you have xxxDollars versus xxxFeet or where they want each variable to contain a similar suffix (or prefix) specifying the type of the object such as int or char or objectXY as one way to make things clearer or help prevent errors. There are MANY schools of thought and I suggest no one right way.

My thought was that no matter what methodology for naming you have, it may not work quite well if the same variable is used in contexts ranging from does it currently exist, how much does it hold, is it "true" as in non-empty, or the value it has when switched to another form of measurement. It is common often to encapsulate something into an object and then use instance variables or functions to address it different ways. So an object called incomedata might be used as incomedata.count in one context and incomedata.nonempty() in another. That is not the same as my talking about synonyms. And note many languages allow you to create somewhat dynamic synonyms such as a view of a subset of something like an array using another variable and allowing it to represent the current state of the main data structure or even change selected parts. It is not at all a foreign concept to have multiple names point to the same things. Often, it helps make the code clearer.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On Behalf Of Stefan Ram
Sent: Thursday, October 28, 2021 2:07 PM
To: python-list@python.org
Subject: Re: The task is to invent names for things

Supersedes: <names-20211028185041@ram.dialup.fu-berlin.de>
[corrected two typos]

"Avi Gross" <avigross@verizon.net> writes:
>if (WeHaveAny)

|Function names should be lowercase, with words separated by underscores
|as necessary to improve readability.
|Variable names follow the same convention as function names.
PEP 8 (2019)

The name should not be "optimized" for a certain use case
(as for the use in an if expression) only. "We", "have",
and "any" carry little information. A name should pack as
much information as possible in as least characters as
possible. So, for me, it'd be something like:

if word_count:

.

>So, the obvious solution is to ask the language, like Python, to allow
>variables that are synonyms.

Programs already have too many names in them.
There is no need to add even more, especially
when they are equivalent, and the average human can
only hold 7 ± 2 objects (like names) in his short-
term memory.

>really good names often end up being really long names

If they are really long, they are not really good,
/except/ when they have a really large scope.

Names for a small scope can and should be short,
names for a large scope may be longer.

Some very short names have traditional meanings
and are ok when used as such:

for i in range( 10 ):

. And, as a "golden rule" for refactoring, I'd say:
When you see:

i = 0 # word count

, then remove the comment and rename "i" to "word_count"!

--
https://mail.python.org/mailman/listinfo/python-list

On Friday, 29 October 2021 at 01:12:40 UTC+2, Avi Gross wrote:
> Stefan,
>
> I choose not to get involved in a discussion about arbitrary naming rules as many languages and programmers have their own ideas and preferences and rules.

The majority of people in this area for the most part are simply and utterly incompetent, so incompetent that you can't even guess how incompetent you are, nor you can see competence when you encounter it.

Because building software is *the most complex engineering that there is*: add to that the sorry state of an entire industry thanks to 25+ years of the fake agility and the most insane speculations ad nauseam.

> My POINT

You should just shut up and learn for a change (from me of course, not from some other fraudulent wannabe such as Stefan). But that is sci-fi of course, you stupid cunts rather take any advice as a personal insult...

Fuck off you and the permanent shithole for everybody.

(EOD.)

Julio

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>Some very short names have traditional meanings
>and are ok when used as such:

Since this is comp.lang.python, one might add that a special
property of Python is that several common words already are
taken by the language or library.

list
set
pass
as
is
....

The standard solution is to add an underscore when one wants
to use such words as names.

list_
set_
pass_
as_
is_
....

As a kind of a metonymy, classes are often named like their
objects. For example, "list" is not /a/ list, but the /class/
of lists. When one writes:

list = list()

, this then will hide the name for the class by the name of
one of its object. Recently, I have been naming some classes
with names ending in "_class", so that I can write, for example,

text = text_class()

.

On Thu, 28 Oct 2021 00:41:41 +0200, Peter J. Holzer wrote:

> On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote:
>> Am Tue, Oct 26, 2021 at 11:36:33PM +0000 schrieb Stefan Ram:
>> > xyzzy = lambda x: 2 * x
>> > . Sometimes, this can even lead to "naming paralysis", where one
>> > thinks excessively long about a good name. To avoid this naming
>> > paralysis, one can start out with a mediocre name. In the course of
>> > time, often a better name will come to one's mind.
>>
>> In that situation, is it preferable to choose a nonsensical name over a
>> mediocre one ?
>
> I don't know. A mediocre name conveys at least some information, and
> that seems to be better than none. On the other hand it might be just
> enough to lead the reader astray which wouldn't happen with a
> non-sensical name.
>
> But since perfect names are hard to find, using nonsensical instead of
> mediocre names would mean choosing nonsensical names most of the time.
> So I'll stick with mediocre names if in doubt.
>
> hp

Although if a mediocre name is chosen there is less impetus on the
programmer to change it, "its not great but it'll do"
where as a nonsense name sticks out like a saw thumb until it is
corrected.
I am firmly undecided

--
Riches cover a multitude of woes.
-- Menander

On Thu, 28 Oct 2021 00:38:17 +0000, Eli the Bearded wrote:

> In comp.lang.python, Peter J. Holzer <hjp-python@hjp.at> wrote:
> ^^^^^^
>
> Those all work. But if you are writing a new web framework and you name
> your method to log stuff to a remote server "Britney" because you were
> listening the singer, that's not perfectly fine, even you want to make
> "Oops, I did it again" jokes about your logged errors.

Although Oops would be aq pretty reasonable name for a logger or error
handler...
>
>
> Elijah ------
> naming is hard, unless it's easy

--
After a number of decimal places, nobody gives a damn.

On 29/10/2021 07.07, Stefan Ram wrote:
> The name should not be "optimized" for a certain use case
> (as for the use in an if expression) only. "We", "have",
> and "any" carry little information. A name should pack as
> much information as possible in as least characters as
> possible. So, for me, it'd be something like:

Although, does that not imply that "pack[ing]...information" is primary,
and "least characters..." secondary?

How else to define "readability" (wrt 'names')?

> if word_count:

Yes, but this does open the door to the 'gotchas' of truthiness, ie
there ain't no such thing as a free lunch/"silver bullet".

Whereas, names such as:

is_valid
words

help to imply a boolean and a collection, resp. (cf the micro-softy way
of imposing the language-technicalities over naming-readability, eg

bValid

Thereafter, to counter the idea of not having too many names, there may
be an argument for setting-up one's data to be able to code:

if is_valid:
while word_count:
# pop word from words and do something...

so now we have a data-set which includes:

words: a collection, eg arriving to us from some input
word: one item from words, isolated for processing
word_count: a convenient expression of len( words )
is_valid: an indicator that the words received are ready for our process

(not that I 'like' "is_valid" but need a specific context to improve that)

The "is_" prefix appeals to me because it is so English-like (dare I say
COBOL-like?) that readability is in no doubt. At the same time, whilst
it could be considered and 'extra' name/extra-effort, it adds precision
to the logic.

YMMV!
Indeed some may wish to argue that the data-set includes unnecessary
verbiage, and that this in-and-of-itself might contribute to
cognitive-overload...

import this

>> So, the obvious solution is to ask the language, like Python, to allow
>> variables that are synonyms.
>
> Programs already have too many names in them.
> There is no need to add even more, especially
> when they are equivalent, and the average human can
> only hold 7 ± 2 objects (like names) in his short-
> term memory.

+1

aka "cognitive overload"

@Martin's term is "naming paralysis", which fits as a component of
"analysis paralysis", cf 'let's get on with it'!

(which summed-up how I felt abstracting and refactoring a function this
morning - dithering and vacillating like I couldn't decide between
chocolate cake or chocolate pudding...)

Which point, when referred to synonym variables, gives the optimal
answer: "both" (cake and pudding!)

When you think about it, passing values to functions, ie an argument
becomes a parameter, that can be considered a form of synonym.

(and (before someone disappears off on another unintended tangent) some
circumstances where it is not!)

>> really good names often end up being really long names
>
> If they are really long, they are not really good,
> /except/ when they have a really large scope.
>
> Names for a small scope can and should be short,
> names for a large scope may be longer.

Interesting! Surely as something becomes more specific, there is more
meaning and/or greater precision to be embedded within the name. Thus:

operator

assignment_operator
walrus_operator

> Some very short names have traditional meanings
> and are ok when used as such:
>
> for i in range( 10 ):

For historical (?hysterical) reasons I find myself agreeing with this.
(in FORTRAN any variable beginning with the letters "I" through "N" was
regarded as an integer - all others being real/floating-point - thus, it
is a familiar idiom.

That said, this form of for-loop is reminiscent of other languages which
use "pointers" to access data-collections, etc, and keep track of where
to logic is within the process using "counters" - none of which are
necessary in pythonic for-loops.

Accordingly, there is an argument for using:

for ptr in range( 10 ):
for ctr in range( 10 ):

(or even the complete word, if that is the functionality required)

The above allowing for the fact that I have my own 'set' of 'standard
abbreviations' which are idiomatic and readable to me (!). One of which is:

for ndx in range( 10 ):

This abbreviation originated in the days when variable-names had to be
short. So, one tactic was to remove vowels*. Once again, more readable
(to me) than "i", but possibly less-than idiomatic to others...

That said, watching a video from EuroPython 2021, I was amused to see:

for idx in range( 10 ):

and doubly-amused when I experimented with the idea as-presented and
'copied' the code by 'translating' his "idx" into the English "index",
and whilst typing into my own REPL, cogno-translated the thought into my
own "ndx" expression.

Now, I don't know if the EuroPython author uses "idx" because that
relates somehow to his home-language. However, if we analyse such
abbreviations, their writing is a personal exercise. Whereas,
measuring/assessing "readability" involve neither "writing" nor
"personal" at its core. Thus, if there is a "jargon" abbreviation which
is readily understandable, is it so 'bad' just because it is not a
complete (English) word?

Until I spent more (?too much) time with folk who formed their Style
Guides as super-sets of PEP-008, I didn't worry too much about these
abbreviations. People 'here' are amongst those who dislike(d) my use of:

idNR - id = identification (?), number (NB suffix)
NUMwords = number in/len() of a collection (NB prefix)
arrayPTR = pointer to specific member within array

The interesting thing about some of these (aside from PEP-008) is that
they are very historial - as above. Accordingly, it is 'the youngsters'
who object more vociferously (aside from pedants, like trainers, er,
cough, splutter). Yet, until a few years ago I would not have understood
"OMG" and similar 'text-isms' that have escaped into the real-world from
cell-phones. Yet, asking (a youngster) what (s)he means will
stereotypically involve a shrug or eye-roll (patent-pending) indicating
that I should not need to ask because 'everyone' knows!

(OK, so am I allowed to give you a few PTRs about politesse?)

NB I find that 'modern IDEs' and sundry plug-ins are possibly more
responsible for making me PEP-008-compliant than any human(s). The
nagging splatters of queries and criticisms are even less
politically-correct than aforementioned ageist youngsters!

> . And, as a "golden rule" for refactoring, I'd say:
> When you see:
>
> i = 0 # word count
>
> , then remove the comment and rename "i" to "word_count"!

Yes, a beautiful illustration of why comments can cause more damage than
they should (theoretically) be helping us, readers, avoid...

Two for the price of one: criticising the choice of name, and the choice
of comment!

* see also written Classical Arabic
--
Regards,
=dn

dn <PythonList@DancesWithMice.info> writes:
>On 29/10/2021 07.07, Stefan Ram wrote:
>>The name should not be "optimized" for a certain use case
>>(as for the use in an if expression) only. "We", "have",
>>and "any" carry little information. A name should pack as
>>much information as possible in as least characters as
>>possible. So, for me, it'd be something like:
>Although, does that not imply that "pack[ing]...information" is primary,
>and "least characters..." secondary?
>How else to define "readability" (wrt 'names')?

To illustrate this:

I might have a variable to hold the count of words in an
input file. It could be named:

count_of_words_in_the_input_file

. But I do not want to tell whole stories in a single name.
So, I should choose the two or three words most important
and distinctive:

count_of_words

and then reverse them to get rid of the "of", thus:

word_count

. However, when I suddently have /two/ input files (one
"English input file" and one "French input file"), I might
need to use:

count_of_english_words
count_of_french_words

and then reduce them to

english_count
french_count

. Now, "english" and "french" are more important and
distinctive than "word", so I have kept them and thrown
away "words". But when I also start to count /characters/
I would be forced to use

english_words
french_words
english_chars
french_chars

. The "count" made it clear that these are not the words
themselves but their count, but here I have removed it for
brevity. I try to find a reasonable compromise between
length and clarity.

>When you think about it, passing values to functions, ie an
>argument becomes a parameter, that can be considered a form
>of synonym.

Yes, but of course only by its /value/, i.e., "def f( x ): x =
x + 1" does not change the argument. And I think the word
"synonym" was intended to be implemented so that the following
will print "4" when a and b are synonyms:

a = 3
b = 4
print( a )

(something like this is possible in C++).

>This abbreviation originated in the days when variable-names
>had to be short. So, one tactic was to remove vowels*. Once
>again, more readable (to me) than "i", but possibly less-than
>idiomatic to others...

Yes, I think the observation that the consonants carry more
information has been made often.

The English word "admirable" is pronounced [ˈæd mər əb əl],
i.e., the vowels written "i", "a", and "e" are all
pronounced using the same sound, the mumble sound [ə] called
"schwar". So, in spoken English, many vowels already are
"neutralized" or, in fact, removed: "admirable" (in fast
speech) also is pronounced [ˈæd m̩ rəb l̩] with a so called
"syllabic" [m̩] and a "syllabic" [l̩], where now the [m̩] and
[l̩] are "intense" consonants and two of the vowels-in-writing
are totally gone in the pronunciation. So, the word is quite
readable when written as "admrbl".

>>Names for a small scope can and should be short,
>>names for a large scope may be longer.
>Interesting!

When the scope is small, it is more easy to overlook the
definition and all uses, so the name does not have to carry
that much information:

def example():
name = input( "What's you name?" )
print( f"Hi, {name}!" )

. Here we do not ask "The name /of what/ is this?",
so it does not have to be called "name_of_the_current_user".
Just "name" is sufficient.

When the scope is larger, a longer name also serves to
avoid name clashes and it is more important to carry more
information to the site where it is used. It is also less
likely to be used in any line of code than a local variable,
so that it's not so bad if one has to type it in (because
this is less often necessary than with a local variable).

>The interesting thing about some of these (aside from PEP-008) is that
>they are very historial - as above. Accordingly, it is 'the youngsters'
>who object more vociferously (aside from pedants, like trainers, er,
>cough, splutter).

Of course, PEP 8 is not any kind of law, it is only intended
for the Python code comprising the /standard library/. But
sometimes people /are/ searching for guidance in the field
of programming style, and they are happy when someone gives
them a guideline, so they don't have to think about certain
choices themselves again and again and then have to remember
how they decided the last time to stay consistent with it or
even write their own style guide. And when several people work
one the same project, it's best when they all follow the same
style rules.