[Python-ideas] Before and after the colon in funciton defs.
Guido van Rossum
guido at python.org
Tue Sep 20 19:09:21 CEST 2011
On Tue, Sep 20, 2011 at 9:59 AM, Terry Reedy <tjreedy at udel.edu> 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'.
I would be much more interested in a tweak to the language semantics
where the compiler is allowed to assume that "len means len" if there
is no global assignment to it in a module. There are many past threads
about this topic. It should make the feature proposed here unnecessary
-- at least its use for manual micro-optimizations, which I mostly
find an offense to the reader (even in the shortened form proposed
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas