PEP 312 - Making lambdas implicit worries me, surely it's just the name 'lambda' that is bad...

[Alex Martelli]

Stephen Horne wrote:
   ...
>>>>> starts a line". Other frequently used words (such as built-in function
>>>>> names) also never start a line - 'reduce' is as long as 'lambda' for a
   ...
>>So, the assertion that built-in function names never start a line
>>is incorrect.
> 
> I never made that assertion, though on further examination I see why
> you thought I did.

Ah, yes -- I do see a parenthesis of "Other <Y>s (such as <X>s)" as 
meaning "all <X>s are <Y>s" without needing a redundant "all" after
the word "as" (just as "all <X>s are <Y>s" does not need the pleonasm
of the reinforcing "all" -- it means the same thing without it).

So, I believe you simply mis-spoke, and are now trying to hedge by 
claiming some ambiguity (needing to be resolved by context) for a
phrasal form that I believe has no such ambiguity.  Feel free to keep
tilting at this particular windmill -- I'll no doubt remain convinced
of my thesis, and you, of yours.

As for the meta-thesis -- if I make an unambiguous assertion, I can get
quite angry when people try to distort it into something else by claiming
that "context" justifies their attempt to make me say something different
than what I _DID_ say.  When my assertion is ambiguous the responsibility
for possibly mis-interpreting it is often shared, but not ALL assertions
are inevitably ambiguous -- and when an assertion IS non-ambiguous, it
stands or falls on its own; trying to weasel it into meaning something 
quite different by invoking "context" is a game that's no doubt of huge
interest to lawyers and literary critics, but of no interest to me as
an engineer.  In particular, when I say something unambiguously wrong (by
badly chosen wording, OR because I did not know the true state of things,
makes no difference) I prefer to admit it and apologize for it, rather
than attacking those who correct me and/or climbing over mirrors of
"context" to avoid admitting I was wrong.  Personal tastes, I guess.

> need to clarify "some" built-in functions. Hence, when you 'corrected'
> me, implying that I didn't know this common sense thing, I felt
> insulted and - in my already bad mood - I overreacted.
> 
> Once again, I am sorry for that.

No problem, except that the implication you're reading is also quite
unwarranted -- somebody may know something perfectly well but still err
in expressing it.  Thus, correcting a wrong expression carries no
necessary implication that the utterer of said expression did not
know the true state of affairs, any more than it carries any necessary
implication that the utterer was deliberately lying -- in the general
case, both are possible, but mis-expression is also quite possible.


> Now I think about it, most built-in functions probably return a value

They all do, but that value can of course be None.  

> (I can't be bothered checking, but most of the ones I can think of off
> the top of my head do anyway). While some of those may still be used
> (or abused) for their side effects, a person might reasonably consider
> that functions that can appear at the start of a line are exceptional.

There are 43 built-in names of type builtin_function_or_method (in
Python 2.3 just built from CVS).  Of those, I'd say apply, delattr,
execfile, intern, raw_input, reload and setattr are typically or at
least quite frequently called without caring about their return values
(one could quibble both ways, e.g. adding map or removing intern,
but, roughly) -- whether 7 out of 43 qualifies as "exceptional" is
quite dependent on what meaning one attaches to that adjective, of
course, but to me it seems to qualify as a substantial minority,
even without considering the common try/except idioms (e.g., hash(x)
in a try clause to check if x is hashable without caring about its
hash value).

Once again, the _relevance_ of this to anything whatsoever appears to
be totally mysterious to me.  If MOST built-in functions very rarely
make sense at the start of a logical line, then the "context" you were
earlier claiming as the justification for (what I do still consider)
your mis-statement is very weak indeed -- and so much more important
was it then for me to correct that mis-statement, according to your
own interpretations as previously presented.


Alex