It would be great to be able to reverse usage/definition parts in
haskell-way with "where" keyword. Since Python 3 would miss lambda, that
would be extremly useful for creating readable sources.

Usage could be something like:

 >>> res = [ f(i) for i in objects ] where:
 >>>     def f(x):
 >>>         #do something

or

 >>> print words[3], words[5] where:
 >>>     words = input.split()

- defining variables in "where" block would restrict their visibility to
one expression

- it's more easy to read sources when you know which part you can skip,
compare to

 >>> def f(x):
 >>>     #do something
 >>> res = [ f(i) for i in objects ]

     [lambda x: f(x) for x, f in lst]

instead of

     [lambda x, f=f: for x, f in lst]

Are there other situations where you run into these kinds of problems?

TOOWTDI-ily-yrs,

     [lambda y: f(x, y) for x, f in lst]

...

     [lambda y, x=x, f=f: f(x, y) for x, f in lst]

where you actually need the lambda.

I don't by any means agree that this notation is worth adopting, and
in general I think this kind of readability issue is more or less a lost
cause for a language with Python's scoping rules, but the motive makes
sense to me.  One way to look at it might be, if I observe that "words"
is assigned to in a where clause, then I  know it will not be used
elsewhere in the surrounding scope so I can forget about it right away.
If the name does occur elsewhere, it evidently refers to something else.

 >>> res = [x for x in sequence if x.isOk()]

 >>> print input.split()[3:5:2]

(Does it qualify as obfuscated Python code? :) )

I think this idea is of the same kind as the @decorator syntax. Guido
moved an operation to a point in the code where it was more visible. You
moved an operation to a more local context where (pun not intended) it
really belongs.

I'm usually rather conservative about Python syntax (@decorators,
absolute/relative imports, if-else operator), but this one could appear
in Python tomorrow and that would be too far in the future for me ;)

Cheers,

This idea has the virtue of being able to do the same thing, but have full
access to Python's function syntax and assignment statements in the 'expression
local' suite.

In fact, any subexpressions in a complicated expression can be extracted and
named for clarity without fear of screwing up the containing namespace, which
would be an enormous boon for software maintainers.

It also allows the necessary but uninteresting setup for an expression to be
moved "out of the way", bringing the expression that does the real work to
prominence.

 From the interpreter's point of view, the meaning would probably be something like:

namespace = locals()
exec where_suite in globals(), namespace
exec statement in globals(), namespace
res = namespace["res"]
del namespace

Making the 'where' clause part of the grammar for the assignment statement
should be enough to make the above example parseable, too.

The clause might actually make sense for all of the simple statement forms in
the grammar which contain an expression:
   expression statement
   assignment statement
   augmented assignment statement
   del statement
   print statement
   return statement
   yield statement
   raise statement
   exec statement

The clause really isn't appropriate for break, continue, import or global
statements, as they don't contain any expressions :)

For compound statements, a where clause probably isn't appropriate, as it would
be rather unclear what the where clause applied to.

Cheers,
Nick.

    x = (-b + sqrt(discriminant))/(2*a) where:
          discriminant = b*b - 4*a*c

Maybe you could just have a where: suite that binds variables
within the suite:

    where:
       def f(x):
          #do something
    res = [ f(i) for i in objects ]

    where:
       discriminant = b*b - 4*a*c
    x = (-b + sqrt(discriminant))/(2*a)

Syntax is
   where:
      suite
   statement

class C(object):

   x = property(get, set) where:
     def get(self):
       return "Silly property"
     def set(self, val):
       self.x = "Told you it was silly"

Cheers,
Nick.

Putting the statement of interest after the where suite still gives the benefits
of avoiding namespace clutter, but doesn't really help readability (it makes it
worse, if you ask me).

Particularly, what if the next statement is a compound statement?

Cheers,
Nick.

Frankly, they might have a point here.  Although we have replacing
lambda expressions on our minds, I have in mind a different problem
that a where-statement would solve perfectly.  But it would have to be
used with an if-expression.

However, I think it might not be so hard.  Let's take Paul Rubin's
advice and precede the if statement with where.  Let's also allow
"elif" clauses to be replaced with "else where ... if" clauses.  That
which is bound in the while-block would be visible in both the
if-expression and if-block.

Then we could do this:

. where:
.     m = someregexp.match(somestring)
. if m:
.     blah blah blah
. else where:
.     m = someotherregexp.match(somestring)
. if m:
.     blah blah blah

We might want to spell "else where" instead as "elwhere", to match
"elif", but that's not important now.  This would take away one of the
major minor annoyances of Python.  (In fact, I've suggested something
like this as a solution to the set-and-test idiom, which Python makes
difficult, only I used the keyword "suppose" instead of "where".)

Ok, but if you do that, now you have people whining that "where" comes
after some expressions, and before others.  (This would not bother me
one bit, BTW, but I'm pretty sure I'd lose the popular vote on this
one.)

So, let's go all out and say that while could precede any statement.
We now have consistency.  Well, that really wouldn't work for the
if-statement, though, because then how could we apply a different
while-block to an else clause?  We'd have to treat if-statements
specially anyways.  So we don't have consistency.

My solution would be to propose two different where statements: a
where...do statement, and a separate where...if statement.  The
where...do statement would look like this:

. where:
.     def whatever(): pass
. do:
.     blah blah use whatever blah

It has the advantage of being able to apply the where bindings to
several statements, and is, IMO, much cleaner looking than simply
applying where's bindings to the single following unindented statement.

I would recommend against where...while and where...for statements.
They can't accomplish anything you couldn't do with a break statement
inside the block, and it's not obvious whether the where clause gets
executed once or for each loop (since it's physically outside the loop
part).

One question: what do you do with a variable bound inside a while-block
that has the same name as a local variable?  (Or, horrors, a
surrounding while-block?)  I'm inclined to think it should be illegal,
but maybe it would be too restrictive.
Anyways, I like this idea a lot.

+1

'as' is used for renaming in import statements. 'as' will be used for exception
naming in Python 3k.

So let's use it for expression naming in 'if' statements, too.

if someregexp.match(s) as m:
   # blah using m
elif someotherregexp.match(s) as m:
   # blah using m

Cheers,
Nick.

    z = C() where:
       class C(object):
          ...

   x = term1 + term2 where:
       term1 = a*b where:
           a = 123
           b = 456
       term2 = math.pi

Reminds me of some kind of weird let ;-)

And, is the whole thing after the '=' an expression? E.g.,

  x = ( foo(x) where:
         x = math.pi/4.0
      ) where:
         def foo(x): print 'just for illustration', x

or is this legal?

  for y in ([foo(x) for x in bar] where:
                 bar = xrange(5)
            ): baz(y) where:
                def baz(arg): return arg*2

Not trying to sabotage the idea, really, just looking for clarification ;-)

def gcd(a, b):
where:
a: int, b: int
return c where:
c: int
while a:
a, b = b%a, a
return b

More can be found at http://aroberge.blogspot.com

.def gcd(a, b):
.    where:
.        a: int, b: int
.    return c where:
.        c: int
.    while a:
.        a, b = b%a, a
.    return b
more examples can be found at aroberge.blogspot.com

I think it's a really ingenious solution to the the anonymous function
problem - don't make it anonymous! A short, throwaway name with a very
localized scope is as good as a truly anonymous function and feels more
Pythonic to me. We thought we wanted a better syntax than lambda for
anonymous functions but Andrey shows that perhaps it wasn't what we
really need. What we need is a solution to quickly and cleanly generate
bits of callable code without polluting the containing namespace,
without having to think too hard about unique names and while making
their temporary and local nature clear from the context. Anonymity
isn't one of the requirements.

I really liked Nick Coghlan's property example. The names 'get' and
'set' are too short and generic to be used without a proper scope but
with this syntax they are just perfect.

Here's another example:

w = Widget(color=Red, onClick=onClick, onMouseOver=onMouseOver) where:
.   def onClick(event): do_this(event.x, event.y, foo)
.   def onMouseOver(event): someotherwidget.do_that()

The "onClick=onClick" part seems a bit redundant, right? So how about
this:

w = Widget(**kw) where:
.   color = Red
.   def onClick(event): do_this(event.x, event.y, blabla)
.   def onMouseOver(event): someotherwidget.do_that()
.   x, y = 100, 200
.   kw = locals()

I'm not really sure myself how much I like this. It has a certain charm
but also feels like abuse of the feature. Note that "w =
Widget(**locals()) where:" would produce the wrong result as it will
include all the values in the containing scope, not just those defined
in the where block.

Overall, I found the idea interesting. It seems like a obvious
counterpart to "with", in the sense that both act as modifiers to the
scoping rules. I think it can be made to work, and that it would lead
to elegant & readable code, but there are still lots of things to
consider: exception handling, fast name lookup in the "where" block,
access to symbols outside the "where" block, just to name a few.

This wouldn't be a problem parsing, of course, because "where" would be
a keyword.