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

[Sven Marnach]

Nick Coghlan schrieb am Di, 20. Sep 2011, um 08:23:14 +1000:
> [stripped well-reasoned case for using closures against classes]
> 
> And that's why people use the default argument hack today - they weigh
> those downsides up against the consequences of having a bit of noise
> in the function signature (as seen by introspection tools) and decide
> they're happy to accept that trade-off in return for a simple and
> straightforward expression of a single algorithm with some associated
> state.

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.)

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.

> Various ideas for addressing this have been proposed in the past. PEP
> 3150's statement local namespaces are one, as are the assorted
> incarnations of the proposal for flagging arbitrary expressions within
> a function for evaluation at definition time rather than runtime
> (search the python-dev and python-ideas archives for phrase like 'once
> statement' and 'atdef' - alas, nobody has stepped forward to codify
> those ideas into a PEP).

How does PEP 3150 target the use cases of the default argument hack
given in your original mail?

Cheers,
    Sven