Why can function definitions only use identifiers, and not attribute references or any other primaries?

[Jeremy Banks]

On Apr 23, 5:23 pm, Terry Reedy <tjre... at udel.edu> wrote:
> Jeremy Banks wrote:
> > Hi. I'm sure there've been debates about this before, but I can't seem
> > to figure out what to search for to pull them up, so I'm asking here.
>
> > It seems to me that a lot of things could be made much easier if you
> > could use primaries other than basic identifiers for the target of
> > function definitions. For example, if attribute references were
> > allowed I'd be able to do:
>
> >     def foo.bar():
> >         return("I'm a method!")
>
> > If we wanted to get even more liberal (which I don't see as a bad
> > thing, but I could see being found more objectionable by some), we
> > could allow the use of anything that's a valid assignment target. For
> > example:
>
> >     def foo["bar']():
> >         return("I'm a function referenced in a mapping object!")
>
> > In this case I could see there being a problem in that there's nothing
> > to get the function's __name__ from, but that doesn't apply for the
> > first example.
>
> > Many uses of this may not be Pythonic, but I'm sure there are many
> > that are. It just feels like an arbitrary restriction, preventing
> > users from doing something that may be useful.
>
> > Any feedback or direction to previous discussion on the subject would
> > be appreciated. Thanks!
>
> There has been some discussion on py-dev and perhaps python-ideas, but I
> cannot remember any specifics as to why Guido was unpersuaded/negative.
>
> If one regards
>
> def name(params): body
>
> as syntantic sugar for a (somewhat hypothetical) assignment statement
>
> name = make_func('name', "params", "body")
>
> (there is a function_maker function in the new module, though with a
> more complicated interface), then generalizing the target would seem
> reasonable.  The function's __name__ does not seem like an issue:
> "foo.bar" and "foo['bar']" both direct one to the proper definition code.
>
> Counter-argument: class and import are also implied assignments, and
> they also subject to the same limitation.
>
> Counter-counter-argument: a) doing actual assignments with name =
> type('name', bases, dict) and name = __import__('name',...) is more
> feasible, and b) the need for qualified names is less for class and
> probably for import and c) the restriction *could* also be lifted for
> those two statements also.
>
> For some, a plus for this proposal is that is directly binds the
> function to the target without introducing a spurious name into the
> local scope.  It would thus reduce the perceived need for and hence
> pressure for generalized function expressions.  I believe Guido would
> consider this last point a plus if so stated.
>
> I do not believe this recurring idea has been the subject of a PEP.  If
> not, writing one might be a service, should you choose to do so, even if
> rejected.
>
> Terry Jan Reedy

Interesting, thank you very much for your suggestions. I'll try to put
together a draft.