Update to PEP 227 (static scoping)

[Carel Fellinger]

Russell E. Owen <owen at astrono.junkwashington.emu> wrote:
...
> I confess to being nervous about this proposed change. Static scoping 
> does add some very nice functionality, but it seems to come at a 
> significant cost in
> - complexity (the new rules have some tricky exceptions)
> - safety (Tim's example is a good one; also typos can do more damage)

I'm worried too by the increasing complexity of this scoping thing!

...
> lambda list-of-args : list-of-non-local-variables : code

maybe this could be spelled (as is suggested before me thinks) like:

  lambda list-of-args ; list-of-non-local-variables : code

and then functions could use the same spelling for closures, like

  def f(list-of-args ;
        list-of-closures):
      pass

This would prevent the nasty Pascal habbit of deeply nested
references, or actual it would spell it out, as each and every
function needs to pass on all vars that are going to be referenced
somewhere inside that function being it in the function body itself or
in some locally declared one.  (Probably my upbringing in Eindhoven
(and subsequent admiration for Dijkstra) shines through here:)

Ofcourse nested functions do not recurse easily in such a scheme,
but neither do recursive methods in the PEP that worries us so much.
(I know self.method will do, but why do I have to spell recursion
differently for methods? yak)

Or maybe the semantics of that semi-colon inside the argument list
could be such that it allowed to pass the function name into the
visible scope of that function?

<rambling on>
We could use that semicolon again to create a place to define function
attributes like in

   def f(arg-list ;
         closures ) ;
         function-attributes :
       pass

Spelled like this, I would expect to be able to address function
attributes inside the function body.  I think The BDFL is against
this, but why?
<\rambling off>
-- 
groetjes, carel