I have a completely different idea here. Forget clunky syntax, overloading of 'def' and 'as', and all that. Introduce the magic parameter '$'. To wit:

    def func(*args, **kwargs, $):  # positioning of the $ is discussed below
        ...  # function code here

$ would be a special-cased parameter that does not receive an explicit argument, and is thus ignored when calling the function (i.e. the function above would be called simply as 'func(*args, **kwargs)'). Instead, the $ parameter receives as its value a string representing the name that the function's return value will be bound to, or None if the function is called as a statement (where the return value is simply thrown away). Now any function (e.g. namedtuple) requiring the name can simply toss in a $ parameter, and it automatically receives the appropriate name through compiler magic. So assuming that namedtuple is patched to take a $ parameter instead of an explicit argument with the name, this common code today:

    Record = namedtuple('Record', ['name', 'address', 'phone', 'age'])

becomes simply this:

    Record = namedtuple(['name', 'address', 'phone', 'age'])

Some open questions here are where to require the $ to be placed in the argument list, and whether and how an advanced user can override it if needed. For the former, I propose to require it to be the last argument, after **kwargs. I considered making it the first argument, but that would create a competition for first argument in a class method or instance method (particularly __init__). Making it last also enables it to be overridden as a keyword-only argument. If the user really wanted to, they could change the above namedtuple call to:

    Record = namedtuple('name, address, phone, age', $='BusinessCard')

and $ would receive the explicit argument provided without compiler magic being applied.

Another concern is backward compatibility for namedtuple and other functions during the transition to the $ parameter. The easy solution would seem to be to just keep the explicit parameter and deprecate/ignore it, but there is then no way to transition to eliminating it completely since new code will have to continue providing a useless argument (in the common case that it is the first parameter), or else the function will have to give default values to every argument so that the other arguments can be passed as keyword arguments (which is not always desirable or practical), and sufficient time given for all users to switch to keywords, before the old first argument can be deleted in a subsequent release.

Instead, I suggest that the recommended method of transition ought to be to simply provide new functions and deprecate the existing functions (except where they are already built to handle omitting the explicit parameter in the call, if such cases exist) in a minor release, and remove the deprecated functions in a subsequent major release.

Thoughts? (I'm sunburned after spending six hours in a waterpark today on four hours of sleep last night, so if I sound crazy, that's why.)