[Python-ideas] Quick idea: defining variables from functions that take the variable name

[Jonathan Goble]

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160601/87e8d567/attachment.html>