pre-PEP: Suite-Based Keywords - syntax proposal

[Kay Schluehr]

Bengt Richter wrote:

[...]

> Um, I think that's too narrow for where. Consider
>
>     foo = f1; bar=f2; x=k1; y=k2
>     foo(x)*bar(y)[3].attr
>
> now should
>
>     foo(x)*bar(y)[3].attr where:
>         foo = f1; bar=f2; x=k1; y=k2

I think we are diverging again. You are right with Your objection about
my claim of generality but I'm completely against the latter statement
not only because

foo(x) where:
   foo = f1

is not much better than

foo(x) where:
   def foo():
       # do some stuff

which should clearly raise an exception and be abandoned.

After all I start backtracking: the purpose of defining suites is still
prevention of namespaces pollution with helper-functions not a sake of
it's own and not inventing of a suite-based programming style for
everything. The examples You presented have become almost pathological
examples of what should be prevented and where syntax cannot be rigid
enough.

So there are following requierements about we seem to agree:

- define suites on a functions-call scope in order to define helper
functions
  that would otherwise pollute external namespaces

- mark the func-call-scope by some keyword either "with" or "where"
because
  it has to be separated from the calling environment both for
consistency
  and user friendlyness

- Simple matching rules for both keyword-parameters and
argument-tuples.
  Make explicit which kind of inference rule is selected.

I think that my last proposal I finally distilled from our discussion
would pretty much fullfill all three requirements whereas that of
Andrey Tatarinov would be somewhat more restrictive and fullfills only
the first two. 

Ciao,
Kay