On Aug 21, 2014, at 12:55 AM, icefap...@gmail.com wrote:
> Hi, just wanting to do a shot in the dark,but maybe this syntax is Pythonic
> (in a "we-are-all-grown-ups" fashion, ahem)enough to get its way into the
> language
> this is what yours truly thinks: don't we all know that ":" means the next
> token must be an indent (mostly)? and doesn't the "(" and its alikes, [ and }
> begin an space-insensitive lexing context? so all we need is having an
> "space-sensitivity-stack" and the corresponding "(" counting stack and this
> way we could match opening and closing "()" and pop the
> space-sensitivity-stack whenever the "(" counting stack gets a 0 at the top:
<snip>
Those more pythonista than me have weighed in on the particulars. I’ll offer
some more general thoughts.
While I dwell in the land of pythonistas, I’m a an expat from the Island of
Smalltalk. I live happily in Pythonville and will probably never return to the
shrinking island, I do miss Smalltalk’s block closures. I don’t miss them *too*
much, because things like comprehensions as well as the large library of
functional like modules, covers many of the use cases. But I do miss their
simple elegance.
I do not like the python lambda. For two reasons.
One: In a language that sought to be approachable by simple people (i.e. non
computer science graduates who would use it in addition to their
scientific/education background), I can’t believe they threw in a 6 character
phonetic description of a greek character to imply “fragment of code expression
to be executed in a removed context”. Show a subset of keyword.kwlist to a
non-comp-sci guy and tell me if when they see the ‘lambda’ betwixt the others,
they don’t stop and think “huh, one of these is not like the others”.
Two: The reason that this subject circles regularity, because they used a
keyword, it can only be used as a literal creator for a single line expression.
So we keep coming back to “how can we do multiple expressions with a
lambda/closure”.
For the unaware, the Smaltalk syntax for a literal block closure was a pair of
[ ]. First of all, I liked that the characters actually looked like a “block”
with the corners. I liked that it did not use parentheses. Parentheses are
pretty loaded already, and it helped the brain pick out the differences
instantly. I don’t like the OP’s proposal because I don’t think (def()) is
distinct from normal grouping () statements. And I liked how terse they are.
Two characters and you had a block. They are *everywhere* in the library.
Compare that with how often you find ‘lambda’ in the python standard modules. I
used to joke about the irony, that no language did more with functional
closures than the all-objects-all-the-time Smalltalk, and that CLOS had a more
robust object model than Smalltalk.
To me, for a multiple-expression (multi line or not) literal closure syntax to
succeed, it must a) denote both the start and stop (not a leading keyword), b)
be extremely terse so that the cost of creating closures is reduced c) not be
confused with other common literal denotation so it can be quickly recognized
when reading close (so [ and { are out for example, because of lists and
dictionaries, and using < > would cause complete confusion because it’s hard at
a glance to differentiate from a comparison operand).
Personally, I don’t think the desire to use lines as statement boundaries
(something I like a lot) and at the same time to tersely pack multiple
statements into a deferred code fragment, are reconcilable. And I don’t think
there’s critical mass desire for them. So this subject will continue to
resurface regularly. But I thought I’d chime in with a “foreigners” perspective.
--
https://mail.python.org/mailman/listinfo/python-list
