Eval (was Re: Question about using python as a scripting language)

[Brendon Towle]

On 9 Aug 2006, at 12:03 PM, skip at pobox.com wrote:

>
>     Brendon> I could do that, or I could do something like the re.*  
> trick
>     Brendon> mentioned by another poster. But, doesn't it offend  
> anyone else
>     Brendon> that the only clean way to access functionality that's  
> already
>     Brendon> in Python is to write long complicated Python code?  
> Python
>     Brendon> already knows how to extract a list object from a  
> string; why
>     Brendon> should I have to rewrite that?
>
> Doesn't bother me at all.  One, it's not actually Python code, it's
> JavaScript.  It's just serendipity that the table can be parsed as  
> a Python
> list.  Two, there's nothing to prevent the authors from changing the
> formatting in an incompatible way in the future.

I think that these are actually the same reason, and can be safely  
ignored, because item 2 is true no matter what method I use to parse  
the data. Sure, it's serendipity, but that happens to be the hand I'm  
dealt at the moment; why not exploit the serendipity?


>   Three, it's completely
> untrusted input and shouldn't be fed to eval().

This is the crucial point, and the reason I asked the question to  
begin with.

Lisp (which I'm used to) has the read-eval-print loop; I think that  
my confusion was because:

1. Python's eval(X) is essentially the same as Lisp's (eval (read- 
from-string X)), not Lisp's (eval X) or Lisp's (read-from-string X);
2. The '[' character that begins a list should actually be read as a  
function call, not a data delimiter. (Which, in the context of list  
comprehensions, makes a lot of sense as I think about it.)


> Four, it's not actually
> complicated code (using the csv module would probably be simpler).

I'll look into the csv module.

And, it may not be complicated on an absolute scale, but Chris' re.*  
method turned one line of code into about 15; that's certainly a non- 
trivial increase in complexity.


> Five, you have to stop thinking of it a "list
> object".  It's just a string of bytes which happens at this point  
> in time to
> intersect with the definition of a Python list.  You're trying to  
> wish it
> was something that it's not.

I must be confused here. If I call the following function:

   eval('[1, 2, 3]')

what does that function call return, if not a list object?

Sure, the string isn't a list object; it's a string of bytes that  
happens to be syntactically identical to the definition of a list in  
python code. I was hoping for a clean and safe way to exploit that  
identical-ness; apparently, all the clean ways are unsafe, and all  
the safe ways are unclean.


B.


-- 
Brendon Towle, PhD
Cognitive Scientist
+1-412-690-2442x127
Carnegie Learning, Inc.
The Cognitive Tutor Company ®
Helping over 375,000 students in 1000 school districts succeed in math.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20060809/d84f36a9/attachment.html>