Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #36122

Re: Yet another attempt at a safe eval() call

From Grant Edwards <invalid@invalid.invalid>
Newsgroups comp.lang.python
Subject Re: Yet another attempt at a safe eval() call
Date 2013-01-04 17:14 +0000
Organization PANIX Public Access Internet and UNIX, NYC
Message-ID <kc72ls$3m7$1@reader1.panix.com> (permalink)
References <kc541v$3e4$1@reader1.panix.com> <50e6891c$0$30003$c3e8da3$5496439d@news.astraweb.com> <kc70hb$p5$1@reader1.panix.com> <mailman.89.1357318292.2939.python-list@python.org>

Show all headers | View raw


On 2013-01-04, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jan 5, 2013 at 3:38 AM, Grant Edwards <invalid@invalid.invalid> wrote:

>> I've added equals, backslash, commas, square/curly brackets, colons
>> and semicolons to the prohibited character list. I also reduced the
>> maximum length to 60 characters.  It's unfortunate that parentheses
>> are overloaded for both expression grouping and for function
>> calling...
>
> I have to say that an expression evaluator that can't handle parens
> for grouping is badly flawed.

Indeed.  That's why I didn't disallow parens.

What I was implying was that since you have to allow parens for
grouping, there's no simple way to disallow function calls.

> Can you demand that open parenthesis be preceded by an operator (or
> beginning of line)?

Yes, but once you've parsed the expression to the point where you can
enforce rules like that, you're probably most of the way to doing the
"right" thing and evaluating the expression using ast or pyparsing or
similar.

> You can probably recognize the formula I'm working with there, but
> it's far less obvious and involves six separate statements rather than
> two. And this is a fairly simple formula. It'll get a lot worse in
> production.

In the general case, yes.  For this assembler I could _probably_ get
by with expressions of the form <symbol> <op> <literal> where op is
'+' or '-'.  But, whenever I try to come up with a minimal solution
like that, it tends to get "enhanced" over the years until it's a
complete mess, doesn't work quite right, and took more total man-hours
than a general and "permanent" solution would have.

Some might argue that repeated tweaking of and adding limitiations to
a "safe eval" is just heading down that same road in a different car.
They'd probably be right: in the end, it will probably have been less
work to just do it with ast.  But it's still interesting to try. :)

-- 
Grant Edwards               grant.b.edwards        Yow! Are you the
                                  at               self-frying president?
                              gmail.com            

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-03 23:25 +0000
  Re: Yet another attempt at a safe eval() call Tim Chase <python.list@tim.thechases.com> - 2013-01-03 19:11 -0600
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 02:34 +0000
  Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 07:47 +0000
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:53 +0000
      Re: Yet another attempt at a safe eval() call Michael Torrie <torriem@gmail.com> - 2013-01-04 09:05 -0700
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:16 +0000
      Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 15:56 +0000
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-06 15:12 +0000
          Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-07 00:08 +0000
      Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-06 03:01 +1100
      Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 16:17 +0000
        Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
        Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
    Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:38 +0000
      Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 03:51 +1100
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 17:14 +0000
          Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 04:21 +1100
            Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:09 +0000
              Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 05:23 +1100
                Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:43 +0000
                Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 06:02 +1100
  Re: Yet another attempt at a safe eval() call Chris Rebert <clp2@rebertia.com> - 2013-01-03 23:50 -0800
  Re: Yet another attempt at a safe eval() call Terry Reedy <tjreedy@udel.edu> - 2013-01-04 07:24 -0500
    Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 13:33 +0000
      Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:59 +0000
      Re: Yet another attempt at a safe eval() call Alister <alister.ware@ntlworld.com> - 2013-01-04 18:13 +0000

csiph-web