[Python-ideas] Before and after the colon in funciton defs.
ron3200 at gmail.com
Tue Sep 20 05:40:02 CEST 2011
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
> 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
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
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,
>>> 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.
More information about the Python-ideas