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

[Paul Moore]

On 22 September 2011 14:58, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Thu, Sep 22, 2011 at 6:21 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> A concern I have with the expression variant is that I don't
>> understand what it would mean except in the restricted contexts it's
>> been discussed in. Can you describe the semantics of
>>
>>    static EXPR
>>
>> in isolation, so that we're not just interpreting it in terms of its
>> use in an assignment, and can understand the wider implications?
>
> It isn't really that different from the statement version - a
> definition time expression would be calculated at definition time by
> the interpreter and the resulting value cached on the function object.
> At execution time, the cached value would be used in place of the
> original expression. (As an implementation detail, this would likely
> work by assigning such expressions an index in the function's closure
> list and populating them at definition time as cells)

OK, I think I get it now.

So the example

a, b, c = atdef ([], {}, set())

would create and cache a tuple at definition-time, then retrieve and
unpack it at runtime. Which means that it has the same effect as

a = atdef []
b = atdef {}
c = atdef set()

with some slightly subtle differences in detail (there's only one
cached "value" rather than 3, but it'd be hard to detect that in
practice.

I think that based on your definition, all my "but what about X"
pathological examples have reasonably sane behaviours (you need a good
understanding of what "definition time" actually means, but once you
internalise the fact that def is an executable statement, that isn't
too hard).

I can see the attractions of the idea but:
* I'm sorry but the keyword atdef is ugly. The only proposal I like is
static, but I agree that it only makes sense to someone with a C-type
background.
* I remain unconvinced that the problem is severe enough to warrant a
new keyword.
* The semantics, although clear and easy to state, are probably one
more step away from Python being a simple language. I can imagine
beginners' heads exploding...[1]

Paul.

[1] Although anyone needing the semantics is arguably no longer a beginner :-)