[Python-ideas] explicitation lines in python ?

[Nick Coghlan]

On Sun, Jun 27, 2010 at 5:00 PM, Daniel DELAY <danieldelay at gmail.com> wrote:
> Le 26/06/2010 05:26, Chris Rebert a écrit :
> That's why I would in fact prefer a third option
> c) a refinement expression is only evaluated once even if the refinement
> name (ex: "htmlline") appears twice or more, but that name is not published
> in locals().

That's definitely the same goal as the old "statement local namespace"
idea. Trawling through a couple of old threads, the various keywords
suggested were:

- with (pro: already a keyword, con: now has completely different
meaning from normal with statement)
- where (pro: same name as used in Haskell, con: new keyword, also
completely different meaning from the SQL meaning many programmers
will find more familiar)
- using (pro: completely made up name at the time, con: new keyword,
now conflicts with the C# equivalents to Python's with and import
statements)

These days, I'm personally inclined to favour Haskell's "where"
terminology, but that preference isn't particularly strong.

The availability of "nonlocal" binding semantics also makes the
semantics much easier to define than they were in those previous
discussions (the lack of clear semantics for name binding statements
with an attached local namespace was the major factor blocking
creation of a reference implementation for this proposal back then).

For example:

 c = sqrt(a*a + b*b) where:
    a = retrieve_a()
    b = retrieve_b()

could translate to something like:

  def _anon(): # *(see below)
    nonlocal c
    a = retrieve_a()
    b = retrieve_b()
    c = sqrt(a*a + b*b)
 _anon()

*(unlike Python code, the compiler can make truly anonymous functions
by storing them solely on the VM stack. It already does this when
executing class definitions):

The major question mark over the idea is whether or not it would
actually help or hinder readability in practice. This is a question
that could be addressed by someone trawling the standard library or
other large public Python code bases (e.g. things in SciPy, the
assorted web frameworks, bzr, hg) for existing code that could be made
clearer if less important details could easily be moved out of the way
into an indented suite.

It's also something that has no chance of being accepted until after
the language moratorium ends.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia