Patrick May <[EMAIL PROTECTED]> wrote:
...an alleged reply to me, which in fact quotes (and responds to) only
to statements by Brian, without mentioning Brian...
Mr May, it seems that you're badly confused regarding Usenet's quoting
conventions. You may want to repeat your answer addressing specifically
the poster you ARE apparently answering. Nevertheless, I'll share my
opinions:
> Using lambda in an expression communicates the fact that it will
> be used only in the scope of that expression. Another benefit is that
> declaration at the point of use means that all necessary context is
> available without having to look elsewhere. Those are two pragmatic
> benefits.
You still need to look a little bit upwards to the "point of use",
almost invariably, to see what's bound to which names -- so, you DO
"have to look elsewhere", nullifying this alleged benefit -- looking at
the def statement, immediately before the "point of use", is really no
pragmatic cost when you have to go further up to get the context for all
other names used (are they arguments of this function, variables from a
lexically-containing outer function, assigned somewhere...), which is
almost always. And if you think it's an important pragmatic advantage
to limit "potential scope" drastically, nothing stops you from wrapping
functions just for that purpose around your intended scope -- me, I find
that as long as functions are always kept small (as they should be for a
host of other excellent reasons anyway), the "ambiguity" of scope being
between the def and the end of the containing function is nil (literally
nil when the statement right after the def, using the named function, is
a return, as is often the case -- pragmatically equivalent to nil when
the statements following the def are >1 but sufficiently few).
Your "pragmatic benefits", if such they were, would also apply to the
issue of "magic numbers", which was discussed in another subthread of
this unending thread; are you therefore arguing, contrary to widespread
opinion [also concurred in by an apparently-Lisp-oriented discussant],
that it's BETTER to have magic unexplained numbers appear as numeric
constants "out of nowhere" smack in the middle of expressions, rather
than get NAMED separately and then have the names be used? If you
really believe in the importance of the "pragmatic benefits" you claim,
then to be consistent you should be arguing that...:
return total_amount * 1.19
is vastly superior to the alternative which most everybody would deem
preferable,
VAT_MULTIPLIER = 1.19
return total_amount * VAT_MULTIPLIER
because the alternative with the magic number splattered inexplicably
smack in the middle of code "communicated the fact" that it's used only
within that expression, and makes all context available without having
to look "elsewhere" (just one statement up of course, but then this
would be identically so if the "one statement up" was a def, and we were
discussing named vs unnamed functions vs "magic numbers").
> >> 3. It adds another construction to the language.
>
> That's a very minimal cost relative to the benefits.
To my view of thinking, offering multiple semantically equivalent ways
(or, perhaps worse, "nearly equivalent but with subtle differences"
ones) to perform identical tasks is a *HUGE* conceptual cost: I like
languages that are and stay SMALL and SIMPLE. Having "only one obvious
way to do it" is just an ideal, but that's no reason to simply abrogate
it when it can so conveniently be reached (my only serious beef with
Python it has it *HAS* abdicated the pursuit of that perfect design
principle by recent decisions to keep lambda, and to keep the syntax
[<genexp>] as an identical equivalent to list(<genexp>), in the future
release 3.0, which was supposed to simplify and remove redundant stuff
accreted over the years: suddenly, due to those decisions, I don't
really look forward to Python 3.0 as I used to - though, as I've already
mentioned, being a greedy fellow I'll no doubt stick with Python until
all my Google options have vested).
> You haven't made your case for named functions being preferable.
I think it's made at least as well as the case for using constant-names
rather than "magic numbers" numeric constants strewn throughout the
code, and THAT case is accepted by a wide consensus of people who care
about programming style and clarity, so I'm pretty happy with that.
Alex
--
http://mail.python.org/mailman/listinfo/python-list
