[Python-3000] in-out parameters

[Rudy Rudolph]

One thing that has always bothered me about Python is the lack of in-out
parameters. Python is such a wonderful object-oriented language, but it lacks
this feature that nearly every language has. Maybe we can fix this in 3.0.

There are two possibilities for how to do this: by reference or by copy-back.
For a single-threaded app the effect is the same if the function returns
normally. If the function raises an exception, then the actual argument may
have a changed value with by-reference semantics but not with copy-back
semantics. Either semantics is acceptable to me.

Here's what I have in mind.
    def f(inout param):
        param += 5
        return "this is my result"

    # call it
    x = 2
    result = f(x)
    # x is now 7

I don't much care about the syntax. The proposed "inout" reserved word could
be "ref" or "&" or "in out". We could even do "param : inout [type]". Whatever.

There are two current workarounds for this missing feature.

1) copy-back:
    def f(param):
        param += 5
        return "this is my result", param

    # call it
    x = 2
    result,x = f(x)
    # ugly, but x is now 7

    # If we implement copy-back inout, the meaning would be similar to this.


2) pass-by-reference: 
    def f(wrappedParam):
        wrappedParam[0] += 5  # ugh
        return "this is my result"

    # call it
    x = 2
    result = f([x])
    # also ugly, but x is now 7

    # If we implement by-reference inout, the meaning would be similar to this.
    # Passing some kind of proxy is also possible.

The effect of approaches 1 and 2 is the same unless f raises an exception
between incrementing by 5 and returning. With copy-back semantics, x is still
2 when the exception is caught. If x is a global accessed by other threads,
the choice of semantics also affects them if an exception is raised.

If we do either of these, we should also consider "out". This is not as big of
a concern because the workaround has no parameter and the function just
returns a pair of results. This isn't as unnatural as mentioning x twice
or "listing" it. I propose that if we do "out" it would mean the same as either
meaning of inout, but passing None as the argument (for copy-back) or doing
"x = None" before the call (for pass-by-reference). This is, of course,
subject to debate.

Impact :
a) Inside the function, inout and out params would be treated differently.
   If inout implemented as copy-back:
       return an extra value (make a tuple with the complete nominal return
       value as the first element, followed by special params in order)
   If inout implemented as pass-by-reference:
       treat param as param[0] (if list is passed. If a proxy is used, then
       something like calling a property setter)
   If out : same as one of the above
b) At the point of call, an extra step or two is necessary for each inout or
   out param in the function to be called.
   If inout implemented as copy-back:
       assign after return (returned value is implicitly a tuple with the
       nominal result or None at 0, followed by new values for inout arguments)
   If inout implemented as pass-by-reference:
       wrap in a list or proxy before call
   If out implemented as copy-back:
       pass None for the value of param, then do same as inout via copy-back
   If out implemented as pass-by-reference:
       x = None before call, then do same as inout by reference

This does not introduce any backward incompatabilities so far as I know, so it
could possibly go into 2.6. I consider it very important for 3.0. I suppose
this could be accomplished via a decorator that messed with the
caller's stack frame, but I think syntactic support is better.

I don't remember seeing a PEP for this. Is it worth writing one or is the
initial reaction strongly negative? If I write a PEP, what other issues would
need to be examined besides the discussion above and interaction with the
other proposed changes to the parameter list?
(BTW, I'm +1 on keyword-only parameters, keyword arguments before positional ones in the call, and optional type on parameters.)

I have never written a patch for the Python core but am willing to try if the people on the dev list are willing to help when I have questions. I'm an experienced C programmer but have never looked at the CPython source code.

This is my first time posting to 3000, but I've been a Python user for 9 years
and a software engineer for 19 years. Good to meet you, everyone. I'm working
on a PhD in computer science, specializing in programming languages. I was a
reviewer for the Ada95 changes.

#Rudy

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!