gratuitous new features in 2.0

[Alex Martelli]

"Martijn Faassen" <m.faassen at vet.uu.nl> wrote in message
news:8odgka$dqg$1 at newshost.accu.uu.nl...
> Alex Martelli <alex at magenta.com> wrote:
> > "Martijn Faassen" <m.faassen at vet.uu.nl> wrote in message
> > news:8oc8si$dsg$1 at newshost.accu.uu.nl...
> [snip]
> >> I never thought the 'print' statement was a bad idea, myself. I do
> >> think the >> addition to print isn't a very good idea. And it makes me
> >> realise *now* that 'print' ought to have been a function all along. :)
> >> Before this proposal, I didn't think so.
>
> > I'm not sure whether "print ought to have been a function all along", in
> > fact.  Maybe, maybe not.  It IS fractionally handy for the
above-mentioned
> > uses, after all.
>
> So would a function have been, right?

Yes, with a microscopic amount of extra syntactic baggage.  I have no
real opinion on whether this very slight extra syntax for a function
justifies print-as-a-statement's existence.


> > We need NOT deprecate print-as-a-statement to abhor the
> > idea of extending its functionality to cases for which its
appropriateness
> > is low-to-nonexistent.
>
> Oh, I agree. That was the point I was making, right? The realisation *now*
> that if print had been a function all along would've avoided this hackish
> addition is only a side-issue that I mentioned.

Well, we may be in violent agreement on this, but this wasn't entirely
clear to me; the "ought to have been" may have seemed more central to me
than you intended it to be.

The BDFL has argued, basically, that whether having print as a statement
was best or not, we're stuck with it, THEREFORE we need to extend the
core language to let print's output be more conveniently directed to
a file.  I'm NOT convinced at all of the consequentiality: I think we
may perfectly well accept "being stuck with print" (whether we're sort
of happy, relatively indifferent, or very slightly saddened by that)
while intensely believing that the print statement's role should _not_
be expanded to output-to-file.  And I think this lack of consequentiality
is very important, and needs to be emphasized.


> > Even if one dislikes the idea of print existing at all as a statement,
> > extending its functionality would just be "throwing good money after
> > bad".
>
> I'm not quite sure who you are arguing with here. I mean, I don't dislike
> the idea of print existing as a statement at all, and I do think extending
> its functionality is not the best approach. I thought I said this in
> my post. :)

I guess I'm basically arguing with the proponents of the print
statement's functionality extension; I realize this is tilting
at windmills, as we're no doubt stuck with the 'print>>' kludge
anyway, but then, Havel was just as convinced he would not live
to see communism crumble, but this did not stop him from braving
far-worse repercussions than I'm likely to face, just in order to
keep stating his opinions in the matter (highly recommended reading:
Timur Kuran's "Private Truths, Public Lies: The Social Consequences
of Preference Falsification", Harvard University Press, 1995 -- a
rare gem, a sociology text with the intellectual rigour of an
economics text... but then, Timur's a rare gem himself, being a
professor of both Economics and Islamic Culture at USC:-).


> >  But, if one DOES sort-of-like the statement, it need not follow
> > that the statement's mission must be enlarged to make it able to output
> > to a file, when that specific need (and others) are best served by a
> > function (or method) even if the statement stays just as it is today.
>
> As I said in my post, right? Are you summarizing me? :)

I've been justly accused of many faults, but, as "to summarize"
implies concision, I can honestly aver that THIS is something
I've never been guilty of.  I can always find a way to say in
a hundred words what somebody else could say in a dozen.

If you think our opinions on this issue are identical (this was
not clear to me from your post, but I cannot rule it out), then
you may want to say I was _paraphrasing_ your expression, or
"glossating" them (in the technical sense; cfr
http://www.britannica.com/bcom/eb/article/3/0,5716,48743+1+47624,00.html).


Alex