[EMAIL PROTECTED] (Alex Martelli) writes:
> ...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.
It seems that someone pisses in your cornflakes nearly every
morning.
For the record, I was attempting to respond to your post which I
only saw quoted in another message. Please excuse any accidental
misquoting.
>> 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.
It appears that you write much longer functions than I generally
do. Requiring that all functions be named adds even more to the
clutter.
> 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
Or, I could just use a language that supports unnamed functions.
> Your "pragmatic benefits", if such they were, would also apply to the
> issue of "magic numbers",
That claim is, frankly, silly. A function is far more
understandable without a name than a value like 1.19 in isolation.
The situations aren't remotely comparable.
>> >> 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.
Like Scheme?
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
[EMAIL PROTECTED] | (C++, Java, Common Lisp, Jini, CORBA, UML)
--
http://mail.python.org/mailman/listinfo/python-list
