Title: Clarify multiple function names in the tutorial
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.10, Python 3.9, Python 3.8
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Jim Fasarakis-Hilliard, docs@python, miss-islington, nanjekyejoannah, r.david.murray, rhettinger, steven.daprano, terry.reedy, veky, xfq
Priority: normal Keywords: patch

Created on 2016-11-13 03:36 by xfq, last changed 2020-07-06 09:40 by terry.reedy. This issue is now closed.

File name Uploaded Description Edit
renaming.patch xfq, 2016-11-13 03:36 patch review
Pull Requests
URL Status Linked Edit
PR 21340 merged nanjekyejoannah, 2020-07-05 20:59
PR 21343 merged miss-islington, 2020-07-06 01:47
PR 21344 merged miss-islington, 2020-07-06 01:47
Messages (12)
msg280683 - (view) Author: Fuqiao Xue (xfq) Date: 2016-11-13 03:36
In :

   A function definition introduces the function name in the
   current symbol table. The value of the function name has a
   type that is recognized by the interpreter as a user-defined
   function.  This value can be assigned to another name which
   can then also be used as a function.  This serves as a general
   renaming mechanism

Maybe "aliasing" is a better term than "renaming" here, since the original function name can still be used after the "renaming".
msg280686 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-11-13 04:29
+1 "Aliasing" is more accurate.
msg280687 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2016-11-13 05:52
I disagree that "aliasing" is more accurate.

We have a perfectly good name for symbols in Python: "name". A value (and that includes functions) can have multiple names. It seems to me that if we're to start distinguishing between names and aliases, then aliases have to be different from names. And the way I understand "alias" is that it is another symbol for a variable, not another symbol for the same value.

We wouldn't say that

    x = 1
    y = x

makes y an alias for x. y just happens to be a second name for the same value that x currently has. There's no guarantee that they will stay the same. Substitute a function object for the int 1, and you have the situation being discussed in the tutorial.

I would expect that aliases should not be effected by rebinding:

    x = 1
    y = alias(x)  # if such a thing existed
    x = 2
    assert y == 2

Obviously there's nothing in Python like that! This doesn't match Python's name binding model at all.

I think that talking about a "general aliasing" mechanism is exactly wrong. I think that the tutorial should emphasis the reality that functions are just ordinary values, like ints and floats and dicts and lists, and not try to indicate that there is something special or different about names bound to functions:

    def f(): ...
    g = f

is no different from the x = y example earlier.
msg280688 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-11-13 06:01
To me, this is renaming:

     def f(x): pass
     f.__name__ = g

And this is aliasing:

     g = f
msg280691 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2016-11-13 10:31
> And this is aliasing:
>      g = f

Is it only aliasing if you know that f is a function? I don't mean that 
as a rhetorical question -- I'm asking if we're comfortable with the 
idea of saying that g is an alias when f is (say) a float.
msg280705 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2016-11-13 17:24
I would rewrite that paragraph as follows:

   A function definition associates the function name with
   the function object in the current symbol table.  The
   interpreter recognizes the object pointed to by that
   name as a user-defined function.  Other names can also
   point to that same function object and can then also
   be used as a function.

You will note that I've dropped the mention of renaming entirely, since the function does know it's __name__, and introducing that topic at this point in the tutorial would be confusing and unnecessary.  (NB: one could also say "referenced" and "reference" rather than "pointed to" and "point to"; I'm not sure which is more in line with the rest of the tutorial).
msg281154 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-11-18 18:25
It took me a moment to realize that 'value of the function name' meant 'the function object associated with the name'.  I think David's rewrite is a substantial improvement.  I would just change the end 'can be used as a function' to 'can be used to access the function.'

'Renaming' is wrong to me because it implies invalidation of the previous name. 'Alternate name' is more accurate.

I agree that 'alias' is better, but also that it is a bit problematical*.  'Alias' is distinct from 'legal name'. The closest analogy to 'legal name' is 'definition name' (.__name__ attribute).  But definition names are distinct from bound names, only some objects have definition names, and when they do, they can be renamed if and only if the object is coded in Python. 

I don't understand the relevance of the middle sentence
   "The interpreter recognizes the object pointed to by that
   name as a user-defined function."
All objects can be given multiple names.  In this context, the difference between C and Python coded names is whether the .__name__ attribute can be rebound, and that attribute is not part of the discussion here.  The paragraph introduces this code example, which has nothing to do with .__name__.

   >>> fib
   <function fib at 10042ed0>
   >>> f = fib
   >>> f(100)
   0 1 1 2 3 5 8 13 21 34 55 89

(* Steven, I would say that both 'x' and 'y' in your example are aliases for the int 1.  But I understand the other viewpoint.)
msg281199 - (view) Author: Vedran Čačić (veky) * Date: 2016-11-19 05:19
Obligatory link: :-P
Yes, Python objects are simpler than people, but still not completely trivial. The core issue is "who does the calling".

Even one's native language might subtly (in Orwell sense) alter what they mean the name is. English question "What is your name?" is usually translated into Croatian (and some other Slavic languages) as "Kako se zoveš?", literally "how do you call yourself". In some other languages, it's "how should I call you". I think you agree those are three different concepts. And I think most disagreements between people in these discussions stem from those cultural differences. (Even people who consider English their native language might still have cultural differences, since English is spoken so widely.)

In Python, the most important distinction is "name as own identity"(1) vs "name as handle for calling"(2). Of course, we all know that each of these concepts have disadvantages, and as such, cannot serve completely. name(1) is not something all objects have (but e.g. functions and classes do), while name(2) is external to the object - each of existing namespaces might or might not have a way (or three, or infinitely many) to refer to it. And all those ways are not considered to be known to the object itself.

Since this concrete example speaks about names of functions defined with a def statement, those concepts coincide, and that's why some people have thought it speaks about name(1) and some others have thought it speaks about name(2). If we want to be completely honest, we should clarify that "name" is used in two ways, and that later text speaks only about name(2). But it might be too much for beginners. In that case, we should probably avoid mention name(1) sense until much later, and speak only of names as "name(2)".
msg373057 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-07-06 01:35
Vedran, thank you for the interesting cultural and linguistic perspective.  In Spanish, "Como te llamas?" (familiar) "Como se llama?" (formal) literally translate as "What do you call yourself?" (want me to call you?).  (I believe the latter could also be translated as "What are you called?", which you note is slightly different.  I also know that addressing people by name is a more involved -- and dangerous-- subject in Japan than in America.

I think that David's rewrite is clear enough with the little change I suggested at the end, and have approved Joannah's PR with one little addition.  Even if not perfect, it is definitely better than the current text.
msg373060 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2020-07-06 01:47
New changeset d12af71047f0eae86440654d3ea74c032c7c3558 by Joannah Nanjekye in branch 'master':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340)
msg373064 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2020-07-06 02:07
New changeset 00c09f06a4cf1e352c6ab0c9b9e6074e52f44ae1 by Miss Islington (bot) in branch '3.9':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21343)
msg373065 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2020-07-06 02:08
New changeset 6790f9badda47c7aa0fe4b0b5f090d6ca0c477d5 by Miss Islington (bot) in branch '3.8':
bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21344)
Date User Action Args
2020-07-06 09:40:20terry.reedysetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2020-07-06 02:08:03nanjekyejoannahsetmessages: + msg373065
2020-07-06 02:07:35nanjekyejoannahsetmessages: + msg373064
2020-07-06 01:47:35miss-islingtonsetpull_requests: + pull_request20492
2020-07-06 01:47:28miss-islingtonsetnosy: + miss-islington
pull_requests: + pull_request20491
2020-07-06 01:47:18nanjekyejoannahsetmessages: + msg373060
2020-07-06 01:35:22terry.reedysettitle: About function renaming in the tutorial -> Clarify multiple function names in the tutorial
messages: + msg373057
versions: + Python 3.8, Python 3.9, Python 3.10, - Python 3.5, Python 3.6, Python 3.7
2020-07-05 20:59:05nanjekyejoannahsetnosy: + nanjekyejoannah

pull_requests: + pull_request20488
stage: needs patch -> patch review
2017-04-04 19:38:26Jim Fasarakis-Hilliardsetnosy: + Jim Fasarakis-Hilliard
2016-11-19 05:19:37vekysetnosy: + veky
messages: + msg281199
2016-11-18 18:25:26terry.reedysetversions: - Python 3.3, Python 3.4
nosy: + terry.reedy

messages: + msg281154

stage: needs patch
2016-11-13 17:24:11r.david.murraysetnosy: + r.david.murray
messages: + msg280705
2016-11-13 10:31:21steven.dapranosetmessages: + msg280691
2016-11-13 06:01:02rhettingersetmessages: + msg280688
2016-11-13 05:52:37steven.dapranosetnosy: + steven.daprano
messages: + msg280687
2016-11-13 04:29:15rhettingersetnosy: + rhettinger
messages: + msg280686
2016-11-13 03:36:36xfqcreate