On 19 Apr 2005 00:16:32 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
> >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. Why do you say that? foo(x) is just a call of whatever foo is bound to. The where: suite supplies a transient namespace where foo happens to be defined in the conventional way. This allows definition and call of foo without binding it in the caller's local namespace, much like (lambda(): do_some_stuff)() IMO that's a perfectly valid use. You don't have to worry that your def foo():... will clobber some other foo. > >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. You don't have to write what you consider to be pathological, but this becomes sort of a free speech issue. I.e., don't impose a style-censoring spell-checker on me please ;-) > >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 Why just function call? You realize that a "function call" is just the effect of (<arglist>) tacked on the tail of an expression that is not necessarily just a name. E.g., notice the possibilities the parser goes through before finding that foo() is a simple name expression with a () trailer: [ 1:18] C:\pywk\parse\ast>py24 debg.py -full foo() 'file_input' 'stmt' 'simple_stmt' 'small_stmt' 'expr_stmt' 'testlist' 'test' 'and_test' 'not_test' 'comparison' 'expr' 'xor_expr' 'and_expr' 'shift_expr' 'arith_expr' 'term' 'factor' 'power' 'atom' NAME 'foo' 'trailer' LPAR '(' RPAR ')' NEWLINE '' ENDMARKER '' What about instance.method(args) as a call? Should you not be able write instance.method(*args) where: args = [] # append various values to args here, # in single statements and/or using looping etc. to specify complex args in a where? That looks like [ 2:18] C:\pywk\parse\ast>py24 debg.py -full instance.method(*args) 'file_input' 'stmt' 'simple_stmt' 'small_stmt' 'expr_stmt' 'testlist' 'test' 'and_test' 'not_test' 'comparison' 'expr' 'xor_expr' 'and_expr' 'shift_expr' 'arith_expr' 'term' 'factor' 'power' 'atom' NAME 'instance' 'trailer' DOT '.' NAME 'method' 'trailer' LPAR '(' 'arglist' STAR '*' 'test' 'and_test' 'not_test' 'comparison' 'expr' 'xor_expr' 'and_expr' 'shift_expr' 'arith_expr' 'term' 'factor' 'power' 'atom' NAME 'args' RPAR ')' NEWLINE '' ENDMARKER '' What about other expressions that can retrieve a callable whose arguments you might want to compute with logic? My bet is that neither of us can predict what pain an arbitrary restriction on natural consequences of a good orthogonal grammar change will do. In another post I did sketch out a grammar mod that prevents a whole bunch of nonsense such as continue where ... (and I'm not sure I caught all true silliness), but I would rather not restrict for pure style reasons. Obviously the BDFL went the style-restrictive way with decorator expressions, since functionally any expression after the '@' which returned a callable taking a function as its first argument could have been allowed. I agree (after some mixed feelings ;-) about that in the decorator case, but I think where-functionality is much more general. > >- 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 Not sure what you mean by func-call scope, but I assume you are referring to what is created by processing the where suite. The way I have been thinking of this for where is to translate <tiny_stmt> where <wheresuite> to def uniquetmp(): # return dict with bindings created in wheresuite <where-suite> return vars() exec_with_shadowing_name_space( uniquetmp(), <tiny_stmt> ) IOW, the idea is to execute the tiny_stmt normally, except that any names accessed will first be looked up in the dict returned by uniquetmp(), and if not found there will go on to the normal local space of tiny_stmt and then to its globals. Thunks are tricky, because while bound in the where suite namespace, their code bodies share the namespace outside of the where scope. I think I can implement the functionality with a combination of import-time AST rewriting and byte code hacks, but I am not sure I want to expend the energy doing that. Better to expend it getting set up to do real experimental changes. But I need to upgrade a bunch of stuff to do that ;-/ > >- Simple matching rules for both keyword-parameters and >argument-tuples. This almost suggests source-level macro processing to me, which is _NOT_ what where is about. "Matching" in my view is not textual, it happens dynamically at run time and names not supplied will cause run time name errors, not syntax errors. > Make explicit which kind of inference rule is selected. I'm not sure what this means ;-) > >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. Maybe you could summarize it as a concrete grammar change? That would help make it clear. I enjoy this ping pong, but it takes up a lot of time ;-) Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list