[Python-ideas] Another way to avoid clumsy lambdas, while adding new functionality

[David Mertz]

On Tue, Mar 4, 2014 at 5:46 PM, Cameron Simpson <cs at zip.com.au> wrote:

> >   foo = 1
> >   a = $(foo + 1)
> Definitely nicer. Still irrationally uncomfortable about the "$" though.
> A thought, though it could break existing code (and nested tuples, alas):
>
>     a = (( foo + 1 ))
>

That looks like unresolvable ambiguity to me.  I confess that I am more
comfortable with '$(...)' because I'm one of those folks who actually likes
bash, and uses that spelling often over there (where the meaning isn't the
*same* as this, but is enough similar for the meaning to carry over)


> Still, what does this mean?
>     a = 3 + (( foo + 1 ))
> I think that would need to be a syntax error, because I can't see it being
> anything except nonsense otherwise.
>

In my example I made it a TypeError on the grounds that a thunk and and int
aren't things that can be added together.  That makes more sense to me than
a SyntaxError, since a thunk is a perfectly good expression (or would be if
the feature is added).

Besides, you really need to allow thunks in expressions, since sometimes
they make sense as values to operate on, e.g. (as I wrote before):

  print(foo, 'foo', $(foo))  # Using my bash-like syntax
  # 1 foo <thunk object ...>

You could also, for example, have a type of object that knew how to operate
on a thunk with operators:

  class Thunker(object):
      def __radd__(self, other):
          if isinstance(other, thunk):
              ... return something sensible ...

  thunker = Thunker()
  a = thunker + $(foo + bar)

>   b = eval(a) * 6
> This makes me unhappy. Eval parses a string and runs it, currently.
> I would _want_ to read that as "compute a, then eval() the result".



> b = a() * 6


I don't think I would want a thunk to be *exactly* a callable. That feels
wrong to me.  But I can see that overloading the meaning of eval() to
operate on either a string or a thunk might feel odd. *Except* that eval()
is *already* overloaded in a similar manner:

  >>> exp = compile("1+2", "<string>", "eval")
  >>> exp, eval(exp)
  (<code object <module> at 0x100730ae0, file "<string>", line 1>, 3)

However, what if it was spelled differently from eval(), e.g.:

  b = unthunk(a) * 6

OK, I don't actually like that name, but you see what I mean that other
names are perfectly possible.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140304/46581697/attachment.html>