[issue28681] About function renaming in the tutorial
New submission from Xue Fuqiao: In https://hg.python.org/cpython/file/6fbb7c9d77c6/Doc/tutorial/controlflow.rst... : 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". ---------- assignee: docs@python components: Documentation files: renaming.patch keywords: patch messages: 280683 nosy: docs@python, xfq priority: normal severity: normal status: open title: About function renaming in the tutorial type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45468/renaming.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Raymond Hettinger added the comment: +1 "Aliasing" is more accurate. ---------- nosy: +rhettinger _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Steven D'Aprano added the comment: 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. ---------- nosy: +steven.daprano _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Raymond Hettinger added the comment: To me, this is renaming: def f(x): pass f.__name__ = g And this is aliasing: g = f ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Steven D'Aprano added the comment:
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. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
R. David Murray added the comment: 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). ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Terry J. Reedy added the comment: 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.) ---------- nosy: +terry.reedy stage: -> needs patch versions: -Python 3.3, Python 3.4 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Vedran Čačić added the comment: Obligatory link: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-na... :-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)". ---------- nosy: +veky _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Changes by Jim Fasarakis-Hilliard <d.f.hilliard@gmail.com>: ---------- nosy: +Jim Fasarakis-Hilliard _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________
Change by Joannah Nanjekye <nanjekyejoannah@gmail.com>: ---------- nosy: +nanjekyejoannah nosy_count: 8.0 -> 9.0 pull_requests: +20488 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21340 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: 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. ---------- title: About function renaming in the tutorial -> Clarify multiple function names in the tutorial versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Joannah Nanjekye <nanjekyejoannah@gmail.com> added the comment: New changeset d12af71047f0eae86440654d3ea74c032c7c3558 by Joannah Nanjekye in branch 'master': bpo-28681: Clarify multiple function names in the tutorial (GH-21340) https://github.com/python/cpython/commit/d12af71047f0eae86440654d3ea74c032c7... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Change by miss-islington <mariatta.wijaya+miss-islington@gmail.com>: ---------- nosy: +miss-islington nosy_count: 9.0 -> 10.0 pull_requests: +20491 pull_request: https://github.com/python/cpython/pull/21343 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Change by miss-islington <mariatta.wijaya+miss-islington@gmail.com>: ---------- pull_requests: +20492 pull_request: https://github.com/python/cpython/pull/21344 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Joannah Nanjekye <nanjekyejoannah@gmail.com> added the comment: New changeset 00c09f06a4cf1e352c6ab0c9b9e6074e52f44ae1 by Miss Islington (bot) in branch '3.9': bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21343) https://github.com/python/cpython/commit/00c09f06a4cf1e352c6ab0c9b9e6074e52f... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Joannah Nanjekye <nanjekyejoannah@gmail.com> added the comment: New changeset 6790f9badda47c7aa0fe4b0b5f090d6ca0c477d5 by Miss Islington (bot) in branch '3.8': bpo-28681: Clarify multiple function names in the tutorial (GH-21340) (GH-21344) https://github.com/python/cpython/commit/6790f9badda47c7aa0fe4b0b5f090d6ca0c... ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
Change by Terry J. Reedy <tjreedy@udel.edu>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue28681> _______________________________________
participants (9)
-
Jim Fasarakis-Hilliard -
Joannah Nanjekye
-
miss-islington
-
R. David Murray
-
Raymond Hettinger
-
Steven D'Aprano
-
Terry J. Reedy
-
Vedran Čačić
-
Xue Fuqiao