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 -- http://mail.python.org/mailman/listinfo/python-list