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

[Eric Snow]

On Wed, Sep 21, 2011 at 9:44 PM, Ron Adam <ron3200 at gmail.com> wrote:
> On Wed, 2011-09-21 at 20:31 -0600, Eric Snow wrote:
>> Agreed, though the the keyword should be on the LHS:
>>
>>   static spam, print, open = len, print, open
>
>
> The above could also be ...
>
>     spam, print, open = (static len, print, open)
>
>
> As Jan pointed out, it would be very similar to how the 'yield' is used.
>
> It doesn't do anything to the identifiers on the left side.

Yeah, "static" on the LHS does imply a different meaning.  Perhaps
"static" is the wrong keyword, for all the baggage it carries.  And a
real "static" statement may not even be the right solution[1].

We're looking at two approaches here: do it in the function "header"
or in the body.  Here're some pros and cons:

In-header Pros:
- implies definition time

In-header Cons:
- limited space so more info adds clutter
- could be mistaken as part of function's signature

In-body Pros:
- less cluttered
- more closely associated with function locals?

In-body Cons:
- easy to miss that it's a definition-time directive (particularly if
on RHS of assignment)
- evaluated expression must not reference any of the function's locals


We definitely want the solution to be explicit that it's a
definition-time behavior.  If the new syntax is in the body then it'll
have to be especially obvious.  Either way, the new syntax should
clearly isolate the expression and associate it with a name to which
it will be bound in the locals.

All things considered, I don't think the that RHS static expression
fits the bill.  The right solution seems to be pretty elusive here...

As an aside, what would take precedence in the case of a name
collision: default arguments or the new syntax?

-eric


[1] If a static statement had an assignment clause for the initial
value, then it would work.  However, it doesn't seem explicit enough
that the value is evaluated at definition time.
[2] Ideally we would just use attributes on the function object.
However, this has a number of problems including performance and the
ambiguity of to which object the function name points.  (I have a
patch in issue 12857 that addresses exactly that.)


>
>
> The only thing the static expression does is save a reference to what
> ever the expression part on the right evaluates to at the time the
> function is defined.  Later, when the function is called, is when it's
> actually used.
>
> At define time...
>
>     spam, print, open = static (len, print, open)
>
>
> Becomes this at call time...
>
>     spam, print, open = _tuple  #tuple created by static expression
>
>
> Cheers,
>   Ron
>
> (Apologies for any double or delayed posts, I'm still trying to get some
> email glitches worked out.)
>
>
>> It's more consistent with other keywords that way and easier to spot
>> when reading code.
>>
>> Also, "static" as a keyword is in use as an identifier in a number of
>> places per google's codesearch (on the order of 100) including in
>> Django.  It's not like it's in super broad use, but it is in use.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>