[Python-ideas] Before and after the colon in funciton defs.

[Ron Adam]

On Tue, 2011-09-20 at 08:23 +1000, Nick Coghlan wrote:
> On Mon, Sep 19, 2011 at 11:22 PM, Sven Marnach <sven at marnach.net> wrote:
> > I don't see too much benefit of the proposed syntax for this use
> > case.  If f() is a local throw-away function, I wouldn't worry about
> > its signature.  If f() is a longer-lived object and I do care about
> > its signature, I'd uses a class:
> >
> >    class Adder:
> >        def __init__(self, i):
> >            self.i = i
> >        def __call__(self, x):
> >            return x + self.i
> >
> >    [...] adders.append(Adder(i))
> >
> > I still think classes are the Python way to hide state, not closures.
> 
> The thing is, real function objects genuinely *are* special. They have
> a privileged place in the interpreter, the inspect module and other
> introspection tools know more about how to deal with them, they have
> instance method descriptor behaviour built in, etc.

Heh, On an abstract level, I do know there is something special about
function objects.  Putting my finger on it is a bit harder.  Trying a
few things to see what happens...

At some point there does need to be a base object that can't be taken
apart into it's smaller parts.  That normally would be the object class.
But with functions, we are referring to the base *executable* object.

A function is is a union of other basic objects that can then be
executed.  (I think there can be some improvements in how a function
object is constructed and organized.)

I guess the real *special* magic is the byte code, CALL_FUNCTION, which
knows how to use a function object.  Along with the other Function
related bytecodes.



> Where those proposals all come unstuck is that they try to do more
> than the default argument hack allows, *without compelling use cases
> to guide the additional semantics*. The pre-initialised locals concept
> deliberately avoids that problem by targeting exactly the use cases
> that are *already* supported via the default argument hack, just in a
> way that tries to avoid the negative effects on introspection and
> readability.

Umm... "...default arguments hack allows,..."?  Not well said, I think
you meant, "...unstuck, by doing more than is needed...".  

Even so, I do understand your point you are trying to get across.


Would your suggestion add any additional methods, or attributes to a
function object?

Would it need any additional byte codes?


An alternative proposal, I came across the other day... don't remember
exactly where, is to be able to put default arguments after the **kwds,
parameter.

>>> def boo(a, *args, b=1, **kwds, c=3):
  File "<stdin>", line 1
    def boo(a, *args, b=1, **kwds, c=3):
                                 ^
SyntaxError: invalid syntax

It's currently a syntax error.  But that requires using an ** someplace.

I don't really like this one, as I think function arguments are already
hard enough to understand.  For a language that is suppose to be easy to
understand, that's not a good thing.

Cheers,
   Ron