Ron_Adam wrote: > On 24 Mar 2005 01:58:48 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> > wrote: > > >I personally don't like using exec and eval for stuff different from > >evaluating user input. > > I lean the other way. I never want to use user impute for eval and > exec. Way too risky.
Well a Python console does nothing else. I love that and sometimes I would like to develop the console a bit further in the direction of Mathematicas console where special formatted text- as well as image output is possible. Security problems of Python is another issue. > But limited use, that is not user input, should > be ok. The programmer can do anything he/she wants anyways, so exec or > eval is just another tool in that respect. > > But I am trying to find a way to limit the code objects. To make it > safe I need to hide all the name spaces except locals within the > function. Not sure if it's possible.. um, not easy. I know it's > possible. A castrated InteractiveInterpreter object with restricted access to os, file, eval, exec, sys.modules, __class__, import? > > >You rely much on "evaluate statement on the line" by adapting > >conventional Python syntax. I think one can go a bit further breaking > >the syntactical prejudices and apply tuple-actions :) > > > >Playing a bit with tuple-actions shows that the concept is quite > >powerfull and can be used to create simple statements. > > > >First of all the semantics has to be patched: > > > >We have > > > > (x,y,z=0) -> (x,y,z) > > > >as a tuple assignment > > > > ((x,y,z=0)->(x,y,z))(a,b,c) = (x=a,y=b,z=c) > > > >But it is not clear what > > > > (x,y,z=0) -> x*y-z > > > >actually means? > > I think I'm following you, but I'm not sure how much of it is > diagramic or meant to be actual code. > > Are you suggesting to use the -> as a operator? Yes. > If so then this is > backwards to the = operator. > > x*y-z <- (x,y,z=0) > > Would be more consistent to current syntax. Then the <- would have > the meaning of translate instead of assign. Or possibly an operator > for adapt? Guido wants to use the -> in function definitions to > specify return value types. Although I see problems with that too. Me too. I have written something about it in Guidos Artima blog a couple of weeks ago but I do mention now that also my thoughts about this topic were a bit short-sighted. Now I will wait for PyPy and it's annotator/type inferencer to become finished and run on CPythons speed ( if possible ). I have to think about the "<-" syntax but I'm a little in hurry - going to travel the next days. [...] > >Provide a compiler-hint: > > > > (x,y,()) -> x*y > > I'm not following you completely here. It appears your trying to > create a system to map different arguments to equations in a indirect > way. That's true. An important aspect that has to made clearer: diagrammtic: x -> (=,(x,.)) (x -> (=,(x,.)))(a) => x=a But (x,y,()) x*y > > > >Now we are ready for a few examples: > > > > > >default value: > > (i) -> (0) # i = 0 > > > >inplace increment: > > (i) -> i+1 # i = i+1 > > > >conditional expression: > > (i) -> i<3 # i,res = i,i<3 > > Lost me again, what is res? A mistake. (i)->i<3 should be a short form for (i,res=None) -> (i,i<3). But the interpreter should not create a variable on it's own. But I don't know how to prevent creation of a new name. Maybe the expression should not be shortened to (i) -> i<3 but to (i,res=None) -> i<3 ? [...] > >Wouldn't it be fun to use in Python? > > > >Only drawback: does not look like executable pseudo-code anymore :( > > > > > >Regards Kay > > I think I get the gist of what you are trying to do, but I can't > follow it entirely. > > Well it looks like an interesting puzzle, but you'll need to go a > little slower for some of us. I tired though. :) It's all developed during this discussion. Sometimes I'm a bit surprised were it goes. To make my intention clear for another time, also for George who mistrusts these exercises alltogether. I want to derive a syntax and semantics for anonymus functions ( called "tuple-actions" ) that are generalizations of rules that are already used implicitely within Python e.g. tuple-unpacking. This is done by progressive interpretation and extension. They are not there by means of an accident, what Guido claims about the current lambda which he feels to be sticked onto the language. Regards, Kay -- http://mail.python.org/mailman/listinfo/python-list