Tim] Peters wrote:
>> The points to using function-call-like syntax were already covered
>> ("nothing syntactically new to learn there",

[Greg Ewing]
[> The trouble is that one usually expects "nothing syntactically
> new" to imply "nothing semantically new" as well, which is very
> far from the case here. So I think that not using *any* new
> syntax would actually be hurting users rather than helping them.

I expect anyone who has programmed for over a year has proved beyond
doubt that they can run a marathon even if forced to wear a backpack
containing a ton of lead, with barbed wire wrapped around their feet
;-)

They're indestructible.  If they came from Perl, they'd even have a
hearty laugh when they learned the syntax had utterly fooled them :-)


> If you really want to leverage existing knowledge, I'd suggest
> something based on lambda:
>
>   let a = 3, b = 4: a + b
>
> This can be easily explained as a shorthand for
>
>   (lambda a = 3, b = 4: a + b)()

In that case, yes, but not in all.  There's more than one kind of
magic here, even outside of block constructs.  See, e.g., the
quadratic equation example in the original post

    local(D = b**2 - 4*a*c,
          sqrtD = math.sqrt(D),
          ...

Try that with a lambda, and you get a NameError when computing sqrt(D)
- or, worse, pick up an irrelevant value of D left over from earlier
code.

In Scheme terminology, what Python does with default args (keyword
args too) is "let" (as if you evaluate all the expressions before
doing any of the bindings), but what's wanted is "let*" (bindings are
established left-to-right, one at a time, and each binding already
established is visible in the expression part of each later binding).

But even with `let*`, I'm not sure whether this would (or should, or
shouldn't) work:

local(even = (lambda n: n == 0 or odd(n-1)),
      odd = (lambda n: False if n == 0 else even(n-1)),
      odd(7))

Well, OK, I'm pretty sure it would work.  But by design or by accident? ;-)


> except, of course, for the magic needed to make it DWIM in an if
> or while statement. I'm still pretty uncomfortable about that.

That's because it's horrid.  Honest, I'm not even convinced it's
_worth_ "solving" , even if it didn't seem to require deep magic.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to