Why does not Python accept functions with no names?

[Avi Gross]

Eric,
You bring up a related topic which I agree with. You need to be careful to make aspects of a language as consistent as possible and thus allowing no receiver of a function definition (somewhat different than no name) might result in anomalies in other parts of the language. Errors that could be caught would be accepted, even if teh resulting code was nonsense.
Some languages use a real placeholder such as "_" (single underscore) to represent an I DON'T CARE scenario meaning I do not want to provide a name and Python allows code like:
(a, _, c, _, e) = (1, 2, 3, 4, 5)
print(a, _, c, _, e)1 4 3 4 5
The above code snippet suggests that _ is allowed to be used multiple times and retains whatever is done last. But an experiment shows there is nothing special about underscore as a name in that replacing it with an x above gets the same results. It may not be implemented at the interpreter level as "throw away" or skip over, but I can imagine languages implementing just that. In the above, certainly, the reading in of the number 2 may have happened and the variable reused leaves it without one of the pointers to it.
But consider what happens if the matching above was to more complex items like function calls that may have all kinds of effects and side effects.  I may want to throw away the results returned, but may want the side effect. 
So in a sense the question being asked might have a partial suggestion, in Python, to simply provide a clue when creating the function to have the name _, albeit I still keep wondering WHY you want that.
Consider other things like a language in which just typing the name of a variable has no meaning. I mean it does not autoprint. If a line by itself says:
myvar
It typically starts a search for whatever method the language uses to find that name in their data structures to determine if it exists in the current context. If not found, you expect an error message. But even if found, what does one do with it? In some languages, there seems to be no point in even accessing it and it seems to be anything from harmless code to be ignored or an error because it is not a valid construct and the user may have meant to say myvar = 6 or something. But in a language like Python, it may have some impact just from being invoked such as incrementing a counter within an object. If you want to have such functionality in the language, you now have to allow it. And one way to support this is to make believe you typed print(myvar) which on my machine fails when myvar is not defined. When it is, it prints what it can. This works even when I ask for seemingly useless operations like "()" which creates and then (after the print) ignores an empty tuple. 
Anonymous functions arguably have an important place in many languages and I keep seeing languages adding some version of them or new syntax for them, as R recently did. But they are best used when made deliberately and the example we are given seems highly likely to be a mistake where the user forgot to put in a name where it was expected. At the very least it may merit a WARNING. Or, if allowed, I wonder if the interpreter should perhaps do something amusing like give it some long nonsense name and notify the user that in case they actually wanted a real function, it is now mxyzptlk666 ...


-----Original Message-----
From: Eryk Sun <eryksun at gmail.com>
To: python-list at python.org
Sent: Mon, Feb 21, 2022 2:35 am
Subject: Re: Why does not Python accept functions with no names?

On 2/20/22, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>
> BTW, this is not what is usually meant by the term "anonymous
> function". An anonymous function is one that is not bound
> to *any* name. The thing you're proposing wouldn't be
> anonymous -- it would have a name, that name being the empty
> string.

Sorry. I read Avi's reply first, scanned the original post and didn't
consider the literal question. I doubt that Python would have become a
popular language if it allowed the empty string as an identifier. That
would let common syntax errors slip past the compiler with useless
results, e.g `= 1`, `c. = 1`. It's no less absurd in a `def`
statement.
-- 
https://mail.python.org/mailman/listinfo/python-list