[Python-ideas] Before and after the colon in funciton defs.
python at mrabarnett.plus.com
Tue Sep 20 19:43:07 CEST 2011
On 20/09/2011 17:59, Terry Reedy wrote:
> On 9/20/2011 10:00 AM, Sven Marnach wrote:
>> I actually *do* use the default argument hack for early binding
>> myself. My main points were that the current status quo isn't too
>> bad, there are alternatives if the function signature is really
>> important, and that the cases which require both using closures *and*
>> having a clean signature are too rare to justify yet another
>> confusing-for-beginners syntax. (When I started learning Python in
>> 1998, the language was praised for having a small language core. I
>> didn't hear this very often in more recent times.)
> I have noticed the same. The big syntax additions are generators,
> comprehensions, decorators, and the with statement. The switch to
> unicode doesn't change syntax but can complicate text processing.
>> Assuming a new syntax *is* necessary -- there is no objective way to
>> decide this after all -- I don't particularly like the proposed square
>> bracket syntax because
>> a) it puts the information at the wrong place. The first line of the
>> function definition is for the outside appearance of the function,
>> including signature and annotations. Separating the internal
>> information on early bound variables from the signature is the
>> primary goal of the proposal after all.
>> b) it does not make the intention of early binding very clear.
>> c) it consists of a list of the form [i=i] or [tuple=tuple, len=len]
>> in most use cases, making it necessary to type every name that
>> shall use early binding twice.
>> That's why I would prefer a syntax that explicitly declares the names
>> that should use early binding, similar to "global" or "nonlocal"
>> statements, if such a syntax is deemed necessary at all.
> The problem with an earlybind statement in the body is that it is in the
> body, which should be runtime stuff. I would prefer something in the
> header. A semi-colon or other char would be sufficient syntactically:
> def f(a; len, alist=): alist.append(a); return len(alist)
> where a bare identifier like 'len' *means* 'len=len'.
To me that's like a 'static' declaration in C++, which in Python might
be something like:
What follows 'static' would be an assignment which is executed when the
function is defined, much like a default argument, and would be shared
between invocations in the same way.
More information about the Python-ideas