Bill Atkins <[EMAIL PROTECTED]> wrote:
...
> > ``allow ( as an ordinary single-character identifier'' as for the
> > unneded feature ``allow unnamed functions with all the flexibility of
> > named ones''.
>
> Not so infeasible:
>
> (let ((|bizarrely(named()symbol| 3))
> (+ |bizarrely(named()symbol| 4))
>
> ;; => 7
Read again what I wrote: I very specifically said "ordinary
*single-character* identifier" (as opposed to "one of many characters
inside a multi-character identifier"). Why do you think I said
otherwise, when you just quoted what I had written? (Even just a
_leading_ ( at the start of an identifier may be problematic -- and just
as trivial as having to give names to functions, of course, see below).
> And in any case, enforced indentation is a policy with vastly more
> serious consequences than the naming of identifiers.
So far, what was being discussed here isn't -- having to use an
identifier for an object, rather than keeping it anonymous -- trivial.
Python practically enforces names for several kinds of objects, such as
classes and modules as well as functions ("practically" because you CAN
call new.function(...), type(...), etc, where the name is still there
but might e.g. be empty -- not a very practical alternative, though) --
so what? Can you have an unnamed macro in Lisp? Is being "forced" to
name it a "serious consequence"? Pah.
Anyway, I repeat: *any* design choice (in a language, or for that matter
any other artefact) has consequences. As Paul Graham quotes and
supports his unnamed friend as saying, Python lets you easily write code
that *looks* good, and, as Graham argues, that's an important issue --
and, please note, a crucial consequence of using significant
indentation. Alien whitespace eating nanoviruses are no more of a worry
than alien parentheses eating nanoviruses, after all.
Alex
--
http://mail.python.org/mailman/listinfo/python-list
